[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)
    Haojian Wu via cfe-commits 
    cfe-commits at lists.llvm.org
       
    Thu Oct  9 01:57:37 PDT 2025
    
    
  
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
    
    
More information about the cfe-commits
mailing list