-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[clang] check deduction consistency when partial ordering function templates #100692
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
f8fd471
1c6ea6e
5b8099e
9497c1d
4cd65d6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
// RUN: %clang_cc1 -std=c++23 -verify %s | ||
|
||
namespace t1 { | ||
template<bool> struct enable_if { typedef void type; }; | ||
template <class T> class Foo {}; | ||
template <class X> constexpr bool check() { return true; } | ||
template <class X, class Enable = void> struct Bar {}; | ||
|
||
template<class X> void func(Bar<X, typename enable_if<check<X>()>::type>) {} | ||
// expected-note@-1 {{candidate function}} | ||
|
||
template<class T> void func(Bar<Foo<T>>) {} | ||
// expected-note@-1 {{candidate function}} | ||
|
||
void g() { | ||
func(Bar<Foo<int>>()); // expected-error {{call to 'func' is ambiguous}} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interestingly everyone accepts that https://godbolt.org/z/KG9cx4c6f There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can you add a similar tests where the overload are constrained (both with subsumption, and with either one having a constraint nit satisfied) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not seeing wording that would allow us to accept this, but it is interesting that we all consistently implement the same rules and accept anyway. Should this be a Core issue in order to avoid breaking working code? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nah, I think this is contrived enough that it's unlikely to affect users. If users find issues with the direction we can reconsider or divide a transition strategy (like we did with template template parameter ordering) And as explain in #18291 - we are not self consistent There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion, but when 100% of implementations all do the same thing (which we do), it seems rather silly to expect implementations and users to change instead of asking whether the standard should reflect reality. https://godbolt.org/z/johT7fva8 I don't see a reason to break user code except for conformance, but nobody conforms so... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Related core issue CWG2160 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, after playing around a bit more... I don't think I can explain what our behavior is in practice, so maybe this is the correct approach. Certainly the code seems ambiguous to me, so I think the changes are defensible. I'm curious if @zygoloid has opinions here, but if not, I think it's fine to move forward. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Subsumption is not checked on deduction, that's only used later during overload resolution, which we are not changing, so I am not sure that test would be relevant to this change. Relatedly, in a callback to another discussion with @zygoloid , we currently check if deduction would produce arguments which would not satisfy the constraints, but according to the specification this should not apply to partial ordering, which we fail to do so before this patch, and this patch introduces another case where we fail to follow the rules. |
||
} | ||
} // namespace t1 | ||
|
||
namespace t2 { | ||
template <bool> struct enable_if; | ||
template <> struct enable_if<true> { | ||
typedef int type; | ||
}; | ||
struct pair { | ||
template <int = 0> pair(int); | ||
template <class _U2, enable_if<__is_constructible(int &, _U2)>::type = 0> | ||
pair(_U2 &&); | ||
}; | ||
int test_test_i; | ||
void test() { pair{test_test_i}; } | ||
} // namespace t2 |
Uh oh!
There was an error while loading. Please reload this page.