Skip to content

Changes to add itypes on undefined functions#691

Merged
john-h-kastner merged 17 commits into
mainfrom
rewrite_extern
Sep 8, 2021
Merged

Changes to add itypes on undefined functions#691
john-h-kastner merged 17 commits into
mainfrom
rewrite_extern

Conversation

@john-h-kastner

@john-h-kastner john-h-kastner commented Aug 25, 2021

Copy link
Copy Markdown
Collaborator

With this change, 3C will insert itypes on functions without definitions. For example:

void foo(int *);

becomes

void foo(int * : itype(_Ptr<int>));

This should be merged into main after #690, #689, and #688.

@kyleheadley kyleheadley 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 good, though I had couple of comments.
Congratulations on getting more checked types in the tests.

Comment thread clang/lib/3C/DeclRewriter.cpp Outdated
Comment thread clang/lib/3C/ProgramInfo.cpp Outdated
Comment thread clang/test/3C/function_typedef.c Outdated
john-h-kastner added a commit that referenced this pull request Aug 26, 2021
Adds checks to ensure that 3C will not attempt to rewrite in unwritable files
to insert array bounds. The test file in this PR contains an example using a
function body in an unwritable file which fails on the current main. After
changes made to support rewriting in functions declarations without
definitions (#691), this will be able to
happen even when the functions are not defined, and so it will becomes a more
prevalent issue.
@john-h-kastner john-h-kastner changed the base branch from rewrite_extern.base to main August 27, 2021 19:27
@john-h-kastner john-h-kastner changed the base branch from main to options_cleanup August 30, 2021 18:50
@john-h-kastner

Copy link
Copy Markdown
Collaborator Author

The new behavior is now behind a flag. This now also depends on #692

@john-h-kastner john-h-kastner changed the base branch from options_cleanup to main August 30, 2021 19:55
Fixes an assertion that would fail when attempting to extract the string
representation of an itype expression from the original source code if
the itype expression was inside a macro. The string representation for
itypes in macros is now re-generated from the AST.

@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.

The flag definition itself looks OK modulo my comment, but there have been so many merges and force-pushes since Kyle's approval that I can't claim to have reviewed the other changes you've made since then. Are we going to just trust that those changes are OK? Or if we want, I can try to construct the right diff to review.

Comment thread clang/tools/3c/3CStandalone.cpp Outdated
@john-h-kastner

john-h-kastner commented Aug 31, 2021

Copy link
Copy Markdown
Collaborator Author

Or if we want, I can try to construct the right diff to review.

The relevant changes should just be d589534...0ec32e0

The force-pushing can safely be ignored.

john-h-kastner and others added 2 commits August 31, 2021 15:14
Co-authored-by: Matt McCutchen (Correct Computation) <matt@correctcomputation.com>
@mattmccutchen-cci

Copy link
Copy Markdown
Member

The relevant changes should just be d589534...0ec32e0

Thanks. @kyleheadley I think it makes the most sense if you review these changes since you reviewed the previous version of the same code.

@kyleheadley

kyleheadley commented Sep 1, 2021

Copy link
Copy Markdown
Member

The relevant changes should just be d589534...0ec32e0

In this block I see:

ConstraintVariables ~2260:
-  bool SrcChecked = ExternalConstraint->isOriginallyChecked() ||
-                   ExternalConstraint->srcHasItype();
+  bool HasItype = ExternalConstraint->srcHasItype();

But it doesn't appear in the collective change. It's the only code from the block that I have any issue with. Was it perhaps reversed because of how github deals with diffs? Was this a real change and if so what is it for?

@john-h-kastner

Copy link
Copy Markdown
Collaborator Author

Was it perhaps reversed because of how github deals with diffs? Was this a real change and if so what is it for?

This is undoing a change that was present in the original version of the PR

@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.

One thing I noticed. I'm still hoping Kyle will review all the changes since his previous approval.

Also, please merge main into this branch per our discussion. We expect that to make no difference, but it's good to rule out any surprises during the PR merge.

Comment thread clang/lib/3C/ProgramInfo.cpp Outdated
Comment on lines +457 to +458
// If we've seen this symbol, but never seen a body for it, constrain
// everything about it.

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.

It seems this comment is no longer quite accurate when InferTypesForUndefs is on.

@kyleheadley

Copy link
Copy Markdown
Member

One thing I noticed. I'm still hoping Kyle will review all the changes since his previous approval.

Did I not do that in my previous comment?

If there's some confusion about what needs to be reviewed, please send me a link, like was done above, or let me know that I'll need to look over the whole thing again. Otherwise, I'll stick with trusting that our team wants to have their code reviewed and has made their best effort to provide it. Since, as far I as recall, "submitter presses merge" and takes responsibility for their own code.

@mattmccutchen-cci

Copy link
Copy Markdown
Member

One thing I noticed. I'm still hoping Kyle will review all the changes since his previous approval.

Did I not do that in my previous comment?

If there's some confusion about what needs to be reviewed, please send me a link, like was done above, or let me know that I'll need to look over the whole thing again. [...]

My concern was that that discussion had not reached a conclusion (as could be expressed by a GitHub re-approval), not that there was confusion about what needed review. Maybe I should have said "approve" rather than "review". 🙂

@kyleheadley kyleheadley 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.

re-approve (code so far). Carry on.

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