[clang] [Clang] Add [[clang::complete_on_member_instantiation]] (PR #211231)

[Erich Keane via cfe-commits]

erichkeane wrote:

> I could see that it would be useful to have an attribute `[[clang::container(T, additional-properties)]]`. The type this is applied to would be guaranteed to fulfill [container.requirements] as well as whatever other properties `additional-properties` require. Initial ideas for `additional-properties`:
> 
>     * "sequence-container" for [sequence.reqmts]
> 
>     * "node-container" for [container.node]
> 
>     * "associative-container" for [associative.reqmts]
> 
>     * "reversible-container" for [container.rev.reqmts]
> 
>     * "allocator-aware-container"(Alloc) for [container.alloc.reqmts]
> 
>     * "enforce-allocator-requirements" to diagnose incorrect allocators
> 
>     * "enforce-completeness-requirements" for the initial goal of this patch
> 
> 
> We of course wouldn't want to allow nonsensical combinations like "sequence-container" and "associative-container" or "enforece-allocator-requirements" without "allocator-aware-container".
> 
> I'm not quite sure whether "allocator-aware-container" should be done in that way, but that seems like a rather niche detail.
> 
> WDYT? Is that a direction worth pursuing?

The first 5 are exactly the kind of thing I was getting at... something written in source that guarantees to the compiler that, even though we can't do the analysis, the author of it promises is the case.

The last 2 (and I realize are the important ones to you) are a different beast, in that they aren't guarantees to the compilers, but requests for the compiler to 'check'.  I'm still very sympathetic to the intent of the original patch here, I can see the attraction of an `enable-if-but-with-non-SFINAE-error` type requirement on a function template for the purposes of better diags.  I just don't know what ergonomics are right for it yet.

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