This is an archive of the discontinued LLVM Phabricator instance.

[AST] Add more source information for DecltypeTypeLoc.
ClosedPublic

Authored by hokein on Jan 6 2022, 11:35 PM.

Details

Summary

Adds the paren source location, and removes the hack in clangd.

Diff Detail

Event Timeline

hokein created this revision.Jan 6 2022, 11:35 PM
hokein requested review of this revision.Jan 6 2022, 11:35 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJan 6 2022, 11:35 PM
hokein added inline comments.Jan 6 2022, 11:42 PM
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:

  • first time, we parse the raw decltype token, and we annotate that (the DS was created locally, and then was thrown away)
  • second time, we parsed the annotated decltype, and set another DS, at this point, we lost the LParen information :(

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?
This is enough to compute the correct sourcerange, which was the original bug we hit.

Our options are:

  • do the work to always compute it: nice to have but it does seem hard/intrusive
  • don't store/expose it
  • expose it but have it be unreliable

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 :-)

hokein updated this revision to Diff 398101.Jan 7 2022, 4:25 AM

don't expose LParen loc.

hokein added a comment.Jan 7 2022, 4:26 AM

(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.

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 :-)

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).

(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.

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?

sammccall accepted this revision.Jan 7 2022, 5:47 AM

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.

This revision is now accepted and ready to land.Jan 7 2022, 5:47 AM
This revision was landed with ongoing or failed builds.Jan 10 2022, 12:34 AM
This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.