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

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In https://reviews.llvm.org/D52301#1267163, @kadircet wrote:

> 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?


Repository:
  rC Clang

https://reviews.llvm.org/D52301