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

9584

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

9601–9605

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?

13012–13016

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

9584

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

9601–9605

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]]).

13012–13016

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

12931–12933

This and below need to be deleted.

[shafik]

clang/include/clang/Basic/AttrDocs.td

542

A lot of these look like unrelated changes.

clang/lib/Parse/ParseDecl.cpp

3788–3789

clang/lib/Sema/SemaOverload.cpp

6514

Unrelated change?

13010

[cjdb]

responds to feedback

clang/include/clang/Basic/AttrDocs.td

542

I tend to not argue with autoformatters.

[cjdb]

Ping @aaron.ballman @rsmith

[cjdb]

Ping @aaron.ballman

[rsmith]

clang/include/clang/Basic/Attr.td

4132

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

OK!

clang/lib/Sema/SemaDeclAttr.cpp

5756

Maybe also global operator new / operator delete?

[cjdb]

clang/include/clang/Basic/Attr.td

4132

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

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

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

542

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!

6851

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

clang/lib/Sema/SemaDeclAttr.cpp

5756

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

[cor3ntin]

clang/lib/Sema/SemaDeclAttr.cpp

5756

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

clang/lib/Sema/SemaOverload.cpp

13972–13973

White space only changes

[aaron.ballman]

clang/lib/Sema/SemaDeclAttr.cpp

5756

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

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

9601–9605

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

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/ExprCXX.h

static UnresolvedLookupExpr *CreateEmpty(const ASTContext &Context,
                                            unsigned NumResults,
                                            bool HasTemplateKWAndArgsInfo,
                                            unsigned NumTemplateArgs);
 
   /// True if this declaration should be extended by
   /// argument-dependent lookup.
   bool requiresADL() const { return UnresolvedLookupExprBits.RequiresADL; }
 
+  /// A function marked '__disable_adl' inhibits ADL.
+  void disableADL() { UnresolvedLookupExprBits.RequiresADL = false; }
+
   /// True if this lookup is overloaded.
   bool isOverloaded() const { return UnresolvedLookupExprBits.Overloaded; }
 
   /// Gets the 'naming class' (in the sense of C++0x
   /// [class.access.base]p5) of the lookup.  This is the scope
   /// that was looked in to find these results.
   CXXRecordDecl *getNamingClass() { return NamingClass; }
   const CXXRecordDecl *getNamingClass() const { return NamingClass; }

clang/include/clang/Basic/Attr.td

def FunctionReturnThunks : InheritableAttr,
   let Subjects = SubjectList<[Function]>;
   let Documentation = [FunctionReturnThunksDocs];
 }
 def ReadOnlyPlacement : InheritableAttr {
   let Spellings = [Clang<"enforce_read_only_placement">];
   let Subjects = SubjectList<[Record]>;
   let Documentation = [ReadOnlyPlacementDocs];
 }
+
+def DisableADL : InheritableAttr {
+  let Spellings = [Keyword<"__disable_adl">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [DisableADLDocs];
+  let LangOpts = [CPlusPlus];
+}

clang/include/clang/Basic/AttrDocs.td

 migration for code using ``[[noreturn]]`` after including ``<stdnoreturn.h>``.
   }];
 }
 
 def NoMergeDocs : Documentation {
   let Category = DocCatStmt;
   let Content = [{
 If a statement is marked ``nomerge`` and contains call expressions, those call
-expressions inside the statement will not be merged during optimization. This 
+expressions inside the statement will not be merged during optimization. This
 attribute can be used to prevent the optimizer from obscuring the source
 location of certain calls. For example, it will prevent tail merging otherwise
 identical code sequences that raise an exception or terminate the program. Tail
 merging normally reduces the precision of source location information, making
 stack traces less useful for debugging. This attribute gives the user control
-over the tradeoff between code size and debug information precision. 
+over the tradeoff between code size and debug information precision.
 
-``nomerge`` attribute can also be used as function attribute to prevent all 
-calls to the specified function from merging. It has no effect on indirect 
+``nomerge`` attribute can also be used as function attribute to prevent all
+calls to the specified function from merging. It has no effect on indirect
 calls.
   }];
 }
 
 def NoInlineDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 This function attribute suppresses the inlining of a function at the call sites

 
 ``tvos``
   Apple's tvOS operating system. The minimum deployment target is specified by
   the ``-mtvos-version-min=*version*`` command-line argument.
 
 ``watchos``
   Apple's watchOS operating system. The minimum deployment target is specified by
   the ``-mwatchos-version-min=*version*`` command-line argument.
