https://github.com/vtjnash commented:
> Before this commit, isCXXInstanceMember() was true, so it was read as the
> &Outer::mu wildcard. Spelling it &Outer::mu makes the warning go away. Is
> this change intended for C++?
Yes, `&mu` is meant to mean the same as `mu`, i.e. `this->mu`. Note that
`requires_capability(mu)` on `Inner::f` warned the same way before this commit,
so the wildcard was only masking an older problem for the `&mu` spelling.
`Inner` has no `mu`; the only sensible meaning of the annotation is "the `mu`
of the `Outer` this `Inner` belongs to". When the `Inner` is reached through
its `Outer`, the analysis can find that object, and I have an in progress
branch to resolve it that way. From a bare `Inner *` it cannot, short of a
`container_of` macro:
```c++
struct Outer {
Mutex mu;
struct Inner {
void f() REQUIRES(&mu);
} in;
void g(Inner *inner) REQUIRES(&mu) {
in.f(); // accepted with the fix: resolves to this->mu
inner->f(); // still warns: 'inner->mu', no enclosing object is reachable
}
};
```
For the second form we can do one of three things:
1. Since no `mu` could be meant that the analysis can check, infer a wildcard
and treat it as written `&Outer::mu`. This restores the old behaviour, which
accepts any held `mu`, including an unrelated `Outer`'s.
2. Keep warning but print it as `&Outer::mu` with a note that no enclosing
object is reachable from `inner`. Precise, but every such call site becomes a
warning that can only be silenced by restructuring or by spelling `&Outer::mu`,
as you found.
3. Diagnose the attribute in Sema, as you suggest. This cannot work in general,
since the same attribute is fine when the member is reached through the
enclosing object, as `in.f()` shows.
https://github.com/llvm/llvm-project/pull/231604
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
