[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #1 from Jonathan Wakely --- Another option suggested by Barry Revzin is to line up the types, so that the type's name is in the same column so the different nested-name-qualifier is more obvious: vt.C:276:15: error: conversion from 'std::tuple' to non-scalar type 'tuple' requested Although this breaks the current convention that the error is on a single line. This also seems kinda related to the -fdiagnostics-show-template-tree option, but that doesn't help here (and that option is only helpful if you remember it exists and use it).
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 Barry Revzin changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #2 from Barry Revzin --- My suggestion is more to line up the fronts of the types: vt.C:276:15: error: conversion requested from: std::tuple to: tuple And drop the "non-scalar type" part - does it add anything meaningful to the diagnostic? I already know tuple<...> isn't a scalar (and if I didn't, would it help?) But what Mr. Wakely indicated also works - basically any presentation where the 'from' and 'to' types are on separate lines and similarly formatted makes it easier to see what's up.
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Could we add a note for ill-formed conversions between two types that have
> the same name, to make it more obvious that they're defined in different
> scopes?
>
> Maybe:
>
> :: note: tuple and std::tuple are not the same type
> :: note: tuple define here
> :: note: std::tuple define here
I *don't* want the locations printed for two different specializations of the
same temploid, so e.g. don't show where foo::bar and foo::bar are
declared. It will almost certainly be the same line, which won't help the
confused user. I don't even think it's worth adding the first note that they're
not the same type for two specializations of the same template. That's not the
confusing case.
I'm only suggesting this for two unrelated types that just happen to have the
same name but are actually defined in totally different scopes, so a::foo and
b::foo, or c::bar and ::bar.
This would probably be useful for enumeration types as well as classes:
namespace a { enum foo { } }
namespace b { enum foo { B } }
a::foo e = b::B;
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #4 from Jonathan Wakely --- (In reply to Barry Revzin from comment #2) > And drop the "non-scalar type" part - does it add anything meaningful to the > diagnostic? Good point. I assume the intention of that wording is to say "I tried to find constructors and conversion operators to make this work, but there aren't any" but that's a very compiler-centric error. The user doesn't care where we looked, only that it didn't compile. They can figure out (or probably already know) whether that type is a class, and whether that means no constructor exists for the conversion.
[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105672 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > :: note: tuple and std::tuple are not the same type And just to be clear, it was very intentional that this suggestion *doesn't* show the template argument lists. That's just clutter in this context (and those arg lists are already shown in the "error:" line). The template arg lists are irrelevant here, *no* argument list is going to make them the same type, so showing it doesn't help. What matters here is the nested-name-specifier and the name after it.
