refs #13513 - adjusted access of known int values #7181
Conversation
firewave
force-pushed
the
knownint
branch
2 times, most recently
from
3ac7fcc to
516a7f3
Compare
|
This obviously still needs to use the proper calls but that might silently change the behavior and I would like to know if it does. But so far I have not been able to trigger any of those asserts and I do not feel comfortable putting those actually out there. I will still give it a spin with daca and have some other tests to run which might help with finding at least a single test case. |
firewave
changed the title
|
I will take a tiered approach. Using the wrapping functions here and actually adjusting to the proper calls in a follow-up. I am doing this because I still want to test if we might trigger this along with some other tests. And I also need to profile this to make sure that I do not accidentally introduce performance regressions. Also it is not a drop-in replacement in several cases. |
Turns out the unit tests actually trigger this. I definitely ran those locally with the changes and had no failures. Not sure what I did wrong... |
The code in question was only added a few days ago. That explains why. |
lib/symboldatabase.cpp
Outdated
| if (dimension_.tok && (dimension_.tok->hasKnownIntValue() || | ||
| (dimension_.tok->isTemplateArg() && !dimension_.tok->values().empty()))) { | ||
| dimension_.num = dimension_.tok->getKnownIntValue(); | ||
| if (dimension_.tok) { | ||
| if (dimension_.tok->hasKnownIntValue()) | ||
| dimension_.num = dimension_.tok->getKnownIntValue(); | ||
| else if (dimension_.tok->isTemplateArg() && !dimension_.tok->values().empty()) { | ||
| assert(dimension_.tok->values().front().isKnown()); | ||
| dimension_.num = dimension_.tok->values().front().intvalue; | ||
| } |
There was a problem hiding this comment.
@chrchr-github Please have a look. You changed this logic a few days ago in 46781df.
There was a problem hiding this comment.
For template arguments, the values are only possible, not known. But since getKnownIntValue() just returns the first one, it is what we want in this case (I think).
There was a problem hiding this comment.
So like the previous behavior? Just unconditionally use the first value and set dimension_.known to true?
There was a problem hiding this comment.
Yes, pretty much. I imagine/hope that template arguments can have at most one value.
There was a problem hiding this comment.
Maybe we should set those values to known in the future, and prevent unwanted knownConditionTrueFalse warnings in a different way.
There was a problem hiding this comment.
I imagine/hope that template arguments can have at most one value.
I will just add a different assert.
No description provided.