This fixes PR40552 by not showing the diagnostic that complains about different access specifiers, since the template does not have one.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 27563 Build 27562: arc lint + arc unit
Event Timeline
| test/SemaCXX/cxx1z-class-template-argument-deduction.cpp | ||
|---|---|---|
| 360–361 | These errors are pretty unfortunate -- they don't really help the user to understand what's gone wrong here. They're an improvement over the crash, but I think we should try to make the errors more useful if we can. Why is Typo() being treated as a deduction guide? Perhaps we could look to see if there is a -> before making that determination? | |
| test/SemaCXX/cxx1z-class-template-argument-deduction.cpp | ||
|---|---|---|
| 360–361 |
Yes that would be possible. The diagnostic would change for the following code: template <typename>
struct Foo {};
Foo();// -> Foo<int>;
// currently: deduction guide missing ->
// after: C++ requires type specifier for every declarationIs that acceptable? Or I guess I could restrict this to partial deduction guides in classes. | |
| test/SemaCXX/cxx1z-class-template-argument-deduction.cpp | ||
|---|---|---|
| 360–361 | I think the original diagnostic is better in that case. If you restrict to partial deduction guides, do we get all the good diagnostics? | |
| test/SemaCXX/cxx1z-class-template-argument-deduction.cpp | ||
|---|---|---|
| 360–361 | I think the most likely intent in that case was to declare a constructor of Foo, and either it was accidentally written after the end of the class, or the in-class declaration got copy-pasted and the programmer forgot to fix it up. And moreso for a case such as template <typename>
struct Foo { Foo(); };
template<typename T>
Foo() {
// ...
}... where we currently give three errors about deduction guides and no hint that a qualified name is required to define a constructor. I think it's comparatively unlikely that someone would forget the -> in a deduction guide, given how central it is to the purpose of the declaration. So always disambiguating as a failed constructor rather than a failed deduction guide seems reasonable to me. | |
These errors are pretty unfortunate -- they don't really help the user to understand what's gone wrong here. They're an improvement over the crash, but I think we should try to make the errors more useful if we can.
Why is Typo() being treated as a deduction guide? Perhaps we could look to see if there is a -> before making that determination?