That is, mark constructor parameters being used to initialize
non-const reference members.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks, this seems like a useful extension of the usedAsMutableReference modifier
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
541 | Use auto *Member to make clang-tidy happy (const auto * is also fine) Likewise in a few places below | |
543 | Can we factor out this logic into a helper function highlightMutableReferenceArgument(QualType TargetType, const Expr *Arg)? Then here we can call highlightMutableReferenceArgument(MemberType, Init->getInit()) | |
553–554 | nits from previous patch -- I'm getting clang-tidy diagnostics on this line about:
Could you fix these as part of this patch? | |
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp | ||
752 | Maybe we can add a line where the initializer expression is not a constructor parameter, but e.g. a non-const static data member of another class. |
Implemented reviewer suggestions.
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
541 | Ewww... But okay. |
Note that the build failure seems unrelated, as it's due to a failing clang-tidy test.
Yes, I plan to. I'm just building it locally to verify the tests are passing. (And sometimes, for reasons I don't understand, LLVM's build system triggers a full rebuild even though I've only applied a patch that touches a couple of files...)
I see, thanks.
Regarding the scope of rebuilds, it seems to me that the build system pulls in repository meta data, as there's lots of files rebuilt after simply amending a commit with no sources having changed.
Use auto *Member to make clang-tidy happy (const auto * is also fine)
Likewise in a few places below