Skip to content

Soften error#414 - #432

Closed
kyleheadley wants to merge 7 commits into
mainfrom
soften_error#414
Closed

Soften error#414#432
kyleheadley wants to merge 7 commits into
mainfrom
soften_error#414

Conversation

@kyleheadley

Copy link
Copy Markdown
Member

Continuation of #421 with correctcomputation branch. I improved the code based on the comments and added a couple tests. I also ran the nightly tests. They mostly failed, but the same ones passed/failed as in the latest scheduled run, so I think that means it's good?

@kyleheadley kyleheadley mentioned this pull request Feb 16, 2021

@mattmccutchen-cci mattmccutchen-cci left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like good progress. Thanks!

Comment thread clang/test/3C/multidef2_xfail.c
@mattmccutchen-cci
mattmccutchen-cci self-requested a review February 18, 2021 21:31
@mattmccutchen-cci
mattmccutchen-cci dismissed their stale review February 18, 2021 21:41

My main concerns have been addressed, but I'm not prepared to approve the whole PR.

@mattmccutchen-cci
mattmccutchen-cci removed their request for review February 18, 2021 21:41
@mattmccutchen-cci

Copy link
Copy Markdown
Member

Thanks for updating the tests and fixing my obvious mistakes in the RUN lines (which I see now). I would still prefer to see multi-file declaration + definition cases, but if others don't feel it is important, I won't insist on it.

CAtoms CFrom = From->getCvars();
assert(Vars.size() == CFrom.size());
if(Vars.size() != CFrom.size()) {
ReasonFailed = "transplanting between pointers with different depths";

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it ever possible for ReasonFailed to be non-empty when it gets here? In mergeDeclaration you are checking if it was already set, since there are recursive calls.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I think not, and you've probably checked; just wondering.)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did miss the recursive call. Partly because I have no idea what FV is. What is FV? I'll give it a modified reason if necessary with a return.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added a function pointer fail case and an internal merge fail case, both with returns.

Comment thread clang/lib/3C/ProgramInfo.cpp Outdated
// assume a global function, but change to a static if not
ExternalFunctionMapType *Map = &ExternalFunctionFVCons;
if (!FD->isGlobal()) {
// if the filename is new, just insert and we're done

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it mean for the filename to be "new" ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet seen in the map. I'll improve the wording.

@mwhicks1 mwhicks1 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the refactoring of the insertion code for FV constraints! I don't understand @mattmccutchen-cci 's comment about multi-file tests -- aren't there multi-file tests in this PR (involving function foo) ?

// By transplanting the atoms of OldC into NewC, we ensure that any
// constraints applied to NewC later on constrain the atoms of OldC.
NewC->brainTransplant(OldC, *this);
void ProgramInfo::insertNewFVConstraint(FunctionDecl *FD, FVConstraint *NewC,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old functions were removed from ProgramInfo.h; why was this new function not added there?

@kyleheadley kyleheadley Feb 19, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It always existed as the entry point and branched into the two functions now removed. (But since 2/3 of then were minor code then call then next, I combined them all)

@mattmccutchen-cci

Copy link
Copy Markdown
Member

I don't understand @mattmccutchen-cci 's comment about multi-file tests -- aren't there multi-file tests in this PR (involving function foo) ?

We have difftypes1{a,b} with two conflicting declarations of foo in different files and multidef1{a,b} with two definitions of foo in different files (which happen to be conflicting as well but trigger the "multiple definitions" error first). These tests are just cleaned-up versions of tests that predated this PR.

That leaves us to consider tests of the conflicting declaration + definition case that is being fixed in this PR. This PR adds difftypes2, with a conflicting declaration and definition in the same file, and difftypes3, which is the same but with the declaration and definition in the reverse order. But this PR has no test where the conflicting declaration and definition are in different files passed in a single 3C run.

My sense was that the multi-file case is slightly more likely to break than the single-file case, so I would have preferred that the new tests use multiple files. But (as I believe Kyle was arguing) the chance of a change breaking the multi-file declaration+definition case without breaking either the multi-file two-declaration case or the single-file declaration+definition case seems low, so this may not be worth doing now, especially given that the code may be reworked again before too long (e.g., as part of #433).

@mwhicks1

Copy link
Copy Markdown
Member

I see. Then my question is: Is the reason for the absence of the test you are asking for because it won't actually pass, and you are proposing that we should add it and also make further changes so that it does?

I see the link to #433, which is a long discussion I don't have time to read ATM. But if I get the gist of it and what you are saying, there are larger problems afoot that we should not leave for too long, and perhaps the missing/unsupported case you are talking about can be considered with them. Perhaps copy your above comment to #433 too, so we don't drop it once this PR is merged?

@mattmccutchen-cci

mattmccutchen-cci commented Feb 19, 2021

Copy link
Copy Markdown
Member

Is the reason for the absence of the test you are asking for because it won't actually pass, and you are proposing that we should add it and also make further changes so that it does?

No, the code in this PR is fine and the test would pass. For concreteness, I've gone ahead and written it: here's a change that adds the case I was talking about (difftypes_decl_defn_file{1,2}) and one other and makes some cleanups. I can submit this as a PR later, unless we think having these tests in our suite is more trouble than it's worth in terms of maintenance and running time. To be clear, since that decision can be made later on its own merits, I have no remaining concern about the tests in this PR.

@mwhicks1

Copy link
Copy Markdown
Member

OK sounds good. Let's get this merged, and we will welcome additional tests later of the form you propose. Thanks!

@kyleheadley

Copy link
Copy Markdown
Member Author

This PR is now integrated into a #463, a more encompassing change which removes half the code here anyway.

@kyleheadley kyleheadley closed this Mar 3, 2021
@kyleheadley
kyleheadley deleted the soften_error#414 branch March 8, 2021 18:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants