adds `__disable_adl` attribute

[cjdb]

Summary

Certain library functions need to disable ADL. For example, the functions
in [range.iter.ops]/2 and [algorithms.requirements]/2 require functions
declared in namespaces 'std::ranges' aren't found by ADL, and that they
suppress ADL when called in an unqualified context (e.g. by way of a
_using-directive_). Conversations with developers on the #include <C++>
Discord channel identifies that there's a desire for this outside the
ranges library.

Libraries have been implementing these functions as function objects
with varying rules (e.g. libc++ and Microsoft/STL both try their best to
make the function objects appear as standard library function templates,
while libstdc++ makes them plain function objects). Having a large number
of types typically has a negative impact on both compile-times and progam
size.

This commit has seen compile times halved when the __disable_adl
attribute is applied instead of opting to use a function object.

[cjdb]

moves test from Sema to SemaCXX

I Noticed that SemaCXX is only a test directory, and that there's no corresponding SemaCXX in either include or lib.

[cjdb]

updates an inaccuracy in the commit message

[cjdb]

Looking at the output from Clang 14, I'm observing that a binary with 178 function templates is 13% the size of the one with 89 function objects. When only one function object is used vs all 178 function templates, the functions still win out, with the binary being 80% the size.

The AST also becomes substantially larger.

I ran time clang++-13 -c file.cpp -std=c++20 -Oz -DNDEBUG locally, a hundred times, and got the following results:

# Function objects
real mean:	0.07447
real median:	0.074
real stddev:	0.002267268191
	
sys mean:	0.01664
sys median:	0.016
sys stddev:	0.005569614534
	
user mean:	0.05785
user median:	0.057
user stddev:	0.005848896987

# Function templates
real mean:	0.06336
real median:	0.063
real stddev:	0.002076905235
	
sys mean:	0.01701
sys median:	0.017
sys stddev:	0.005545942188
	
user mean:	0.04645
user median:	0.047
user stddev:	0.005678908346

[cjdb]

In D129951#3657923, @cjdb wrote:

Looking at the output from Clang 14, I'm observing that a binary with 178 function templates is 13% the size of the one with 89 function objects. When only one function object is used vs all 178 function templates, the functions still win out, with the binary being 80% the size.

I wrote this quite late at night and confused total lines of assembly with program size. That's not accurate at all.

There doesn't seem to be a difference between the two when the optimiser is enabled, but with:

• -O0: there's a binary size difference of 24kB.
• -Og -g: there's a binary size difference of 32kB.
• -g: there's a binary size difference of 59kB.

[rsmith]

clang/lib/Sema/SemaOverload.cpp

9438

