[cfe-dev] Odd diagnostics

[Richard Smith]

On Sun, Mar 22, 2015 at 5:12 PM, Robert Ankeney <rrankene at gmail.com> wrote:

> I'm seeing some strange results using a RecursiveASTVisitor on some C
> code. The following code compiles fine with clang:
>
> static __inline unsigned int
> __bswap_32 (unsigned int __bsx)
> {
>   return __builtin_bswap32 (__bsx);
> }
>
> But I get the following diagnostic when calling ParseAST:
>
> C:/BUG/builtin.c:4:10: error: use of unknown builtin '__builtin_bswap32'
>
> return __builtin_bswap32 (__bsx);
>
>          ^
>
> It seems odd that I should get this error, as __builtin_bswap32() is
> supported. Any idea why?
>

If you're calling ParseAST yourself, you're likely missing quite a few of
the necessary set up steps; in this case, the missing step is a call to
InitializeBuiltins on the preprocessor's Builtins::Context object. It's
generally better to use the clang Frontend library to set up and initialize
the various components of the compiler for you; see ToolInvocation and
ClangTool in the Tooling library for some prebuilt wrappers to make this
easier.


> Another interesting thing - I get the following results for each of the
> getDiagnostics() calls:
> hasUncompilableErrorOccurred() = True
>
> hasUnrecoverableErrorOccurred() = False
>
> hasFatalErrorOccurred() = False
>
> hasErrorOccurred() = True
>
>
> As a point of comparison, for the following code:
>
> int foo()
> {
>   retrun 42;  // Typo on return
> }
>
>
> I get:
>
> C:/Src/cp.PP/BUG/bug.c:3:3: error: use of undeclared identifier 'retrun'
>
>    retrun 42;
>
>    ^
>
>
> hasUncompilableErrorOccurred() = True
>
> hasUnrecoverableErrorOccurred() = True
>
> hasFatalErrorOccurred() = False
>
> hasErrorOccurred() = True
>
>
> For code that generates only a warning, the above 4 calls all return False.
>
> I guess I'm not sure what the difference is between hasUncompilableErrorOccurred()
> and
> hasErrorOccurred(), or what exactly the other 2 functions do. Any
> enlightenment there?
>

In order from most specific to most general:

hasFatalErrorOccurred() indicates whether we've emitted any "fatal error:"
diagnostics. These are diagnostics that indicate a problem sufficiently
severe that we don't think we could continue to emit correct diagnostics
after emitting one. (For instance: missing a file named by #include, or
reached the template instantiation depth limit.)

hasUnrecoverableErrorOccurred indicates whether we think the AST is not
essentially correct -- whether tools performing automated analysis and
refactorings might get the wrong answer. If an unrecoverable error occurs,
we turn off CFG-based analyses and the like. This excludes errors upgraded
from warnings, and also "warning-like" errors for ARC issues, functions
marked "unavailable", and so on.

hasUncompilableErrorOccurred indicates whether we think we could generate
correct code from the AST we built. This excludes errors upgraded from
warnings, but includes ARC issues and uses of unavailable functions (for
which we could analyse the program, but where we couldn't generate working
code).

hasErrorOccurred() indicates if we've emitted any "error:" diagnostics, and
thus whether the compilation should fail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150323/85a3540e/attachment.html>