[clang] [clang] Implement CTAD for type alias template. (PR #77890)

[Haojian Wu via cfe-commits]

hokein wrote:

Thanks for the summary.

> We do not think a feature flag is a good fit.
> 
> * Until clang 19 ships (in 6 months) we do not need to stabilize the feature (but ofc we should avoid regressions, which we would not find if hidden behind a flag), and the flag does not guarantee existing features are not impacted.
> 

I think this works fine with clang open-source release cycles (18 release was just cut, we have 6 months from now to polish this feature). However, this is not applicable for our internal case. At Google, we have used C++20 in production, and we have our own toolchain release cycles (which stay close to upstream main). Checking in an in-development C++20 feature without a proper safeguard poses risks to users (clang crashes, incorrect compilations, and other issues).

So having a temporary flag is useful, it enables us to incrementally test and experiment it without compromising the experience for most users. 

> And if we break trunk, we revert, you get extra test cases... it's perfectly fine

We could revert the whole patch when things are broken (and it is what we usually do). But I'm not sure revert/reland a big patch back and forth is a good idea.

This also brings a general question: what level of quality should we require from experimental features in HEAD?

> We do that for about every feature that is not concept/module scale (and then again, these things were tses), and this isn't big enough to warrant a novel approach.

Yeah, I agree that this is a narrow feature. Given that this feature is very late to the party, and C++20 has been used in some productions, I think it is probably reasonable to have a flag.

> I still think we should land this soon and we can start a review whenever you are ready.
If you want to land it in an incomplete state, we just need to make sure we have a good collective understanding of the remaining work that would need to be done to bring the feature to completion (tests with fix me, issues, etc)

+1, I think the current state should be good enough and ready for review. The remaining big piece (see the FIXME) is to implement the associated constraints (over.match.class.deduct#3.3).


https://github.com/llvm/llvm-project/pull/77890