It would seem preferable to me to do the filtering in ArgumentDependentLookup itself rather than here (but I don't feel strongly about it).

9455–9459

I worry that this might break some stdlib implementation that finds helper functions via ADL in std::ranges somehow. Also, it seems desirable to make this opt-in for the stdlib implementation and indeed for end-user functions not in std::ranges.

Have you considered enabling this behavior with an attribute instead of by detecting whether the function is in std::ranges?

12837–12841

What should happen if a using declaration names one of these things? Should we care about the properties of the underlying declaration (eg, whether the target of the using declaration is in this namespace / has the attribute), or about the found decl (eg, whether the using declaration itself is in the namespace / has the attribute)?

Depending on the answer, we may need to check all declarations in the UnresolvedLookupExpr, not only the first one. For example, we could have an overload set that contains both a user-declared function and a using declaration that names a function in std::ranges here.

[cjdb]

clang/lib/Sema/SemaOverload.cpp

9438

Agreed. I tried to do it there, but was having issues getting it working. I'll give it a second go?

9455–9459

You're the second person to have suggested this, and I daresay Aaron will too, based on our prior discussion about this. We'd chatted about __disable_adl specifically, so that anyone who uses it won't be affected by a silent change from Clang to GCC: they'd instead get a break. I would prefer an attribute too.

My main concern is that other stdlib implementers would object to adding yet another annotation to their function calls (based on my failure to get libc++ to be as aggressive as Microsoft/STL is with [[nodiscard]]).

12837–12841

When found by unqualified ([basic.lookup.unqual]) name lookup for the postfix-expression in a function call ([expr.call]), they inhibit argument-dependent name lookup.

My interpretation of this is that both using-declarations and -directives are impacted (regardless of what the code says right now). [basic.lookup.unqual] doesn't specifically say anything about using-declarations, but I think p4 implies that they're included.

[cjdb]

• updates patch so that it meets what Aaron and I want, also meets most of Richard's feedback
• updates commit message

[cjdb]

clang/lib/Sema/SemaOverload.cpp

12764–12766

This and below need to be deleted.

[shafik]

clang/include/clang/Basic/AttrDocs.td

542 ↗

(On Diff #492234)

A lot of these look like unrelated changes.

clang/lib/Parse/ParseDecl.cpp

3788–3789 ↗

(On Diff #492234)

clang/lib/Sema/SemaOverload.cpp

6402–6403

Unrelated change?

12835

[cjdb]

responds to feedback

clang/include/clang/Basic/AttrDocs.td

542 ↗

(On Diff #492234)

I tend to not argue with autoformatters.

[cjdb]

Ping @aaron.ballman @rsmith

[cjdb]

Ping @aaron.ballman

[rsmith]

clang/include/clang/Basic/Attr.td

4132 ↗

(On Diff #492296)

Has this syntax been discussed already? If not, why did you choose keyword syntax instead of a normal attribute?

clang/include/clang/Basic/AttrDocs.td

6851 ↗

(On Diff #492296)

OK!

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

Maybe also global operator new / operator delete?

[cjdb]

clang/include/clang/Basic/Attr.td

4132 ↗

(On Diff #492296)

Aaron and I discussed this offline. I'd originally intended to do [[clang::disable_adl]], but Aaron pointed out that this would be problematic for all involved if someone uses a library in GCC, since the feature is implicitly turned off. If we use this syntax, then it forces libraries to acknowledge (and possibly document) that ADL is restricted on Clang, but potentially not GCC.

I will add a note to the documentation that I'm promising.

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

How does ADL even work in with the global namespace? Should it be invalid to apply here?

[aaron.ballman]

clang/include/clang/Basic/Attr.td

4132 ↗

(On Diff #492296)

Yup! The basic thinking I had is: if this attribute is ignored by an implementation, it's very possible that the user's code may change behavior -- if they're unlucky, it's a silent behavior change. However, if it's a keyword, then there's a syntax error and no chance for a silent behavior change.

If you think we need a more broad discussion of the syntax, that'd be fine by me -- it's possible there's a policy question hiding in here about when we want keywords and when we are fine with regular attribute syntax (type attributes are another source of these kinds of questions).

clang/include/clang/Basic/AttrDocs.td

6851 ↗

(On Diff #492296)

Btw, as a reviewer: thank you for this. I appreciate clear markings of "we're not done yet!" in the source.

542 ↗

(On Diff #492234)

We still ask that you don't commit unrelated changes (this was stripping trailing whitespace, which is often an editor setting) -- it makes git blame harder than it needs to be. Feel free to commit the whitespace fixes before/after the patch if you'd like, though!

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

Should this be isCXXInstanceMember() instead? Or do we intend to disallow this on static member functions?

[cor3ntin]

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

Static member functions would be qualified, and not involve ADL. This seems correct.

clang/lib/Sema/SemaOverload.cpp

13801–13802

White space only changes

[aaron.ballman]

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

Hmmm, I think they're *normally* qualified, but if you call the static function from within a member function, it doesn't have to be qualified.

[cor3ntin]

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

nvm, they can be found by adl from within member functions.

[philnik]

I don't think libc++ can adopt this without having to essentially duplicate our code, since GCC doesn't support __disable_adl (and AFAICT there is no coordination between GCC and Clang to add it to both). Have you tested what impact making the members static has? Both clang and GCC already support this as an extension back to C++11: https://godbolt.org/z/drE5v8nYo. Maybe it would make more sense to add an attribute [[clang::cpo]] instead to tell clang that the class should just be treated as an overload set? Make it requirements that the class is empty, there are no non-static member functions and the class is declared final and you should get any benefits without the major drawback of basically no portability. It's of course possible that I'm missing something major, but I think that general way would be a lot more acceptable. Any thoughts?

clang/lib/Sema/SemaOverload.cpp

9455–9459

FWIW we are getting more aggressive with adding [[nodiscard]]. We have extensions enabled by default and are (slowly) adding it to more places.

[cjdb]

In D129951#4178154, @philnik wrote:

I don't think libc++ can adopt this without having to essentially duplicate our code, since GCC doesn't support __disable_adl (and AFAICT there is no coordination between GCC and Clang to add it to both).

I haven't had a lot of time to drive this in Clang, let alone GCC. Even if libc++ can't ultimately use it (which would be sad), there are other libraries that can. For example, Abseil has a similar attitude towards functions as Niebloids, and could wrap it behind a macro.

Have you tested what impact making the members static has? Both clang and GCC already support this as an extension back to C++11: https://godbolt.org/z/drE5v8nYo.

A quick change to the original benchmark shows the AST for static operator() being substantially larger than a function template with ADL being disabled. I haven't properly benchmarked build time impact, but here's a quick one. The averages are below:

__disable_adl

real  0.1164
user  0.0706
sys   0.0488

static operator()

real  0.1272
user  0.081
sys   0.0488

It is worth acknowledging that the assembly output is now much closer with optimised flags (1.63x larger as opposed to 7.56x larger), but 1.26x larger with -g (this is down from 1.66x as non-static).

Maybe it would make more sense to add an attribute [[clang::cpo]] instead to tell clang that the class should just be treated as an overload set? Make it requirements that the class is empty, there are no non-static member functions and the class is declared final and you should get any benefits without the major drawback of basically no portability. It's of course possible that I'm missing something major, but I think that general way would be a lot more acceptable. Any thoughts?

CPOs and Niebloids are different things (and __disable_adl is for Niebloids, not CPOs), so any such attribute would need a different name. Having said that, a struct that hasn't has no base and is final only slightly improves the AST size with respect to the improvement by using an actual overload set. Finally, there would still be a portability issue because even if [[clang::niebloid]] works on Clang, there would still need to be coordination for it to work on GCC; otherwise GCC w/ libc++ mode would have copyable Niebloids; something that the original libc++ design worked hard to ensure wasn't possible so that a feature like this could exist.

It is again worth acknowledging that the assembly output in an optimised build would have parity, but a build using -O0 -g will still be ~1.26x larger.

[philnik]

In D129951#4178844, @cjdb wrote:

In D129951#4178154, @philnik wrote:

I don't think libc++ can adopt this without having to essentially duplicate our code, since GCC doesn't support __disable_adl (and AFAICT there is no coordination between GCC and Clang to add it to both).

I haven't had a lot of time to drive this in Clang, let alone GCC. Even if libc++ can't ultimately use it (which would be sad), there are other libraries that can. For example, Abseil has a similar attitude towards functions as Niebloids, and could wrap it behind a macro.

Abseil has the same support problem though AFAICT. In fact, most open source libraries don't just support clang.

Have you tested what impact making the members static has? Both clang and GCC already support this as an extension back to C++11: https://godbolt.org/z/drE5v8nYo.

A quick change to the original benchmark shows the AST for static operator() being substantially larger than a function template with ADL being disabled. I haven't properly benchmarked build time impact, but here's a quick one. The averages are below:

__disable_adl

real  0.1164
user  0.0706
sys   0.0488

static operator()

real  0.1272
user  0.081
sys   0.0488

It is worth acknowledging that the assembly output is now much closer with optimised flags (1.63x larger as opposed to 7.56x larger), but 1.26x larger with -g (this is down from 1.66x as non-static).

Couldn't that be overcome with some optimizations for Niebloids?

Maybe it would make more sense to add an attribute [[clang::cpo]] instead to tell clang that the class should just be treated as an overload set? Make it requirements that the class is empty, there are no non-static member functions and the class is declared final and you should get any benefits without the major drawback of basically no portability. It's of course possible that I'm missing something major, but I think that general way would be a lot more acceptable. Any thoughts?

CPOs and Niebloids are different things (and __disable_adl is for Niebloids, not CPOs), so any such attribute would need a different name.

Yes. Sorry for the conflation.

Having said that, a struct that hasn't has no base and is final only slightly improves the AST size with respect to the improvement by using an actual overload set. Finally, there would still be a portability issue because even if [[clang::niebloid]] works on Clang, there would still need to be coordination for it to work on GCC; otherwise GCC w/ libc++ mode would have copyable Niebloids; something that the original libc++ design worked hard to ensure wasn't possible so that a feature like this could exist.

I don't know about the original design, but at least the algorithms are copyable. I wouldn't be too concerned if that was different between clang and GCC, it's at least conforming in both cases. Regarding AST size, I don't know how representative LoC in the dump are, but shouldn't it be possible to overcome memory usage by modeling Niebloids in a different way than normal classes?

It is again worth acknowledging that the assembly output in an optimised build would have parity, but a build using -O0 -g will still be ~1.26x larger.

[cjdb]

In D129951#4178949, @philnik wrote:

In D129951#4178844, @cjdb wrote:

In D129951#4178154, @philnik wrote:

I don't think libc++ can adopt this without having to essentially duplicate our code, since GCC doesn't support __disable_adl (and AFAICT there is no coordination between GCC and Clang to add it to both).

I haven't had a lot of time to drive this in Clang, let alone GCC. Even if libc++ can't ultimately use it (which would be sad), there are other libraries that can. For example, Abseil has a similar attitude towards functions as Niebloids, and could wrap it behind a macro.

Abseil has the same support problem though AFAICT. In fact, most open source libraries don't just support clang.

Abseil already doesn't support calling unqualified functions, so this is a QoI improvement, rather than a correctness one like std::ranges::next. There's no portability issue because it's just a compatibility rule of using Abseil that can now get checked at compile time.

#if defined(__clang__) and __clang_major__ > 18
#  define ABSL_DISABLE_ADL __disable_adl
#else
#  define ABSL_DISABLE_ADL
#endif

namespace absl {
  template<class T>
  ABSL_DISABLE_ADL void func(T);
}

The reason Abseil can get away with it while libc++ cannot is because Abseil doesn't need to adhere to a standard saying "ADL shall not be involved", but rather has the attitude "if you want to painlessly use our library, always qualify your calls to our functions".

Have you tested what impact making the members static has? Both clang and GCC already support this as an extension back to C++11: https://godbolt.org/z/drE5v8nYo.

A quick change to the original benchmark shows the AST for static operator() being substantially larger than a function template with ADL being disabled. I haven't properly benchmarked build time impact, but here's a quick one. The averages are below:

__disable_adl

real  0.1164
user  0.0706
sys   0.0488

static operator()

real  0.1272
user  0.081
sys   0.0488

It is worth acknowledging that the assembly output is now much closer with optimised flags (1.63x larger as opposed to 7.56x larger), but 1.26x larger with -g (this is down from 1.66x as non-static).

Couldn't that be overcome with some optimizations for Niebloids?

Potentially, but not doing work is a better situation to be in than doing work and then having to do more work to evaluate whether or not to keep it.

Maybe it would make more sense to add an attribute [[clang::cpo]] instead to tell clang that the class should just be treated as an overload set? Make it requirements that the class is empty, there are no non-static member functions and the class is declared final and you should get any benefits without the major drawback of basically no portability. It's of course possible that I'm missing something major, but I think that general way would be a lot more acceptable. Any thoughts?

CPOs and Niebloids are different things (and __disable_adl is for Niebloids, not CPOs), so any such attribute would need a different name.

Yes. Sorry for the conflation.

Having said that, a struct that hasn't has no base and is final only slightly improves the AST size with respect to the improvement by using an actual overload set. Finally, there would still be a portability issue because even if [[clang::niebloid]] works on Clang, there would still need to be coordination for it to work on GCC; otherwise GCC w/ libc++ mode would have copyable Niebloids; something that the original libc++ design worked hard to ensure wasn't possible so that a feature like this could exist.

I don't know about the original design, but at least the algorithms are copyable. I wouldn't be too concerned if that was different between clang and GCC, it's at least conforming in both cases.

I'm deeply disappointed that libc++ moved away from using __function_like: that was an important part of preventing niebloid misuse. It isn't conforming to treat niebloids as function objects, which is what __function_like prevented (I just checked std::ranges::next and it seems that __function_like was completely removed).

Regarding AST size, I don't know how representative LoC in the dump are, but shouldn't it be possible to overcome memory usage by modeling Niebloids in a different way than normal classes?

Each line of the AST dump should represent a branch in the tree.

Notice that even if [we delete the entirety of main](https://godbolt.org/z/3zKza3T5P), you'll notice that the AST is still double the size when using structs over functions (since libc++ is no longer using __function_like, I've removed that from the linked comparison, but it clocked in at ~+1000 lines of AST). That's because the structs still need to be a part of the AST regardless of use.

shouldn't it be possible to overcome memory usage by modeling Niebloids in a different way than normal classes?

I think this would require a significant overhaul of how Clang processes structs.

It is again worth acknowledging that the assembly output in an optimised build would have parity, but a build using -O0 -g will still be ~1.26x larger.

[ldionne]

This is a really neat attribute! FWIW, I think we would most likely have used it in <ranges> if it were available back then. Assuming that GCC implemented it, I think we could consider changing to use this attribute. However:

1. This would technically be an ABI break, but this is probably not an issue in practice since I doubt this would bite any user, ever. We'd still have to think about it more seriously.
2. This would definitely be a source break for users, since they wouldn't be able to pass niebloids around as function arguments anymore. This one, I suspect, might be a deal breaker depending on how many users have started depending on that. I suspect this means the ship might have sailed for libc++ to use it in existing code.

FWIW, my main thought is that I would like to see this proposed as a WG21 proposal. This might end up an attribute or something else, I'm not sure. But it would address the issue of not all implementations providing the functionality. IMO this patch and the data gathered in it would be a great motivation for WG21 to do something (I also know there are other proposals in this domain).

Note: For history, we stopped making niebloids non-copyable in D116570. We originally did, but then that created divergence with libstdc++ and meant that we had to distinguish between CPOs and Niebloids in a way that seemed a bit arbitrary, so instead we went for a straightforward implementation. It is technically not as strict as it could be, though.

[ldionne]

In D129951#4179467, @cjdb wrote:

I'm deeply disappointed that libc++ moved away from using __function_like: that was an important part of preventing niebloid misuse. It isn't conforming to treat niebloids as function objects, which is what __function_like prevented (I just checked std::ranges::next and it seems that __function_like was completely removed).

Oops, it seems like my reply got into a race condition with yours. I am curious though, why is it non-conforming to treat niebloids as function objects? It is certainly more lax than required by the Standard, however we are allowed to make those copyable, aren't we? Does the Standard say that we *have* to make them non-usable as objects? That would change things for sure (not with this patch, but we'd probably want to try re-introducing __function_like, and we'd file a bug report against libstdc++ to do the same).

[cjdb]

In D129951#4179481, @ldionne wrote:

In D129951#4179467, @cjdb wrote:

I'm deeply disappointed that libc++ moved away from using __function_like: that was an important part of preventing niebloid misuse. It isn't conforming to treat niebloids as function objects, which is what __function_like prevented (I just checked std::ranges::next and it seems that __function_like was completely removed).

Oops, it seems like my reply got into a race condition with yours. I am curious though, why is it non-conforming to treat niebloids as function objects? It is certainly more lax than required by the Standard, however we are allowed to make those copyable, aren't we? Does the Standard say that we *have* to make them non-usable as objects? That would change things for sure (not with this patch, but we'd probably want to try re-introducing __function_like, and we'd file a bug report against libstdc++ to do the same).

"isn't conforming" is a bit too harsh in retrospect (this applies to every conversation I've brought this up in, although I meant that it allows users to write "non-conforming code"). A more accurate way to put this is: it is conforming on a per-implementation basis, but is non-portable due to namespace.std/p6. For example, a user who wants to use Microsoft/STL won't ever be able to take advantage of using std::ranges::next as a higher-order function (and could potentially have migration issues if they're porting to Windows), because their niebloids are derived from _Not_quite_object. _Not_quite_object's predecessor in cmcstl2 was the inspiration for __function_like.

As for a refresher on why this is the reason, it's because the functions in std::ranges should be functions, but we lack the technology to make them functions.

In D129951#4179474, @ldionne wrote:

This is a really neat attribute! FWIW, I think we would most likely have used it in <ranges> if it were available back then. Assuming that GCC implemented it, I think we could consider changing to use this attribute. However:

Thanks, glad you like it :-)
(I think the "however" bit got addressed above.)

FWIW, my main thought is that I would like to see this proposed as a WG21 proposal. This might end up an attribute or something else, I'm not sure. But it would address the issue of not all implementations providing the functionality. IMO this patch and the data gathered in it would be a great motivation for WG21 to do something (I also know there are other proposals in this domain).

I don't attend WG21 anymore, but could probably work with someone who is motivated enough to see it from Evolution through plenary. My preference is a specifier, rather than an attribute. For better, or for worse, most attributes are ignorable; this is certainly a property that should never be ignored.

[cor3ntin]

In D129951#4179596, @cjdb wrote:

In D129951#4179481, @ldionne wrote:

In D129951#4179467, @cjdb wrote:

I'm deeply disappointed that libc++ moved away from using __function_like: that was an important part of preventing niebloid misuse. It isn't conforming to treat niebloids as function objects, which is what __function_like prevented (I just checked std::ranges::next and it seems that __function_like was completely removed).

Oops, it seems like my reply got into a race condition with yours. I am curious though, why is it non-conforming to treat niebloids as function objects? It is certainly more lax than required by the Standard, however we are allowed to make those copyable, aren't we? Does the Standard say that we *have* to make them non-usable as objects? That would change things for sure (not with this patch, but we'd probably want to try re-introducing __function_like, and we'd file a bug report against libstdc++ to do the same).

"isn't conforming" is a bit too harsh in retrospect (this applies to every conversation I've brought this up in, although I meant that it allows users to write "non-conforming code"). A more accurate way to put this is: it is conforming on a per-implementation basis, but is non-portable due to namespace.std/p6. For example, a user who wants to use Microsoft/STL won't ever be able to take advantage of using std::ranges::next as a higher-order function (and could potentially have migration issues if they're porting to Windows), because their niebloids are derived from _Not_quite_object. _Not_quite_object's predecessor in cmcstl2 was the inspiration for __function_like.

As for a refresher on why this is the reason, it's because the functions in std::ranges should be functions, but we lack the technology to make them functions.

In D129951#4179474, @ldionne wrote:

This is a really neat attribute! FWIW, I think we would most likely have used it in <ranges> if it were available back then. Assuming that GCC implemented it, I think we could consider changing to use this attribute. However:

Thanks, glad you like it :-)
(I think the "however" bit got addressed above.)

FWIW, my main thought is that I would like to see this proposed as a WG21 proposal. This might end up an attribute or something else, I'm not sure. But it would address the issue of not all implementations providing the functionality. IMO this patch and the data gathered in it would be a great motivation for WG21 to do something (I also know there are other proposals in this domain).

I don't attend WG21 anymore, but could probably work with someone who is motivated enough to see it from Evolution through plenary. My preference is a specifier, rather than an attribute. For better, or for worse, most attributes are ignorable; this is certainly a property that should never be ignored.

@lewissbaker is the person you want to chat with!

[cjdb]

• undoes whitespace changes as requested
• documents feature

I think the only thing left is to address the global new/delete and static member function discussion, which should be quickly implementable!

[cjdb]

clang/lib/Sema/SemaDeclAttr.cpp

5756 ↗

(On Diff #492296)

Do we have a use-case for this? I'd rather start with global functions and add static member functions if a genuine need arises.

[cjdb]

Gentle ping :)

[cjdb]

Ping (moving my pings from Thursday afternoon to Monday mornings)

[aaron.ballman]

In D129951#4310046, @cjdb wrote:

Ping (moving my pings from Thursday afternoon to Monday mornings)

Apologies for the delay in responding, but I was actually silent in the hopes that the discussion around proposing to WG21 and how much general use this feature sees would materialize a bit more. https://clang.llvm.org/get_involved.html#criteria has two criteria that I think apply here: "Evidence of a significant user community" and "Representation within the appropriate governing organization". The fact that this could potentially be used by an STL or Abseil and drastically reduce compile times with a more direct approach than function objects suggests that there might be a significant user community that would benefit from this, but if those projects would struggle to adopt this feature because they need to handle older Clang versions or non-Clang compilers, that community may not materialize. Further, because this is being proposed as a keyword (which I think makes sense over an attribute because a correct program with this construct will not necessarily remain correct in its absence due to different lookup results) and it seems to be functionality that would be appropriate to standardize, there should be some collaboration with WG21 if only to hear back "we don't see a reason such an extension would be a problem for us or conflict with existing efforts".

Specific to this review, however, this is missing documentation in LanguageExtensions.rst for the feature, how to use it, etc. as well as release notes. How does this marking fit into the language? How does it impact redeclaration merging (do all declarations have to have the marking, or is it additive like attributes often are?), how does it impact ODR (do declarations have to match across TU boundaries?), is this a declaration specifier or something else (can you do void __disable_adl func() or does it have to be __disable_adl void func();?), that sort of stuff.

clang/include/clang/AST/DeclBase.h

public:
   TranslationUnitDecl *getTranslationUnitDecl();
   const TranslationUnitDecl *getTranslationUnitDecl() const {
     return const_cast<Decl*>(this)->getTranslationUnitDecl();
   }
 
   bool isInAnonymousNamespace() const;
 
   bool isInStdNamespace() const;
+  bool isInStdRangesNamespace() const;
 
   ASTContext &getASTContext() const LLVM_READONLY;
 
   /// Helper to get the language options from the ASTContext.
   /// Defined out of line to avoid depending on ASTContext.h.
   const LangOptions &getLangOpts() const LLVM_READONLY;
 
   void setAccess(AccessSpecifier AS) {
public:
   bool isRecord() const {
     return getDeclKind() >= Decl::firstRecord &&
            getDeclKind() <= Decl::lastRecord;
   }
 
   bool isNamespace() const { return getDeclKind() == Decl::Namespace; }
 
   bool isStdNamespace() const;
+  bool isStdRangesNamespace() const;
 
   bool isInlineNamespace() const;
 
   /// Determines whether this context is dependent on a
   /// template parameter.
   bool isDependentContext() const;
 
   /// isTransparentContext - Determines whether this context is a

clang/lib/AST/DeclBase.cpp

bool Decl::isInAnonymousNamespace() const {
   return false;
 }
 
 bool Decl::isInStdNamespace() const {
   const DeclContext *DC = getDeclContext();
   return DC && DC->isStdNamespace();
 }
 
+bool Decl::isInStdRangesNamespace() const {
+  const DeclContext *DC = getDeclContext();
+  return DC && DC->isStdRangesNamespace();
+}
+
 TranslationUnitDecl *Decl::getTranslationUnitDecl() {
   if (auto *TUD = dyn_cast<TranslationUnitDecl>(this))
     return TUD;
 
   DeclContext *DC = getDeclContext();
   assert(DC && "This decl is not contained in a translation unit!");
 
   while (!DC->isTranslationUnit()) {
bool DeclContext::isStdNamespace() const {
 
   if (!getParent()->getRedeclContext()->isTranslationUnit())
     return false;
 
   const IdentifierInfo *II = ND->getIdentifier();
   return II && II->isStr("std");
 }
 
+bool DeclContext::isStdRangesNamespace() const {
+  if (!isNamespace())
+    return false;
+
+  const auto *ND = cast<NamespaceDecl>(this);
+  if (!ND->getParent()->isStdNamespace()) {
+    return false;
+  }
+
+  const IdentifierInfo *II = ND->getIdentifier();
+  return II && II->isStr("ranges");
+}
+
 bool DeclContext::isDependentContext() const {
   if (isFileContext())
     return false;
 
   if (isa<ClassTemplatePartialSpecializationDecl>(this))
     return true;
 
   if (const auto *Record = dyn_cast<CXXRecordDecl>(this)) {

clang/lib/Sema/SemaOverload.cpp

void Sema::AddOverloadCandidate(
   // Explicit functions are not actually candidates at all if we're not
   // allowing them in this context, but keep them around so we can point
   // to them in diagnostics.
   if (!AllowExplicit && ExplicitSpecifier::getFromDecl(Function).isExplicit()) {
     Candidate.Viable = false;
     Candidate.FailureKind = ovl_fail_explicit;
     return;
   }
 
   if (Function->isMultiVersion() && Function->hasAttr<TargetAttr>() &&
       !Function->getAttr<TargetAttr>()->isDefaultVersion()) {
     Candidate.Viable = false;
     Candidate.FailureKind = ovl_non_default_multiversion_function;
     return;
   }
 
   if (Constructor) {
     // C++ [class.copy]p3:
Sema::AddArgumentDependentLookupCandidates(DeclarationName Name,
   // FIXME: This approach for uniquing ADL results (and removing
   // redundant candidates from the set) relies on pointer-equality,
   // which means we need to key off the canonical decl.  However,
   // always going back to the canonical decl might not get us the
   // right set of default arguments.  What default arguments are
   // we supposed to consider on ADL candidates, anyway?
 
   // FIXME: Pass in the explicit template arguments?
   ArgumentDependentLookup(Name, Loc, Args, Fns);
 
   // Erase all of the candidates we already knew about.
   for (OverloadCandidateSet::iterator Cand = CandidateSet.begin(),
                                    CandEnd = CandidateSet.end();
        Cand != CandEnd; ++Cand)
     if (Cand->Function) {
       Fns.erase(Cand->Function);
       if (FunctionTemplateDecl *FunTmpl = Cand->Function->getPrimaryTemplate())
         Fns.erase(FunTmpl);
     }
 
   // For each of the ADL candidates we found, add it to the overload
   // set.
   for (ADLResult::iterator I = Fns.begin(), E = Fns.end(); I != E; ++I) {
     DeclAccessPair FoundDecl = DeclAccessPair::make(*I, AS_none);
 
+    // Functions in 'std::ranges' are hidden from ADL per [range.iter.ops]/2 and
+    // [algorithms.requirements]/2.
+    if ((*I)->isInStdRangesNamespace() &&
+        Name.getNameKind() == DeclarationName::NameKind::Identifier)
+      continue;
+
     if (FunctionDecl *FD = dyn_cast<FunctionDecl>(*I)) {
       if (ExplicitTemplateArgs)
         continue;
 
       AddOverloadCandidate(
           FD, FoundDecl, Args, CandidateSet, /*SuppressUserConversions=*/false,
           PartialOverloading, /*AllowExplicit=*/true,
           /*AllowExplicitConversion=*/false, ADLCallKind::UsesADL);

 /// neither template is more specialized than the other.
 /// [over.match.best]p2.6
 /// F1 and F2 are non-template functions with the same parameter-type-lists,
 /// and F1 is more constrained than F2 [...]
 static bool canCompareFunctionConstraints(Sema &S,
                                           const OverloadCandidate &Cand1,
                                           const OverloadCandidate &Cand2) {
   // FIXME: Per P2113R0 we also need to compare the template parameter lists
-  // when comparing template functions. 
+  // when comparing template functions.
   if (Cand1.Function && Cand2.Function && Cand1.Function->hasPrototype() &&
       Cand2.Function->hasPrototype()) {
     auto *PT1 = cast<FunctionProtoType>(Cand1.Function->getFunctionType());
     auto *PT2 = cast<FunctionProtoType>(Cand2.Function->getFunctionType());
     if (PT1->getNumParams() == PT2->getNumParams() &&
         PT1->isVariadic() == PT2->isVariadic() &&
         S.FunctionParamTypesAreEqual(PT1, PT2, nullptr,
                                      Cand1.isReversed() ^ Cand2.isReversed()))
static void AddOverloadedCallCandidate(Sema &S,
   NamedDecl *Callee = FoundDecl.getDecl();
   if (isa<UsingShadowDecl>(Callee))
     Callee = cast<UsingShadowDecl>(Callee)->getTargetDecl();
 
   if (FunctionDecl *Func = dyn_cast<FunctionDecl>(Callee)) {
     if (ExplicitTemplateArgs) {
       assert(!KnownValid && "Explicit template arguments?");
       return;
     }
     // Prevent ill-formed function decls to be added as overload candidates.
     if (!isa<FunctionProtoType>(Func->getType()->getAs<FunctionType>()))
       return;
 
     S.AddOverloadCandidate(Func, FoundDecl, Args, CandidateSet,
                            /*SuppressUserConversions=*/false,
                            PartialOverloading);
     return;
   }
 
if (ULE->hasExplicitTemplateArgs()) {
     ULE->copyTemplateArgumentsInto(TABuffer);
     ExplicitTemplateArgs = &TABuffer;
   }
 
   for (UnresolvedLookupExpr::decls_iterator I = ULE->decls_begin(),
          E = ULE->decls_end(); I != E; ++I)
     AddOverloadedCallCandidate(*this, I.getPair(), ExplicitTemplateArgs, Args,
                                CandidateSet, PartialOverloading,
                                /*KnownValid*/ true);
 
+  // Functions in 'std::ranges' inhibit ADL per [range.iter.ops]/2 and
+  // [algorithms.requirements]/2.
+  if (!ULE->decls().empty() && ULE->decls_begin()->isInStdRangesNamespace() &&
+      ULE->getName().getNameKind() == DeclarationName::NameKind::Identifier)
+    return;
+
   if (ULE->requiresADL())
     AddArgumentDependentLookupCandidates(ULE->getName(), ULE->getExprLoc(),
                                          Args, ExplicitTemplateArgs,
                                          CandidateSet, PartialOverloading);
 }
 
 /// Add the call candidates from the given set of lookup results to the given
 /// overload set. Non-function lookup results are ignored.
case OR_Success: {
                 AmbiguousWith.size() == 1 &&
                 declaresSameEntity(AmbiguousWith.front(), FnDecl);
             Diag(OpLoc, diag::ext_ovl_ambiguous_oper_binary_reversed)
                 << BinaryOperator::getOpcodeStr(Opc)
                 << Args[0]->getType() << Args[1]->getType() << AmbiguousWithSelf
                 << Args[0]->getSourceRange() << Args[1]->getSourceRange();
             if (AmbiguousWithSelf) {
               Diag(FnDecl->getLocation(),
                    diag::note_ovl_ambiguous_oper_binary_reversed_self);
             } else {
               Diag(FnDecl->getLocation(),
                    diag::note_ovl_ambiguous_oper_binary_selected_candidate);
               for (auto *F : AmbiguousWith)
                 Diag(F->getLocation(),
                      diag::note_ovl_ambiguous_oper_binary_reversed_candidate);
             }
           }
         }

clang/test/SemaCXX/disable-adl.cpp

+// RUN: %clang_cc1 %s -fsyntax-only -verify
+
+// [e-mail]:* 2{{}}
+
+namespace std {
+  struct S1 {};
+  S1 inhibited(S1);
+
+  namespace ranges {
+    struct S2 {};
+    void hidden(S2);
+    int inhibited(S1);
+  }
+}
+
+void test_functions() {
+  hidden(std::ranges::S2{});
+  // expected-error@-1{{use of undeclared identifier 'hidden'; did you mean 'std::ranges::hidden'?}}
+
+  using namespace std::ranges;
+  int x = inhibited(std::S1{}); // no error
+}
+
+namespace std {
+  template<typename T>
+  S1 inhibited_template(T);
+
+  namespace ranges {
+    template<typename T>
+    void hidden_template(T);
+
+    template<typename T>
+    int inhibited_template(T);
+  }
+}
+
+void test_function_templates() {
+  hidden_template(std::ranges::S2{});
+  // expected-error@-1{{use of undeclared identifier 'hidden_template'; did you mean 'std::ranges::hidden_template'?}}
+
+  using namespace std::ranges;
+  int x = inhibited_template(std::S1{});
+}
+
+namespace std {
+  S1 inhibited_mixed(S1);
+
+  namespace ranges {
+    template<typename T>
+    int inhibited_mixed(T);
+  }
+}
+
+void test_mixed() {
+  using namespace std::ranges;
+  int x = inhibited_mixed(std::S1{});
+}
+
+// Should be covered by the hidden functions checks, but just to be sure.
+void test_ranges_hidden() {
+  {
+    std::S1 a = inhibited(std::S1{});
+    std::S1 b = inhibited_template(std::S1{});
+    std::S1 c = inhibited_mixed(std::S1{});
+  }
+  {
+    using namespace std;
+    std::S1 a = inhibited(std::S1{});
+    std::S1 b = inhibited_template(std::S1{});
+    std::S1 c = inhibited_mixed(std::S1{});
+  }
+}
+
+namespace std {
+  namespace ranges {
+    void operator-(S2);
+
+    struct hidden_friend_operator {
+      friend void operator-(hidden_friend_operator i, int) {}
+    };
+
+    struct hidden_friend_swap {
+      friend void swap(hidden_friend_swap, hidden_friend_swap) {}
+    };
+  }
+}
+
+void test_friends_and_operators() {
+  -std::ranges::S2{};                        // no error
+  std::ranges::hidden_friend_operator{} - 1; // no error
+
+  swap(std::ranges::hidden_friend_swap{}, std::ranges::hidden_friend_swap{});
+  // expected-error@-1{{use of undeclared identifier 'swap'}}
+}