[clang] [clang] Add `clang::behaves_like_std(...)` attribute (PR #76596)

via cfe-commits cfe-commits at lists.llvm.org
Sun Dec 31 00:14:41 PST 2023


cor3ntin wrote:

I struggle to understand the motivation here: If you are not using a standard library implementation at all and instead act as your own standard library vendor, just providing a declaration of move / forward should be enough.

The concern about ABI tags only come up if the STL is indeed included, and you seem to say it never is. Can you explain a bit more why you are concerned about how things are defined in libc++?

@philnik777 Do `std::move`/ `std::forward` etc actually need an abi tag? Maybe we should simply not set a tag given that clang / gcc replace call to these functions.

I prefer this approach over `msvc::intrinsic` because at least it gives control over how the call is replaced.
Ie, I think the semantics you'd want is really a `substitute_with_builtin` (presumably just after lookup).  `intrinsic`s a very generic name with a very narrow set of use cases (some casts).

More general observations on the "using c++ without the STL thing":
I don't think this is a major consideration of the language/standard committee going forward.
As you noted, there exist a lot of type traits/functions which are or should be backed by compiler magic.
And we are actually extending the set of freestanding function dramatically. Reflection will also have a dependency on the STL

That being said, I understand the pain. 
Modules should ease that pain - I don't have a good visibility on that but my understanding is that some progress is being made. In the meantime, I wonder if there is room for a lighter utility header, one without pair/rel_ops, maybe that would help.

I think we could also extend the set of std functions replaced in the front end if we can show it would have measurable compile times improvements (ie to_integer, as_const, to_underlying, etc).


PS: I appreciate that this patch comes with complete documentation :)


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


More information about the cfe-commits mailing list