hokein wrote: > I think the documentation is right and matches what's happening. It's just that what's considered local has changed in the case of a NestedNameSpecifier which is a Type. The type was previously split-up, each chunk being its own nested name specifier. Now a Type is always a NestedNameSpecifier component by itself.
Just my two cents. I think the term "local" is ambiguous, and my mental model has always been that it refers to the last specifier in a qualified name. This seems to have been the behavior, and the public API [doc](https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/NestedNameSpecifierBase.h#L364-L366) implies it. This recent change seems to break that model and introduces behavior that feels inconsistent: - For namespace specifier `ns1::ns2::`, `getLocalSourceRange` returns the range of "ns2::"; - For type specifier `ns1::C1::`, `getLocalSourceRange` returns the range of "ns1::C1::"; This difference is confusing. While I understand the reasoning behind the internal implementation, API users aren't likely to be aware of it, and the "last piece" model seems more intuitive. If this new behavior is intended, could we update the comments for `getLocalSourceRange()` to clarify these new rules and provide examples for each case? or even would it make sense to preserve the old behavior for the sake of API consistency? https://github.com/llvm/llvm-project/pull/147835 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
