- User Since
- Jul 12 2018, 4:43 PM (115 w, 4 d)
Sat, Sep 26
Maybe we'll have to clarify this further in the future, but for now this is an improvement.
Fri, Sep 18
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.
Thu, Sep 17
Looks pretty good, thanks! I think this clears up the misunderstandings.
Wed, Sep 16
The key here is the word "assumed". We treat the function as if it looks like this:
Mon, Sep 14
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:
Sun, Sep 6
Sat, Sep 5
Fri, Sep 4
Add some prose, not just code. Otherwise our list of attributes would be incomplete.
Thu, Sep 3
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.
Wed, Sep 2
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.
Ah, I guess Ianded on an older version of this through a link and didn't notice. Nevermind.
Tue, Sep 1
Do I understand correctly that this means we should have a template parameter, but haven't read it yet? In that case it would seem strange that we consider them different.
Rebase on top of D84603.
Aug 29 2020
Remove "holding" and moved to a separate message because the overlap was getting smaller.
Aug 28 2020
Aug 27 2020
Ping. Maybe this change is too silly, but I think it's better to be precise and not muddle qualification conversions together with casting away noexcept.
Maybe this is to trivial for a review. The comment on StandardConversionSequence::Third in clang/Sema/Overload.h says
Aug 26 2020
Aug 25 2020
Aug 24 2020
@aaron.ballman, can you have a look again? I think this change is consistent with what we're already doing.
Aug 22 2020
@hans, could we bring this to the release-11.x branch?
Aug 19 2020
Aug 18 2020
Thanks, this looks good to me.
Aug 17 2020
First of all thanks for doing this, I was observing the same issue on arvm6l and armv7l.
Aug 4 2020
Jul 27 2020
Jul 26 2020
Test failure is expected because I based this on D84603 locally, but I'm not sure how to tell that to Phabricator.
@anarazel, that should fix the issue you reported on IRC.
Jul 10 2020
The linkers were behaving differently though: lld and bfd dropped the FINI entirely whereas gold had FINI=0, which lead to a crash. Which of these behaviors would be expected?
Jun 19 2020
Yup, c-index-test crashing was one of the motivators behind this.
Jun 9 2020
Jun 8 2020
@arsenm, just FYI: you probably just overlooked this when removing the header.
Jun 7 2020
Jun 6 2020
Jun 5 2020
Apr 28 2020
Apr 27 2020
Apr 22 2020
@rsmith, what do you think about this?