Rebase

• Handle expressions as unevaluated operands
• Numerous fixes to documentation wording
• Add release notes entry
• Prevent generic "unknown argument" diagnostic from being issued when other more specific diagnostics have been emitted
• Add more tests

Thank you for review!

ping

In D140996#4189452, @bolshakov-a wrote:

Sorry! It's my first time using Phabricator. Maybe, the problem occurs because I've solved the issue with Arcanist just by means of copy-pasting patches into "Update Diff" Web GUI form.

• Diagnose dependent expressions
• Move AST dumping from parser to sema
• Add documentation
• Add tests

LGTM
I got confused at first why this fix is done in a function named getSubobjectSizeInBits, and why do we calculate size to produce a boolean value in the end. Then I realized that this function returns number of bits of value representation, or std::nullopt if there are any padding bits, and we take advantage of the latter to implement hasUniqueObjectRepresentations. I guess I'm either missing some context or that function could be named better (not in this patch, of course).

Thank you for reviewing this!

Thank you for the patch.
Any plans to backport this to 16.x branch?

Remove two examples with identity<B> for reasons explained in D142316#4121079.

Move CWG2385 out to D142315, because it's been resolved prior to P1787, and it's easier to explain it there.

Move CWG2385 ("na") from D142316 into this patch. It makes more sense to put it here, because it fixes inconsistent wording introduced by CWG1111 resolution.

Change status from "6" to "yes" since "ambiguous-member-template" warning is a false-positive now.

In D142316#4073771, @shafik wrote:

You mention CWG2385 as na but you don't explain how it was resolved, was it superceded by p1787.

LGTM
I checked clang-tidy docs for this kind of broken references, but found nothing else.

In D142315#4073782, @erichkeane wrote:

I didn't internalize that it was 'just a warning' (it was a -error in the test above), we should have a task for someone to remove that warning as it is no longer ambiguous. But I don't think it makes it 'partial' here anymore.

Thanks to all of you for your time to review this.

Add example from [over.match.best]/4, and mark CWG418 as not available

@shafik does this imply that example from [over.match.best]/4 should be included in this patch?

I opened #59363 on bug tracker.
What should I do about this patch then? I believe availability no should come with a failing test. Should I include example from [over.match.best]/4 as another example in the test?

I think the relevant change from p1787 is to dcl.fct.default p4, specifically:

... Declarations that inhabit different scopes have completely distinct sets of default arguments ...

Reuse a part of CWG218 test, adding cross-references.

@shafik Would it be fine by you to proceed without changes?

Add a comment per @shafik request

@aaron.ballman do you think it is worth it to provide a link to p1787 as well? I know you can just goto the issue and see that but it feels helpful. I actually missed this at first b/c I usually goto end of the issue to look for the resolution and was confused.

We can do it the following way then: dr405: yes \n NB: also dup 218.

That would be fine by me!

I think this is perfectly fine to have a duplicated test case, I agree with Aaron, we should not invent duplicated status ourselves.
Adding a comment in the test like "Note: this test is identical to the one for CWG405" would be a good idea

There are many editorial issues that ended up as defect reports, you could probably batch many of them in subsequent PR

Thank you for suggestion. I'm being on a safer side at the moment, because CWG405 raised more questions than I anticipated.
I'll also wait until tomorrow morning (≈18 hours from now) to let everybody interested comment on this, to avoid situations like the one with CWG360 yesterday.

I don't think we should mark it as a dup -- we want the status in our tests to match the status on the official document, otherwise things get confusing.

We can do it the following way then: // dr405: yes \n // NB: also dup 218.
Do I understand correctly that superseded status should be used if and only if it's used in official document as well?

Is it fine that we're marking CWG405 as a duplicate even though it's not mentioned as such in official publication?

run make_cxx_dr_status

Get rid of unwanted changes supposedly caused by arc diff

Add examples with dependent types, and rearrange using declarations to group errors and notes.

Discord feels perfect to me for this kind of questions. What's left is to get past a broken bot for agreeing with code of conduct.

Thank you!

Among the worst parts of this paper are references to mailing list and EDG wiki, which I don't have access to. But I still managed to dig everything up, and ready to explain if requested. No tests were copied blindly from issues.

@aaron.ballman Following example of other DR tests, I was reluctant to add relevant comments, e.g. wording. But I can provide it going forward or even update this patch.

Can I kindly ask you to commit this?
I guess I can ask for commit access after this patch, and not bother you any further.

Remove WIP for another patch

Sorry, some other WIP got in there. I'll remove it in a moment

Incorporate D138835 (correctly this time around)

Sorry, I messed up diff update