Funny error message for invalid code.

[CarloWood]

Probably not worth fixing, but well.

namespace vulkan {
}

namespace xcb {
  
struct ModifierMask {
  static constexpr int Shift = 1;
};

} // namespace xcb

void test()
{
  using S = vulkan::ModifierMask::Shift;
}

Gives (with clang HEAD 14.0.0, as well as version 13).

prog.cc:14:13: error: no member named 'ModifierMask' in namespace 'vulkan';
did you mean 'xcb::ModifierMask'?
  using S = vulkan::ModifierMask::Shift;
            ^~~~~~~~~~~~~~~~~~~~
            xcb::ModifierMask
prog.cc:6:8: note: 'xcb::ModifierMask' declared here
struct ModifierMask {
       ^
prog.cc:14:35: error: no type named 'Shift' in 'xcb::ModifierMask'
  using S = vulkan::ModifierMask::Shift;
                    ~~~~~~~~~~~~~~^
2 errors generated.

gcc HEAD reports:

prog.cc: In function 'void test()':
prog.cc:14:21: error: 'ModifierMask' in namespace 'vulkan' does not name a type
   14 |   using S = vulkan::ModifierMask::Shift;
      |                     ^~~~~~~~~~~~

and leaves it at that.

The "bug" is that clang says that there isn't a type 'Shift' in 'xcb::ModifierMask' while there is no 'xcb::ModifierMask' insight imho. The actual problem was me forgetting to include the header that defines 'vulkan::ModifierMask::Shift'.

[Quuxplusone]

Looks to me like "not a bug." Clang clearly explains every step of the error cascade: you write vulkan::ModifierMask, it gets typo-corrected to xcb::ModifierMask, and then xcb::ModifierMask (still) doesn't contain a Shift type. I suggest closing as [invalid] since I don't see anything Clang would want to do differently here.

[CarloWood]

@Quuxplusone: I think it is silly to report errors for something that occurs only after a "typo correction" that is wrong.
I did not mean xcb::ModifierMask, nor did I type it. And the error shows the line I typed:

using S = vulkan::ModifierMask::Shift;

and says "No Shift in xcb::ModifierMask. Wut?

Makes no sense. The typo correction failed too. If you want you can ADD a bug report imho.

[nichtsundniemand]

@CarloWood I think they've got a point.

Look at the first line from clang:

prog.cc:14:13: error: no member named 'ModifierMask' in namespace 'vulkan';

It matches what gcc tells you. Then clang tries to take it a bit further and notices that you have declared a struct with the same name in a different namespace (xcb):

did you mean 'xcb::ModifierMask'?

The rest of the error message is just clang telling you that even after trying very hard it couldn't find the member/type you were after.

Also: In your example the struct ModifierMask has been declared inside the namespace xcb so clang ist correct talk about a symbol xcb::ModifierMask

I would admit that the message is a bit confusing at first and clang seems to report two errors when there's only one?

[CarloWood]

@therufuser I have no problem with it asking if I meant xcb::ModifierMask, but it definitely goes too far to then bother the user with that xcb::ModifierMask doesn't have a Size type. You'd think that that is at most a hint to clang that I didn't mean xcb::ModifierMask - and I didn't. The worst part is that it underlines ModifierMask in vulkan::ModifierMask while stating that xcb::ModifierMask doesn't have a Size type. That borders arrogance, if a compiler was capable of that. First it draws a wrong conclusion and then it has to audacity to assume it was correct and point out another "error" that I would have made (solely based on that it's assumption is correct).

Anyway - I'll leave it to the compiler devs to fix this, or not. But I don't think it is very useful to point out "errors" that occur as a result of a heuristic change that the compiler itself came up with.

A few decades ago a colleague programmer and me joked (as a result of code that we wrote that started to be a little too smart) that at some point we'd get errors like:

prog.cc:42:13: error: you wrote 'vulkan::ModifierMask', that is wrong.
    You probably _meant_ 'xcb::ModifierMask' but that isn't a good idea either;
    better is to use an entirely different approach. Your code was changed accordingly.

and then continue with compiling...

For some reason I have to think about that with this, but I am not amused.

[pmor13]

@CarloWood

warning: after 3 levels of inlining (potentially across files with Link Time Optimization),
some common subexpression elimination, after hoisting this thing out of a loop and proving
that these 13 pointers don't alias, we found a case where you're doing something undefined.
This could either be because there is a bug in your code, or because you have macros and
inlining and the invalid code is dynamically unreachable but we can't prove that it is dead.

source

[AaronBallman]

I am closing this issue as Clang is working as intended.

I agree with the OP that the follow-on diagnostic could be confusing because you have to look at the source and the diagnostic messages at the same time to kind of suss out what's going on. However, the compiler will emit follow-on diagnostics regardless (unless the user passes -ferror-limit=1). So we're either going to emit diagnostics with the typo corrected or with the typo uncorrected.

In the case of an uncorrected typo, the follow-on diagnostics are almost always going to be noise rather than pointing out additional, novel issues. Consider contrived code like:

namespace foo {
using bar = int;
}

fop::bar i = 12; // Without typo correction recovering to foo::bar, you get a follow-on error about unknown type names

With a corrected typo, the follow-on diagnostics are either going to be noise because we did not guess the typo correctly or they're going to be reasonable because we did guess the typo correctly. Our policy in general has always been that if we think we know how to repair the code, we repair the code and continue on because that leads to better diagnostic behavior more often than not. e.g., we'll pretend a declaration ended with ; if we expected one but didn't see one; typo correction is more of the same.

Ultimately, it boils down to the quality of our typo correction (which certainly can be improved).

Free free to reopen this issue if you want to continue the discussion.