User Details
- User Since
- Jul 12 2018, 4:43 PM (131 w, 5 d)
Dec 14 2020
Dec 9 2020
That's also what I was seeing, and then I wondered why our warnings don't catch this.
Dec 8 2020
Nov 28 2020
@tstellar, can we have this in 11.0.1? I've already ported it back in openSUSE because we were having problems with the CMake 3.19 update.
Nov 23 2020
Thread safety attributes want callers of a function to have the same attribute, while this change wants callees to have the same attribute. So the attributes propagate in different directions.
Nov 22 2020
Nov 17 2020
It seems to depend on the standard, with -std=c++17:
Nov 16 2020
Ping.
Nov 15 2020
Fixed the spelling issue in rGdea31f135ceae6e860e6301f9bb66d3b3adb1357.
Rebase and add a comment about the limitations of this implementation.
Nov 3 2020
That's a good point, while mu_ is public, params is a local variable.
Nov 2 2020
@rupprecht, maybe you can try it again?
Rebased on D84604, included static members, and addressed review comments.
Oct 30 2020
If I read this correctly, we'd have a false negative with this patch, which is probably Ok given that this is an odd case.
Need to rebase this on top of D84604 plus a subsequent fix.
Oct 29 2020
Pushed a fix in rGbbed8cfe80cd27d3a47d877c7608d9be4e487d97. For now we just consider all static members as inaccessible, so we'll treat them as we did before this change.
Oct 28 2020
Added the assertions in a follow-up change rGebfc427bbe08f0c36af9721d5a4e6d3ffe2e4bf5.
Can't really add anything to the discussion between @Quuxplusone and the author, just a few comments about the test.
Oct 27 2020
Collect location of a trailing return type in the parser, use that for the warning.
Oct 26 2020
Oct 25 2020
Oct 24 2020
LiteralPtrs aren't always globals, local variables are also translated that way. So we ask the stored ValueDecl if it isDefinedOutsideFunctionOrMethod. That seems like the right thing.
Almost forgot about that. I think I've figured it out.
Oct 1 2020
Sep 30 2020
Use FindPython3 and remove shebang. The script didn't have an executable bit anyway.
Sep 26 2020
Maybe we'll have to clarify this further in the future, but for now this is an improvement.
Sep 18 2020
It's not really too hard, there is an existing parameter somewhere in the CFG generation that controls these exception handling edges, and we'd probably have to change some other diagnostics plus improve the performance/memory usage.
Sep 17 2020
Looks pretty good, thanks! I think this clears up the misunderstandings.
Sep 16 2020
The key here is the word "assumed". We treat the function as if it looks like this:
Sep 14 2020
You can view it this way: there is a dynamic set and a static set of capabilities. The static set is always the same at any particular point in a function, regardless of the circumstances we're called from. It's what we determine in the analysis. The dynamic set depends on who called us and could be greater. To illustrate the difference:
We don't really have a good understanding of ASSERT_CAPABILITY ourselves. For example, there is this loophole:
Sep 6 2020
Sep 5 2020
Sep 4 2020
Add some prose, not just code. Otherwise our list of attributes would be incomplete.
Sep 3 2020
Add tests with qualified names, let tests rely on shadowing.
- More detailed description how scoped capabilities work.
- Make the comment wording more consistent with existing comments and the previous explanation.
- Properly implement the destructor in the presence of an Unlock() function: we need to keep track of the status then.
- Add try-acquire functions on scoped lock.
- Fix compiler errors.
Sep 2 2020
Not sure about the added comments, I can also remove them if they're not helpful.
Fix as suggested by @rsmith instead: set InvalidDecl directly.
Everything compiles with ValueDecl* Decomp instead of a LazyDeclPtr, but I'll leave it until we figure out whether we might actually need it.
I'll go with what @rsmith proposed to fix the bug. If the entire deserialization process doesn't rely on invariants, the order should indeed be irrelevant.