-  
 ``driverkit``
   Apple's DriverKit userspace kernel extensions. The minimum deployment target
   is specified as part of the triple.
 
 A declaration can typically be used even when deploying back to a platform
 version prior to when the declaration was introduced. When this happens, the
 declaration is `weakly linked
 <https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,

 
 
 def NullabilityDocs : DocumentationCategory<"Nullability Attributes"> {
   let Content = [{
 Whether a particular pointer may be "null" is an important concern when working
 with pointers in the C family of languages. The various nullability attributes
 indicate whether a particular pointer can be null or not, which makes APIs more
 expressive and can help static analysis tools identify bugs involving null
-pointers. Clang supports several kinds of nullability attributes: the 
+pointers. Clang supports several kinds of nullability attributes: the
 ``nonnull`` and ``returns_nonnull`` attributes indicate which function or
 method parameters and result types can never be null, while nullability type
 qualifiers indicate which pointer types can be null (``_Nullable``) or cannot
 be null (``_Nonnull``).
 
 The nullability (type) qualifiers express whether a value of a given pointer
 type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning
 for null (the ``_Nonnull`` qualifier), or for which the purpose of null is
memory is not available rather than returning a null pointer:
 
   .. code-block:: c
 
     extern void * malloc (size_t size) __attribute__((returns_nonnull));
 
 The ``returns_nonnull`` attribute implies that returning a null pointer is
 undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
 type qualifier indicates that a pointer cannot be null in a more general manner
-(because it is part of the type system) and does not imply undefined behavior, 
+(because it is part of the type system) and does not imply undefined behavior,
 making it more widely applicable
 }];
 }
 
 def NoAliasDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``noalias`` attribute indicates that the only memory accesses inside

 }];
 }
 
 def CFGuardDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 Code can indicate CFG checks are not wanted with the ``__declspec(guard(nocf))``
 attribute. This directs the compiler to not insert any CFG checks for the entire
-function. This approach is typically used only sparingly in specific situations 
-where the programmer has manually inserted "CFG-equivalent" protection. The 
-programmer knows that they are calling through some read-only function table 
-whose address is obtained through read-only memory references and for which the 
-index is masked to the function table limit. This approach may also be applied 
-to small wrapper functions that are not inlined and that do nothing more than 
-make a call through a function pointer. Since incorrect usage of this directive 
-can compromise the security of CFG, the programmer must be very careful using 
-the directive. Typically, this usage is limited to very small functions that 
+function. This approach is typically used only sparingly in specific situations
+where the programmer has manually inserted "CFG-equivalent" protection. The
+programmer knows that they are calling through some read-only function table
+whose address is obtained through read-only memory references and for which the
+index is masked to the function table limit. This approach may also be applied
+to small wrapper functions that are not inlined and that do nothing more than
+make a call through a function pointer. Since incorrect usage of this directive
+can compromise the security of CFG, the programmer must be very careful using
+the directive. Typically, this usage is limited to very small functions that
 only call one function.
 
 `Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`
 }];
 }
 
 def CUDADeviceBuiltinSurfaceTypeDocs : Documentation {
   let Category = DocCatType;
def ReadOnlyPlacementDocs : Documentation {
   2. Type ``T`` defines/inherits a mutable field.
   3. Type ``T`` defines/inherits non-constexpr constructor(s) for initialization.
   4. A field of type ``T`` is defined by type ``Q``, which does not bear the
      ``enforce_read_only_placement`` attribute.
   5. A type ``Q`` inherits from type ``T`` and it does not have the
      ``enforce_read_only_placement`` attribute.
   }];
 }
+def DisableADLDocs : Documentation {
+  let Content = [{Please don't LGTM without this being fully documented.}];
+}

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def err_callback_implicit_this_not_available : Error<
   "'callback' argument at position %0 references unavailable implicit 'this'">;
 def err_init_method_bad_return_type : Error<
   "init methods must return an object pointer type, not %0">;
 def err_attribute_invalid_size : Error<
   "vector size not an integral multiple of component size">;
 def err_attribute_zero_size : Error<"zero %0 size">;
 def err_attribute_size_too_large : Error<"%0 size too large">;
+def err_disable_adl_no_operators : Error<
+  "can't apply '__disable_adl' to %select{operators|member functions}0, since "
+  "they%select{'re supposed to be used| don't interact}0 with ADL">;
 def err_typecheck_sve_ambiguous : Error<
   "cannot combine fixed-length and sizeless SVE vectors in expression, result is ambiguous (%0 and %1)">;
 def err_typecheck_sve_gnu_ambiguous : Error<
   "cannot combine GNU and SVE vectors in expression, result is ambiguous (%0 and %1)">;
 def err_typecheck_vector_not_convertable_implict_truncation : Error<
    "cannot convert between %select{scalar|vector}0 type %1 and vector type"
    " %2 as implicit conversion would cause truncation">;
 def err_typecheck_vector_not_convertable : Error<

clang/include/clang/Basic/TokenKinds.def

 
 // Clang Extensions.
 KEYWORD(__builtin_convertvector          , KEYALL)
 ALIAS("__char16_t"   , char16_t          , KEYCXX)
 ALIAS("__char32_t"   , char32_t          , KEYCXX)
 KEYWORD(__builtin_bit_cast               , KEYALL)
 KEYWORD(__builtin_available              , KEYALL)
 KEYWORD(__builtin_sycl_unique_stable_name, KEYSYCL)
+KEYWORD(__disable_adl                    , KEYCXX)
 
 // Clang-specific keywords enabled only in testing.
 TESTING_KEYWORD(__unknown_anytype , KEYALL)
 
 
 //===----------------------------------------------------------------------===//
 // Objective-C @-preceded keywords.
 //===----------------------------------------------------------------------===//

clang/lib/Parse/ParseDecl.cpp

while (true) {
     }
 
     // Attributes support.
     case tok::kw___attribute:
     case tok::kw___declspec:
       ParseAttributes(PAKM_GNU | PAKM_Declspec, DS.getAttributes(), LateAttrs);
       continue;
 
+    case tok::kw___disable_adl: {
+      IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+      SourceLocation AttrNameLoc = Tok.getLocation();
+      DS.getAttributes().addNew(
+          AttrName, AttrNameLoc, /*scopeName=*/nullptr, AttrNameLoc,
+          /*args=*/nullptr, /*NumArgs=*/0, ParsedAttr::AS_Keyword);
+      break;
+    }
+
     // Microsoft single token adornments.
     case tok::kw___forceinline: {
       isInvalid = DS.setFunctionSpecForceInline(Loc, PrevSpec, DiagID);
       IdentifierInfo *AttrName = Tok.getIdentifierInfo();
       SourceLocation AttrNameLoc = Tok.getLocation();
       DS.getAttributes().addNew(AttrName, AttrNameLoc, nullptr, AttrNameLoc,
                                 nullptr, 0, ParsedAttr::AS_Keyword);
       break;

clang/lib/Sema/SemaDeclAttr.cpp

if ((IsAArch64 && !ArmSveAliasValid(S.Context, BuiltinID, AliasName)) ||
       (!IsAArch64 && !IsARM && !IsRISCV && !IsHLSL)) {
     S.Diag(AL.getLoc(), diag::err_attribute_builtin_alias) << AL;
     return;
   }
 
   D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
 }
 
+static void handleDisableADLAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (FunctionDecl *F = D->getAsFunction();
+      F->isOverloadedOperator() || F->isCXXClassMember()) {
+    S.Diag(AL.getLoc(), diag::err_disable_adl_no_operators)
+        << F->isCXXClassMember();
+    return;
+  }
+  D->addAttr(::new (S.Context) DisableADLAttr(S.Context, AL));
+}
+
 //===----------------------------------------------------------------------===//
 // Checker-specific attribute handlers.
 //===----------------------------------------------------------------------===//
 static bool isValidSubjectOfNSReturnsRetainedAttribute(QualType QT) {
   return QT->isDependentType() || QT->isObjCRetainableType();
 }
 
 static bool isValidSubjectOfNSAttribute(QualType QT) {
ProcessDeclAttribute(Sema &S, Scope *scope, Decl *D, const ParsedAttr &AL,
 
   case ParsedAttr::AT_BuiltinAlias:
     handleBuiltinAliasAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_UsingIfExists:
     handleSimpleAttribute<UsingIfExistsAttr>(S, D, AL);
     break;
+
+  case ParsedAttr::AT_DisableADL:
+    handleDisableADLAttr(S, D, AL);
+    break;
   }
 }
 
 /// ProcessDeclAttributeList - Apply all the decl attributes in the specified
 /// attribute list to the specified decl, ignoring any type attributes.
 void Sema::ProcessDeclAttributeList(
     Scope *S, Decl *D, const ParsedAttributesView &AttrList,
     const ProcessDeclAttributeOptions &Options) {

clang/lib/Sema/SemaLookup.cpp

for (auto *D : R) {
       auto *Underlying = D;
       if (auto *USD = dyn_cast<UsingShadowDecl>(D))
         Underlying = USD->getTargetDecl();
 
       if (!isa<FunctionDecl>(Underlying) &&
           !isa<FunctionTemplateDecl>(Underlying))
         continue;
 
+      if (Underlying->getAsFunction()->hasAttr<DisableADLAttr>())
+        continue;
+
       // The declaration is visible to argument-dependent lookup if either
       // it's ordinarily visible or declared as a friend in an associated
       // class.
       bool Visible = false;
       for (D = D->getMostRecentDecl(); D;
            D = cast_or_null<NamedDecl>(D->getPreviousDecl())) {
         if (D->getIdentifierNamespace() & Decl::IDNS_Ordinary) {
           if (isVisible(D)) {

clang/lib/Sema/SemaOverload.cpp

if (getLangOpts().CPlusPlusModules && !MF->isModuleMapModule() &&
       /// FIXME: Currently, the semantics of linkage in clang is slightly
       /// different from the semantics in C++ spec. In C++ spec, only names
       /// have linkage. So that all entities of the same should share one
       /// linkage. But in clang, different entities of the same could have
       /// different linkage.
       NamedDecl *ND = Function;
       if (auto *SpecInfo = Function->getTemplateSpecializationInfo())
         ND = SpecInfo->getTemplate();
-      
       if (ND->getFormalLinkage() == Linkage::InternalLinkage) {
         Candidate.Viable = false;
         Candidate.FailureKind = ovl_fail_module_mismatched;
         return;
       }
     }
   }
 
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);
 
     if (FunctionDecl *FD = dyn_cast<FunctionDecl>(*I)) {
       if (ExplicitTemplateArgs)
         continue;
 
       AddOverloadCandidate(
           FD, FoundDecl, Args, CandidateSet, /*SuppressUserConversions=*/false,
           PartialOverloading, /*AllowExplicit=*/true,
           /*AllowExplicitConversion=*/false, ADLCallKind::UsesADL);
       if (CandidateSet.getRewriteInfo().shouldAddReversed(*this, Args, FD)) {
         AddOverloadCandidate(
             FD, FoundDecl, {Args[1], Args[0]}, CandidateSet,
             /*SuppressUserConversions=*/false, PartialOverloading,
             /*AllowExplicit=*/true, /*AllowExplicitConversion=*/false,
if (!SingleFunctionExpression.isUsable()) {
     return false;
   }
 
   SrcExpr = SingleFunctionExpression;
   return true;
 }
 
 /// Add a single candidate to the overload set.
-static void AddOverloadedCallCandidate(Sema &S,
-                                       DeclAccessPair FoundDecl,
-                                 TemplateArgumentListInfo *ExplicitTemplateArgs,
-                                       ArrayRef<Expr *> Args,
-                                       OverloadCandidateSet &CandidateSet,
-                                       bool PartialOverloading,
-                                       bool KnownValid) {
+static void AddOverloadedCallCandidate(
+    Sema &S, DeclAccessPair FoundDecl,
+    TemplateArgumentListInfo *ExplicitTemplateArgs, ArrayRef<Expr *> Args,
+    OverloadCandidateSet &CandidateSet, bool PartialOverloading,
+    bool KnownValid, UnresolvedLookupExpr *ULE) {
   NamedDecl *Callee = FoundDecl.getDecl();
   if (isa<UsingShadowDecl>(Callee))
     Callee = cast<UsingShadowDecl>(Callee)->getTargetDecl();
 
   if (FunctionDecl *Func = dyn_cast<FunctionDecl>(Callee)) {
+    if (Func->hasAttr<DisableADLAttr>() && ULE) {
+      ULE->disableADL();
+    }
+
     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 (FunctionTemplateDecl *FuncTemplate
       = dyn_cast<FunctionTemplateDecl>(Callee)) {
+    if (FuncTemplate->getAsFunction()->hasAttr<DisableADLAttr>() && ULE) {
+      ULE->disableADL();
+    }
+
     S.AddTemplateOverloadCandidate(FuncTemplate, FoundDecl,
                                    ExplicitTemplateArgs, Args, CandidateSet,
                                    /*SuppressUserConversions=*/false,
                                    PartialOverloading);
     return;
   }
 
   assert(!KnownValid && "unhandled case in overloaded call candidate");
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);
+                               /*KnownValid=*/true, ULE);
 
   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.
 void Sema::AddOverloadedCallCandidates(
     LookupResult &R, TemplateArgumentListInfo *ExplicitTemplateArgs,
     ArrayRef<Expr *> Args, OverloadCandidateSet &CandidateSet) {
   for (LookupResult::iterator I = R.begin(), E = R.end(); I != E; ++I)
     AddOverloadedCallCandidate(*this, I.getPair(), ExplicitTemplateArgs, Args,
-                               CandidateSet, false, /*KnownValid*/ false);
+                               CandidateSet, false, /*KnownValid*/ false,
+                               nullptr);
 }
 
 /// Determine whether a declaration with the specified name could be moved into
 /// a different namespace.
 static bool canBeDeclaredInNamespace(const DeclarationName &Name) {
   switch (Name.getCXXOverloadedOperator()) {
   case OO_New: case OO_Array_New:
   case OO_Delete: case OO_Array_Delete:
case OR_Success: {
             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);
               // Mark member== const or provide matching != to disallow reversed
-              // args. Eg. 
-              // struct S { bool operator==(const S&); }; 
+              // args. Eg.
+              // struct S { bool operator==(const S&); };
               // S()==S();
               if (auto *MD = dyn_cast<CXXMethodDecl>(FnDecl))
                 if (Op == OverloadedOperatorKind::OO_EqualEqual &&
                     !MD->isConst() &&
                     Context.hasSameUnqualifiedType(
                         MD->getThisObjectType(),
                         MD->getParamDecl(0)->getType().getNonReferenceType()) &&
                     Context.hasSameUnqualifiedType(MD->getThisObjectType(),

clang/test/SemaCXX/disable-adl.cpp

+// RUN: %clang_cc1 %s -fsyntax-only -verify -std=c++20
+// RUN: %clang_cc1 %s -fsyntax-only -verify -std=c++2b
+
+namespace NS1 {
+  struct S1 {};
+  S1 inhibited(S1); // expected-note 2 {{candidate function}}
+
+  namespace NNS1 {
+    struct S2 {};
+    __disable_adl void hidden(S2);   // expected-note{{declared here}}
+    __disable_adl int inhibited(S1); // expected-note 4 {{candidate function}}
+  }
+}
+
+namespace NS2 {
+  __disable_adl void inhibited(NS1::S1); // expected-note 2 {{candidate function}}
+}
+
+void test_functions() {
+  hidden(NS1::NNS1::S2{}); // expected-error{{use of undeclared identifier 'hidden'; did you mean 'NS1::NNS1::hidden'?}}
+  {
+    NS1::S1 x = inhibited(NS1::S1{}); // no error
+  }
+  {
+    using namespace NS1::NNS1;
+    int x = inhibited(NS1::S1{}); // no error
+
+    using namespace NS1;
+    S1 y = inhibited(NS1::S1{}); // expected-error{{call to 'inhibited' is ambiguous}}
+  }
+  {
+    using NS1::NNS1::inhibited;
+    int x = inhibited(NS1::S1{}); // no error
+
+    using NS1::inhibited;
+    NS1::S1 y = inhibited(NS1::S1{}); // expected-error{{call to 'inhibited' is ambiguous}}
+  }
+  {
+    using namespace NS2;
+    inhibited(NS1::S1{}); // no error
+
+    using namespace NS1::NNS1;
+    inhibited(NS1::S1{}); // expected-error{{call to 'inhibited' is ambiguous}}
+  }
+  {
+    using NS2::inhibited;
+    inhibited(NS1::S1{}); // no error
+
+    using NS1::NNS1::inhibited;
+    inhibited(NS1::S1{}); // expected-error{{call to 'inhibited' is ambiguous}}
+  }
+}
+
+namespace NS1 {
+  template<typename T>
+  S1 inhibited_template(T); // expected-note 2 {{candidate function}}
+
+  namespace NNS1 {
+    template<typename T>
+    __disable_adl void hidden_template(T); // expected-note{{declared here}}
+
+    template<typename T>
+    __disable_adl int inhibited_template(T); // expected-note 4 {{candidate function}}
+  }
+}
+
+namespace NS2 {
+  template<typename T>
+  __disable_adl int inhibited_template(T); // expected-note 2 {{candidate function}}
+}
+
+void test_function_templates() {
+  hidden_template(NS1::NNS1::S2{}); // expected-error{{use of undeclared identifier 'hidden_template'; did you mean 'NS1::NNS1::hidden_template'?}}
+
+  {
+    NS1::S1 x = inhibited_template(NS1::S1{}); // no error
+  }
+  {
+    using namespace NS1::NNS1;
+    int x = inhibited_template(NS1::S1{}); // no error
+
+    using namespace NS1;
+    S1 y = inhibited_template(NS1::S1{}); // expected-error{{call to 'inhibited_template' is ambiguous}}
+  }
+  {
+    using NS1::NNS1::inhibited_template;
+    int x = inhibited_template(NS1::S1{}); // no error
+
+    using NS1::inhibited_template;
+    NS1::S1 y = inhibited_template(NS1::S1{}); // expected-error{{call to 'inhibited_template' is ambiguous}}
+  }
+  {
+    using namespace NS2;
+    inhibited_template(NS1::S1{}); // no error
+
+    using namespace NS1::NNS1;
+    inhibited_template(NS1::S1{}); // expected-error{{call to 'inhibited_template' is ambiguous}}
+  }
+  {
+    using NS2::inhibited_template;
+    inhibited_template(NS1::S1{}); // no error
+
+    using NS1::NNS1::inhibited_template;
+    inhibited_template(NS1::S1{}); // expected-error{{call to 'inhibited_template' is ambiguous}}
+  }
+}
+
+namespace NS1 {
+  S1 inhibited_mixed(S1);
+
+  namespace NNS1 {
+    template<typename T>
+    __disable_adl int inhibited_mixed(T);
+  }
+}
+
+void test_mixed() {
+  using namespace NS1::NNS1;
+  int x = inhibited_mixed(NS1::S1{}); // no error
+}
+
+// Should be covered by the hidden functions checks, but just to be sure.
+void test_NNS1_hidden() {
+  {
+    NS1::S1 a = inhibited(NS1::S1{});
+    NS1::S1 b = inhibited_template(NS1::S1{});
+    NS1::S1 c = inhibited_mixed(NS1::S1{});
+  }
+  {
+    using namespace NS1;
+    NS1::S1 a = inhibited(NS1::S1{});
+    NS1::S1 b = inhibited_template(NS1::S1{});
+    NS1::S1 c = inhibited_mixed(NS1::S1{});
+  }
+}
+
+namespace NS1 {
+  namespace NNS1 {
+    __disable_adl void operator-(S2); // expected-error{{can't apply '__disable_adl' to operators, since they're supposed to be used with ADL}}
+
+    struct hidden_friend_operator {
+      friend void operator-(hidden_friend_operator i, int) {}
+    };
+
+    struct hidden_friend_swap {
+      __disable_adl friend void swap(hidden_friend_swap, hidden_friend_swap) {}
+    };
+  }
+}
+
+void test_friends_and_operators() {
+  -NS1::NNS1::S2{};                        // no error
+  NS1::NNS1::hidden_friend_operator{} - 1; // no error
+
+  swap(NS1::NNS1::hidden_friend_swap{}, NS1::NNS1::hidden_friend_swap{}); // expected-error{{use of undeclared identifier 'swap'}}
+}
+
+struct S {
+  __disable_adl void f();        // expected-error{{can't apply '__disable_adl' to member functions, since they don't interact with ADL}}
+  __disable_adl static void g(); // expected-error{{can't apply '__disable_adl' to member functions, since they don't interact with ADL}}
+};
+
+template <class> using common_comparison_category_t = int;
+template <class T> T declval;
+template <class> __disable_adl auto synth_three_way();
+template <class T, class U = T> using synth_three_way_result = decltype(synth_three_way(declval<U>));
+template <class> concept three_way_comparable_synthesisable = requires { synth_three_way; };
+template <class T2> struct pair {
+  template <three_way_comparable_synthesisable U = T2>
+  auto operator>(pair) -> common_comparison_category_t<synth_three_way_result<U>>;
+};
+struct pair_spaceship_invalid {
+  pair_spaceship_invalid() { test<pair<int>>(); } // expected-note{{}}
+  template <class> void test() noexcept;
+};
+template <class T> void pair_spaceship_invalid::test() noexcept {
+  auto p1 = T(), p2 = T();
+  requires { p1 > p2; }; // expected-warning 2 {{expression result unused}}
+}