- User Since
- Sep 3 2015, 9:16 AM (198 w, 5 d)
See also https://xkcd.com/1638/
I guess it makes sense to add a test into test/Analysis/exploded-graph-rewriter/escapes.c as well, so that to learn if we can actually parse it later.
I think i'd rather remove it entirely.
In normal dumps i'd rather have it the old way because it's similar to how stack frames are displayed in the debugger.
Nice!~ I'm glad this is getting sorted out.
Sat, Jun 22
Fri, Jun 21
I guess let's add a test for the unicode problem that you're seeing.
Pls commit? ^.^
Aha, yep, nice debug flag!
It should be pretty easy to implement, just add your new visitor to the list of default visitors in findValidReport().
Aha, ok, got it. I guess the official term is "error node" (where "error" means "warning").
Thu, Jun 20
Oh, wait, no, loops.
Wed, Jun 19
I think this kinda makes sense, but also it looks like a risky change, because who knows how many times we have took the old behavior for granted. In particular, i'm slightly worried about this breaking the wonky logic of ExprEngine::VisitLogicalExpr (cf. D59857). But i've no specific concerns, so i think it's worth a try, given that it's a massive simplification.
Tue, Jun 18
Hey, thanks! That's a nice catch.
Oh, right, thanks!
My problem is demonstrated (and solved) by D63519. If i revert my changes but apply this patch instead, my test keeps failing.
Don't try to sneak in an unrelated change.
I mean, i'm removing backslashes but you're adding more backslashes. Therefore i think we're talking about different issues.
Hmm, this doesn't seem to solve my problem in D62761. Let me write some actual test case so that you knew it's fixed when it's fixed.
Mon, Jun 17
Add tests, rebase.
Yes, this would be helpful! Tests?
Fri, Jun 14
I don't remember what exactly does markInteresting() do and these tests don't really convince me that it does anything at all. Halp? >.<
Fair enough, they aren't really needed here.
(then, again, not sure what happens if more nested stack frames are around)
How about we track the condition value past its collapse point only if it involves an overwrite of a variable (or other region) from which the value is loaded? Like, if there are no overwrites, stop at the collapse point. If there are overwrites, stop at the oldest overwrite point (i.e., the value was loaded from 'x' which was previously overwritten by the value of value 'y' which was previously overwritten by the initial value of variable 'z' => stop at the overwrite point of 'y').
I am not sure about assuming operator bool being correct. I think we first could think about other tricks to limit the tracking (see my idea above) and if we fail I would only add such rules as a last resort.
Thu, Jun 13
*sloowly catches up >.<*
Great, thanks!! Let's commit this.
Wed, Jun 12
Yup, this makes sense now! I'll do some nit-picking for a little longer.
Tue, Jun 11
This problem is fairly complicated. We clearly need both behaviors (sometimes track until the definition, sometimes track until the collapse-to-null), and it's not clear to me right now when exactly do we need each of them. This is also not a high priority for GSoC because neither there are a lot of warnings of this kind (~15 or so) nor they're actually that false. I suggest taking this more slowly and delay this patch until we actually understand what is the right thing to do here.
All right, it seems that i'm completely misunderstanding this problem and we've been talking past each other this whole time.
Mon, Jun 10
In such cases i recommend starting with writing down a test. Like in TDD: first test, then code.
Whoa, this looks like a much needed improvement, i'm glad that you found it!
Thx for the cleanup!
Hey, i'm seeing a crash in this checker, would you like to look at it? It looks as if you're not being careful about dereferences/lvalue-to-rvalue-casts so it tries to compare &e to e1.
Fri, Jun 7
Thu, Jun 6
Ok! I'll be happy to have this addressed incrementally.
I wouldn't be surprised if some of these are entirely unused.
I think we should:
- Pre-normalize our expected outputs so that we didn't have to normalize them in every run-line.
- Treat the lack of newline in plist output as a bug and try to fix it.
Looks great! Feel free to add a Driver flag as well (i.e., --analyzer-werror or something like that) so that not to type -Xclang every time.
Aha, nice, that's much cleaner! Indeed, we have to skip the construct-expression, which is going to be on our way to the program point of new-expression which corresponds to calling the allocator, despite being nested within the new-expression. An annoying corner-case.
Ah, that positive!
Wed, Jun 5
Aha, that's something! And nice to see we've already had this bug covered with tests. Because, of course, i added these tests a year ago without even thinking about what the correct behavior should look like :/
Tue, Jun 4
Yay, this thing really works!
Thanks!! Will fix as soon as i get to my desktop.
Mon, Jun 3
Fri, May 31
Remove "-" from program point dumps because it resembles a removal marker in diffs.
I'll add some tests as soon as i'm sure tests for this thing actually work (by landing D62638).
Also switched to python2 because it seems to be the default. The differences are minimal.