mizvekov added a comment. In D133468#3803449 <https://reviews.llvm.org/D133468#3803449>, @sammccall wrote:
> The descriptions here are pretty general and opaque nad it's hard to follow > what this means in practice. > It sounds like the motivating cases are to do with template instantiation - > can we see them? e.g. code + proposed diagnostics before/after, or some other > description of how this will be used? > The ternary-expression stuff doesn't seem compelling enough to justify the > complexity here without more context. (Probably others have this context, but > future readers of this code won't). Yeah, the ternary-expression stuff is just a test case for this change, it's not a justification per se. What we need this is for the template specialization resugaring work: https://reviews.llvm.org/D127695 I will give an example using a Typedef for exposition, but the same motivation applies with UsingType. Say we have this code: template <class T> struct A { using type1 = T; }; using Int = int; using type2 = A<Int>; See this example live (with that resugaring patch) at: https://godbolt.org/z/jP64Pern8 We want the underlying type of `type2` to have that `Int` sugar. It would also be good if we could keep the TypedefType sugar referencing the instantiation of `type1` from the `A<int>` template. The problem here is that the TypedefType is currently limited to having the declaration's underlying type, which is just from an instantiation of `A<int>`, and knows nothing about camel case `Int`. This is similar to the infamous problem with `std::string` turning into `std::basic_string` in templates. We could emit a new TypedefDecl with the underlying type that we want, but creating declarations is expensive, so we want to avoid that. We could create a new AST node that represented more accurately what was happening. But the question is, is this worth the cost? Do you see use cases for this yourself? We want resugaring to be cheap and introduce as little changes in the AST as possible, to get a better chance of affording to have it to be on all the time. If we introduce new nodes with more information, that might increase the cost and complexity, and it's hard to justify without an use case. > My intuition is that if a type desugars to something other than what the > UsingDecl points to, then UsingType isn't the right model - it seems we're > trying to shim some extra indirection that doesn't have much to do with > `using`. Maybe we can isolate the complexity better in a new sugar typenode, > rather than weakening the semantics of Using/TypedefType? > But I can easily imagine I'm missing the point and concrete examples might > clear it up. It does not seem too far fetched that the UsingType could point to a resugared version of the declaration's underlying type, without having to create a new declaration. The other options I can think of are: - Introduce new AST nodes. - Simply strip the TypedefType/UsingType. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133468/new/ https://reviews.llvm.org/D133468 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
