This is an archive of the discontinued LLVM Phabricator instance.

[clang] Set TypeSourceInfo for vardecl's in addition to type when we can deduce.
AbandonedPublic

Authored by kadircet on Sep 20 2018, 6:31 AM.

Details

Diff Detail

Event Timeline

kadircet created this revision.Sep 20 2018, 6:31 AM
kadircet updated this revision to Diff 167718.Oct 1 2018, 6:12 AM

rebase & ping

aaron.ballman added a subscriber: aaron.ballman.

Can you give a bit more background on what problem you're trying to solve with this patch?

lib/Sema/SemaChecking.cpp
852 ↗(On Diff #167718)

I'm not certain I understand why this code has been removed?

lib/Sema/SemaDecl.cpp
10772

Why does this need to return a pair? It seems like the returned TypeSourceInfo* carries all the information needed by the caller, or is there ever a case where the QualType will be different than what is returned by TypeSourceInfo::getType()?

Can you give a bit more background on what problem you're trying to solve with this patch?

Sorry for the lack of context, it was about an offline discussion on Sema::DeduceVariableDeclarationType just setting the type and not setting the typesourceinfo, which was resulting in having DeducedType in type but not in typesourceinfo.

We wanted to fix that behavior because it was resulting in getting "auto"s when we look at typesourceinfo(which happens in astprinter). But then it turned out to be there are other parts of clang(including extra tools) that depend on typesourceinfo not having the deduced type, for example include-fixer and refactoring/rename, relied on that information being missing when they were looking for (usage counts/locations) of symbols they were looking for.

So in the middle of the patch we were just trying to figure out whether we are going to break a big assumption that lots of different components relied on but just didn't had any tests for. Maybe @rsmith would have more context about the behavior?

lib/Sema/SemaChecking.cpp
852 ↗(On Diff #167718)

It shouldn't have been, tried rebasing but it didn't go away. I think it was deleted at some point by a different change and somehow ended up showing in here as well. (Tried to revert, got an error stating warn_opencl_generic_address_space_arg doesn't exist)

lib/Sema/SemaDecl.cpp
10772

Yes, unfortunately there are cases these two differ. That's exactly the case we are trying to fix with that patch.

nhaehnle removed a subscriber: nhaehnle.Oct 17 2018, 3:24 AM
shahms added a subscriber: shahms.Oct 17 2018, 8:35 AM

It's worth noting that RecursiveASTVisitor appears to think they are at least somewhat equivalent in that it will only visit one or the other and prefers TypeSourceInfo, if present, via VisitTypeLoc. The fact that the TSI lacks this information makes it pretty awkward to access both the recursively deduced type and the corresponding source location. It seems like the places that expect this information to be absent could be trivially updated to disregard it after this patch, but synthesizing this from the available AST is much more challenging.

Thank you for the context and explanation! I don't feel like I have enough familiarity with this machinery to be an effective reviewer for signing off on anything. I've commented with some nits, but @rsmith should give the sign-off on this one.

include/clang/AST/PrettyPrinter.h
229

prints deduced -> prints the deduced

230

Add a whitespace before the left paren.

include/clang/Sema/Sema.h
7063–7066

I'd appreciate some comments as to why this is returning a pair and under what circumstances the type information will be different, because it's not likely to be obvious to anyone reading this header.

lib/Frontend/ASTConsumers.cpp
92

Since -> Because

That said, I am not convinced I agree with this being the default. "Prettier" is pretty subjective, and I'd rather our default be for clarity instead of brevity, at least here.

lib/Sema/SemaChecking.cpp
852 ↗(On Diff #167718)

That's truly strange. I bring it up because these sort of changes make it harder for reviewers to test changes locally by applying the patch themselves.

lib/Sema/SemaDecl.cpp
10912

Don't use auto as the type is not spelled out in the initialization.

lib/Sema/SemaStmt.cpp
1888

Formatting is off here (the * should bind to the right).

1975

Formatting.

3442–3443

Same -- you should probably run the patch through clang-format (https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting).

lib/Sema/SemaTemplateDeduction.cpp
4464

Null check?

A few more comments, mostly marking places of unintentional changes that we need to revert.
Hope it's not going past the point where the number of comments are not useful.

include/clang/Basic/DiagnosticSemaKinds.td
8616 ↗(On Diff #166279)

This looks unintentional. Should we revert?

lib/Sema/SemaChecking.cpp
852 ↗(On Diff #167718)

+1, we definitely need to revert this, happy to help figure out why this happened.

lib/Sema/SemaTemplateDeduction.cpp
4348–4349

Maybe remove the intermediate variable?

lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
354 ↗(On Diff #169885)

Why do we need this change? Are we fixing some particular regressions?
A comment would be useful.

test/SemaOpenCL/to_addr_builtin.cl
2 ↗(On Diff #169885)

Unrelated change.

48 ↗(On Diff #169885)

Unrelated change

122 ↗(On Diff #169885)

Another unrelated change

kadircet updated this revision to Diff 170215.Oct 19 2018, 10:21 AM
  • Keep only relavant changes and rebase

So in the middle of the patch we were just trying to figure out whether we are going to break a big assumption that lots of different components relied on but just didn't had any tests for. Maybe @rsmith would have more context about the behavior?

We used to update the auto type in both the semantic type of the variable and in the type-as-written. I changed that in r180808; it was a while back, and I didn't do a good job explaining in the commit message, but I think the only reason was consistency. For the case of a deduced return type in a function, we really want to leave the type in the TypeSourceInfo alone, because we need to track the "declared return type" for redeclaration matching:

auto f() { return 0; }
int f(); // error
auto f(); // OK

As we need to sometimes track the "declared type" of the entity as distinct from the semantic type, and as the TypeSourceInfo is intended to track the type as written, it made sense to consistently not update the auto type in the type source information (so the TSI has the declared type, and getType() returns the semantic type).

That said... I'm definitely sympathetic to the problem. When using an AST matcher, for instance, we want to simultaneously think about matching certain syntactic source constructs (eg, match a TypeLoc) and then ask about the semantic properties of the type (for which you want to know what the deduced type was for an auto type). If we update the TypeSourceInfo for variables but not for functions, is that going to deliver the value you're looking for here, or should we be looking for some way to deal with cases where we want the TSI and type to differ and still want to be able to work out correspondences between them?

kadircet abandoned this revision.Oct 22 2018, 1:10 AM
kadircet marked 2 inline comments as done.