<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 14, 2014 at 4:53 PM, Kevin Funk <span dir="ltr"><<a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey,<br>
<br>
I'm a bit puzzled by the following behavior of clang when inspecting the AST<br>
for the following code snippet:<br>
<br>
test.cpp:<br>
char foo;<br>
char bar = foo1;<br>
<br>
$ clang++ -cc1 -ast-dump test.cpp:<br>
main.cpp:2:12: error: use of undeclared identifier 'foo1'; did you mean 'foo'?<br>
(...)<br>
`-VarDecl 0xa19cb0 <line:2:1, col:12> col:6 bar 'char' cinit<br>
  `-ImplicitCastExpr 0xa19d60 <col:12> 'char' <LValueToRValue><br>
    `-DeclRefExpr 0xa19d38 <col:12> 'char' lvalue Var 0xa19c40 'foo' 'char'<br>
<br>
So, Clang seems to interpret 'foo1' as a typo 'foo'. This is still fine.<br>
However, Clang also "fixes up the code" and pretends that 'foo1' *is* 'foo'<br>
which -ast-dump shows (see last line of the dump). This is odd.<br>
<br>
Obviously, this is only the case if -fno-spell-checking is *not* passed to<br>
clang++. With -fno-spell-checking I get this instead:<br>
<br>
$ clang++ -cc1 -ast-dump test.cpp -fno-spell-checking<br>
(...)<br>
`-VarDecl 0x1a79ca0 <line:2:1, col:6> col:6 bar 'char'<br>
<br>
This looks fine to me.<br>
<br>
So, my question: Is this intended behavior? Is this for error recovery in the<br>
parser?<br></blockquote><div><br></div><div>Yes, this is intended. It is our policy that whenever we emit an error message with a fix-it hint, we recover as if that fix-it hint had been applied to the AST. This is not limited to typo-correction; it happens whenever we emit an error with a fix-it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If true, is there a way to both enable spell-checking but to *disable* it<br>
touching the AST?<br></blockquote><div><br></div><div>Not currently, no. I think what you're really asking for is for us to turn off all error recovery, so the AST contains only things that were in the source code, and omits erroneous things rather than trying to recover from errors? We could try to support such a mode, but I suspect that it would degrade the diagnostic experience enough that you may want to run Clang twice: once in this mode, and once to produce user-facing diagnostics. Also, I don't expect that you'll find volunteers in the Clang community to do the work, but if the design and rationale are reasonable and you can provide a convincing argument that the mode will have sufficient ongoing support work, we'd accept patches to implement this.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reminder: I'm working on integrating Clang (read: libclang) in KDevelop, hence<br>
I'm looking at this from an development tool perspective. Magic behavior<br>
inside Clang is somewhat undesirable there :)</blockquote><div><br></div><div>Can you explain a bit more about your use cases? I assume you want to provide some kind of AST introspection on not-necessarily-valid code, and you don't want to expose our typo-correction results in that? Depending on what you're trying to achieve, there might be lighter-weight approaches (for instance, checking if the token at the given location actually refers to the right name).</div>
</div></div></div>