[clang] [clang][StaticAnalyzer] Add support for variables and fields in GetEnclosingDeclContextSignature (PR #214102)

[Donát Nagy via cfe-commits]

https://github.com/NagyDonat requested changes to this pull request.

This commit uses `setDeclWithIssue` in a way that is not consistent with the intended meaning and other usage of this method. Its (admittedly a bit vague, but still understandable) doc-comment says that its role is
```c++
// Specifically set the Decl where an issue occurred. This isn't necessary
// for BugReports that cover a path as it will be automatically inferred. 
```
and before this PR all checkers that use this pass the declaration of a function, class or some analogous thing that _contains_ the error. (Arguably the Webkit checkers may contain one or two counterexample – but that is also unfortunate and not a good example to follow.)

This commit twists the meaning of this `DeclWithIssue` field by passing the `Member` declaration to `setDeclWithIssue`, which is – if I understand correctly – not the declaration that _contains_ the problem, but the declaration that _is_ problematic. After this `DeclWithIssue` can end up with containing "small" declarations like fields or ivars that were previously impossible – which is "handled" by injecting new recursive cases into one function that consumes the value of `DeclWithIssue`.

I don't see any reason why you need to deviate from the established meaning of `DeclWithIssue`: instead of calling `setDeclWithIssue(Member)` you can simply calculate the declaration that contains the problem (i.e. contains `Member`) and pass that to `setDeclWithIssue`.

By the way, I don't think that your code causes any incorrect output – but it is still incorrect, because it needlessly complicates the codebase. When you are using AI assistants, please pay attention to ensure that it inserts the new logic _in a sensible place_. (Passing tests are not enough – the code must stay clean.)

https://github.com/llvm/llvm-project/pull/214102