ping

Superseded by D127233, D127259, rG7f8d844df5e9

• rebase

In D127259#4156314, @erichkeane wrote:

I don't see much compile-time concerns myself,

In D139837#4067208, @ayzhao wrote:

Thanks for your effort on this!

FYI I landed parenthesized aggregate initialization in D141546, so CTAD for that feature should no longer be blocked.

• update cxx_status.html

In D139837#3989814, @cor3ntin wrote:

Hey. Thanks a lot for working on this.
I did a first pass, looking at mostly style issues, looking at conformance will probably take me a lot more time, but i think this looks pretty good overall

• Address Corentin's comments

format

• rebase

LGTM

In D136975#3899717, @erichkeane wrote:

In D136975#3899703, @ychen wrote:

Thanks for the patch. It looks good to me.

About

Note that we DO need to be careful to make sure we still check
constraints properly that are caused by a previous constraint, but not
derived from (such as when a check causes us to check special member
function generation), so we cannot use the existing logic to see if this
is being instantiated.

For the derived from case, I think we also end up getting the infinite recursion? Why do we disable the check for the derived from case?

Can you clarify what you mean? I'm not sure which test case you're speaking of.

Thanks for the patch. It looks good to me.

• remove unnecessary check

• rebase

In D136545#3877899, @royjacobson wrote:

LGTM, thanks for picking it up! I wonder how much effect this has on compilation times given that SubsumptionCache caches subsumption by the Decl * pair...

• do the same when 1. taking the address of a non-template function (with a test) 2. computing SMF eligibility (unfortunately it's hard to compose a test, suggestions are appreciated).
• restore the removed test case

ping?

Looks straightforward to me with one suggestion.

• add a release note.

@mizvekov Thanks for the review and provided valuable feedback.

• DR2565 is fully implemented.

• update Release notes
• remove obsolete CodeGen tests which was used to test ClangABICompat checks, similar Sema tests are already in place.

In D128750#3864612, @mizvekov wrote:

Is the pre-commit CI failure here related to the patch?

• rebase

• rebase

In D134507#3856956, @tahonermann wrote:

Per further discussions in D128745, this is not needed.

I agree that the code change is not needed. I think it is worth keeping the test though (modified to verify the expected ambiguity).

• use getTemplateArgs

• skip non-dependent NTTP comparison because they're equivalent (match GCC)

In D128750#3854675, @hubert.reinterpretcast wrote:

I reached out to the GCC author to confirm that the committee acknowledges that there should be a change to temp.func.order p6.2.1, but no consensus on what changes to make [3].

A more accurate description is that some changes elsewhere to overload resolution are probably needed, but no solution has been developed sufficiently.

Per further discussions in D128745, this is not needed.

In D128745#3851458, @rjmccall wrote:

Was this change in LLVM 15, or is it still unreleased?

@mizvekov it turns out I don't need that code anymore. Thanks.

• remove dead code.

LGTM.

In D128745#3850667, @hubert.reinterpretcast wrote:

In D128745#3834435, @ychen wrote:

New flag or not, as long as we allow users to use the old behavior, it is already fracturing the ecosystem. Do you mean (1) we shouldn't give the user the choices or (2) we allow users to use the old behavior but only for a few releases and then remove the flag? I think (1) is a little bit harsh but I would not say it is disruptive. (2) is more user-friendly.

(1) has been the default absent information to indicate that the new behaviour is not ready for deployment (because it would cause widespread disruption). To consider alternatives would require information about the nature of the deployment difficulties.

Hi @mizvekov , after D135088, this patch is ready.

Looks good to me except for one nit. And the test still fails on Windows for some reason.

In D135115#3839547, @HazardyKnusperkeks wrote:

Except for the @<file> part. (Which also isn't handles by clang-format, or is it?)

• rebased on D135088

• rebase

• rebase

D135088 was landed instead.

• make corresponding change in the commandline

• address comments

In D128745#3834454, @tahonermann wrote:

Is it known what gcc and Microsoft maintainers are going to do with these DRs? I don't see any recent changes in gcc, but the following is interesting...

In D128745#3834387, @hubert.reinterpretcast wrote:

In D128745#3834313, @ychen wrote:

I think the consensus is some flag is needed to put it back to legacy behavior just in case.

I am not sure there is strong consensus to add a flag "just in case". Historically, many DRs had effects on overload resolution (via SFINAE or otherwise). Once we start adding flags "just in case", we might end up having a lot of them. These flags can exacerbate fracturing of the ecosystem.