llvm-project
llvm-project copied to clipboard
poor error recovery from unqualified class enum
Bugzilla Link | 10460 |
Version | unspecified |
OS | All |
CC | @DougGregor,@jryans,@zygoloid |
Extended Description
Consider this:
$ cat t.cc
enum class foo_t { abcdef, b, c };
foo_t x = abcdef;
namespace bar {
enum bar_t { abcdef, b, c };
}
bar::bar_t y = abcdef;
$ clang t.cc -std=c++0x
t.cc:4:11: error: use of undeclared identifier 'abcdef'
foo_t x = abcdef;
^
t.cc:10:16: error: use of undeclared identifier 'abcdef'
bar::bar_t y = abcdef;
^
It would be nice to say "did you mean foo_t::abcdef
" by diving into the namespace/enum class.
For the second case, we now produce
(with a fixit). However, as far as I know, the typo correction doesn't take the type of the variable being declared into account.
I would like to look work on this issue. I'm new to LLVM (gone through kaleidoscope tutorials and building JIT). Any advice on how to begin?
thanks!
Off the top of my head, so your mileage may vary.
Have a look at the AST clang makes for the example, some of the terms you see there will help later. Godbolt is a good way to do this quickly: https://godbolt.org/z/1f476rbbY
Sounds like this issue was sort of half done but the typo correction isn't as good as it could be. I would first work out what it should be ideally, then go looking for where the typo lookup happens.
One way to do that is to find the final point where the message is printed, grep the source for the format of the message is one way. Then pull on that thread so to speak. What you want to understand is how that corrections mechanism works and what context it does - and for this bug - does not have.
You can also breakpoint that final bit and backtrace in a debugger. Though what you might find is that it's not a linear callstack, so you have to follow the data instead.
Another way to do it is to find the classes involved and look at their tests. If they exist, write a test that does what you want to happen, then work to making it pass.
Thanks. I'm looking into it.
This issue was resolved in clang 3.1 and still working in trunk (post-17) https://godbolt.org/z/d85vb7oca
clang trunk (post-17) complie output:
<source>:3:11: error: use of undeclared identifier 'abcdef'
3 | foo_t x = abcdef;
| ^
<source>:9:16: error: use of undeclared identifier 'abcdef'; did you mean 'bar::abcdef'?
9 | bar::bar_t y = abcdef;
| ^~~~~~
| bar::abcdef
<source>:6:16: note: 'bar::abcdef' declared here
6 | enum bar_t { abcdef, b, c };
| ^
2 errors generated.