This change fixed the downstream crash. Thanks for the quick turnaround!
Tue, Jul 20
Thu, Jul 15
update test case
Wed, Jul 14
Thanks for the updates, comments and the reproducer. I've added those in this update. If possible, I'd like to get this change accepted to avoid the crash we currently see, and I'll immediately follow up with the FIXMEs. Otherwise, I'll iterate quickly on the FIXMEs. - Vince
address comments, add test case suggested by @bjope
Thanks all for the updates and comments. I'll address promptly and resubmit. Best!
update commit header
Apr 30 2021
Apr 6 2021
Feb 19 2021
Polite ping. This is a small and simple change, my only doubt is the test coverage. But frankly I see none of the literals are covered in any of the test cases (unless I'm missing something). Could I get some guidance on required test coverage for this simple change, or a LGTM?
Feb 18 2021
Feb 17 2021
Remove extraneous line
Add test case
Feb 8 2021
Feb 3 2021
Thanks @rsmith, will do. Best!
Jan 28 2021
Jan 20 2021
Ping. Could someone pick up review of this patch again, please? Ilya left off with a question to @rsmith , and at that point all activity fell off. Thanks.
Jan 17 2021
Rebase, commandeer this patch from Ilya.
Jan 14 2021
Dec 26 2020
Thanks @steakhal , I found your Bugzilla bug only after I submitted this patch. I'll revise based on your comments and resubmit. Best!
Thanks for the comments, @NoQ . I'll carefully review and update. BTW, I found an old Bugzilla case that seems to relate to this change directly -> https://bugs.llvm.org/show_bug.cgi?id=2820. Once this change is evolved and accepted, I'll update that Bugzilla issue and close. Cheers!
Dec 25 2020
I pulled https://reviews.llvm.org/D69726, brought it up to date and pushed to github at https://github.com/vabridgers/llvm-project-dev.git, branch: vla-fam-fixes. Everything seems ok on this branch (LITs pass, reproducers from https://bugs.llvm.org/show_bug.cgi?id=47272 and https://bugs.llvm.org/show_bug.cgi?id=28450 no longer crash). I think perhaps this change can be abandoned in favor of progressing https://reviews.llvm.org/D69726 ? @Charusso and @balazske , what do you think? Thanks!
I was referred to this patch from https://reviews.llvm.org/D86743. I pulled this patch under review, brought it up to date and pushed to github at https://github.com/vabridgers/llvm-project-dev.git, branch: vla-fam-fixes. Everything seems ok on this branch (LITs pass, reproducers from https://bugs.llvm.org/show_bug.cgi?id=47272 and https://bugs.llvm.org/show_bug.cgi?id=28450 no longer crash). I can continue and push a change to Phabricator for review, or @Charusso and/or @balazske could finish this? I didn't want to just push an update without asking first :/ Cheers!
Dec 24 2020
@baloghadamsoftware , these changes do seem to help the case described. This patch isn't quite up to date, and needs to be integrated with changes from @balazske (my integration is hacky and needs to be cleaned up). I'll continue working on this, and get back to you. These changes may also be helpful in solving https://bugs.llvm.org/show_bug.cgi?id=48136 (as I had discussed with @steakhal). Thanks for looking into these things.
Dec 23 2020
Dec 20 2020
Based on a suggestion from Balazs, I reduced the scope of the initial change to just scalars. There is one issue I'd like to hear comments on, and that's how to handle the case of extracting a bit field outside of the represented APInt. Currently, I'm returning UnknownVal(), following the lead in RegionStore.cpp, line 1775, in method getBindingForElement. During development, I hit an assert in extractBits when encountering a "negative" case exposed by the LIT ptr-arith.cpp - the negative case being an index out of bounds of the punned scalar (see the LIT I added for the negative cases).
Reduce scope of this initial change to just scalars
This proposed change seems to address the referenced issues (https://bugs.llvm.org/show_bug.cgi?id=39032 and https://bugs.llvm.org/show_bug.cgi?id=44114). I believe the scalars test cases to be mostly complete, and the structures test cases to be at most a baseline (just based on covering specific cases mentioned in the bug reports). Please let me know how to improve through review comments and I'll work on that. Thanks to Balazs, Gabor, Artem and Denis for feedback in the email thread and help working through this.
Update commit header.
Clean up a few typos
Aug 28 2020
Aug 27 2020
Aug 7 2020
All comments marked as done. ok to land?
address Bjorn's comment
Aug 6 2020
Ping! Ok to land?
Thanks for the recent comments. I just pushed a few improvements over the last patch that didn't comprehend latest comments from @rsmith and @Quuxplusone. I'll read through those carefully and address those.
use source from expression in fixit
address some chained comparison ambiguities outside of original scope of changes
Aug 5 2020
I added prototype fixits per request by Roman, updated the LIT test, and added an additional RUN line (one for -Wparentheses and one for -Wcompare-op-parentheses). Also filed https://bugs.llvm.org/show_bug.cgi?id=47010 to follow up on the FIXME cases at the bottom of the LIT since they are out of scope for this change. Thanks for the feedback and comments so far, I look forward to driving this change to completion.
added prototype fixits for review.
added additional RUN test case.
filed https://bugs.llvm.org/show_bug.cgi?id=47010 for other
warnings improvement post landing of this patch, after lgtm
Aug 4 2020
ok, I think it's all sorted out now. Thanks @bevinh for the desk review. Let's start at the beginning again :)
ok, I think it's all sorted out now.
fix misc test formatting
Aug 3 2020
remove -DFIXED_POINT from lit test, since it's not needed in this casting
I updated the commit header with more details since the first submission was obviously too terse. @bjope, I believe the update should address your comments.
improve the commit message detail
Aug 2 2020
I believe I've addressed all comments so far. Looks like Arthur suggested some particular cases that are not currently covered, and are not covered by this change since I think addressing those issues are our of scope of my original intent. If this patch is otherwise acceptable, would the reviewers be ok accepting this patch on the condition of creating a bugzilla report to track those issues?
refactor test cases per comment from Arthur
back out last unwanted changes from clang-format
Thanks for the comments. I posted an update for the simpler issues, working on refactoring the test cases and creating a fixit. Thanks for the good and actionable review comments!
Address simpler issues brought up during review so far.
Tests to be refactored, and a fixit added.
Thank you for the comments @lebedev.ri and @Quuxplusone. I'll abandon the tidy approach (https://reviews.llvm.org/D84898) and work towards satisfying these review comments (and any others), driving towards acceptance. Best!
This is an implementation in the CFE, after submitting and getting comments on https://reviews.llvm.org/D84898.
I've posted https://reviews.llvm.org/D85097 to replace this review. https://reviews.llvm.org/D85097 implements this check in the CFE instead of as a tidy check per recommendation from @lebedev.ri . If acceptable, I'll abandon this review.
Aug 1 2020
Looks like this can be implemented as a warning in the cfe (as @lebedev.ri suggested). I'll probably abandon this review, but will keep it active until I have the alternative cfe warning patch prepared.
@njames93, I'll take a crack at implementing a cfe diagnostic for this, see how far I get. Cheers :)
Jul 30 2020
Thanks Eugene, I think the backtick issue has been addressed.
Address backticks in rst files
I believe all review comments have been address, except for the discussion on implementing this in the CFE or as a tidy check.
Address most review comments.
Thanks all for the prompt and actionable comments. I will address all comments directly and 1-1, but would like to bottom out on one point before driving this forward. @lebedev.ri commented this should be in the Clang front end rather than a tidy check. Can we reach a consensus on that comment before I proceed with either a tidy check renamed to bugprone (comment from @Eugene.Zelenko ) or implement this check in the front end, enabled only when all warnings are enabled? I had considered both approaches when I started this, and thought the tidy checker was the best first step.
Jul 29 2020
I believe this is ready for review. Thanks!
Correct some simple mistakes
Jul 25 2020
Adding negative test case that exposes the original problem.