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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
