Adds the paren source location, and removes the hack in clangd.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
50 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
clang/lib/Parse/ParseDeclCXX.cpp | ||
---|---|---|
1012 | This is unfortunate for a common case decltype(expression) a;, the ParseDecltypeSpecifier is called twice to parse the decltype specifier:
One way to fix that is to add a new field SourceLocation in Token class (there is 4-bytes padding size left, so it won't increase its size), but I'm a little worried, it seems like an overkill to just fix this issue. |
Thank you for digging into this!
(BTW the parsing part of this is probably adjacent to a fix for https://github.com/clangd/clangd/issues/121, AutoType also doesn't have enough locations for decltype(auto). But definitely not something to touch in this patch)
clang/lib/Parse/ParseDeclCXX.cpp | ||
---|---|---|
1012 | What do you think about only storing the kw loc + endloc then? Our options are:
I don't know if 3 is better than 2 (without a use case it's hard to judge), maybe it just encourages writing buggy code. And if nothing else, 2 is smaller :-) |
(BTW the parsing part of this is probably adjacent to a fix for https://github.com/clangd/clangd/issues/121, AutoType also doesn't have enough locations for decltype(auto). But definitely not something to touch in this patch)
Yeah, that is my next step, this is an extending change of AutoTypeLoc.
clang/lib/Parse/ParseDeclCXX.cpp | ||
---|---|---|
1012 | Yeah, having the decltype loc + rparen loc should be enough to fix our bug, and it might be a better idea than having a partial working getLParenLoc.
We don't have a concrete use case of the paren range of decltype, so 2 is probably the best (though having a getRParenLoc API without a paired getLParenLoc feels incomplete). |
Yay :-)
clang/lib/Parse/ParseDeclCXX.cpp | ||
---|---|---|
1012 | Agree. Would it make sense to keep the internal names concrete but expose publicly only as begin/endLoc? |
LG thank you!
Keeping/removing the getRParenLoc() accessor is up to you, I see arguments both ways.
clang/include/clang/AST/TypeLoc.h | ||
---|---|---|
2001 | nit: decltype (typo) | |
2015 | So concretely I think I'm talking about just removing this getter, since getEndLoc() will by default to the end of getLocalSourceRange(). Probably the setter would stay as is? Anyway, up to you, it's harmless. |
nit: decltype (typo)