[cfe-dev] Clang as a compiler-only tool

James Molloy james at jamesmolloy.co.uk
Mon Nov 19 04:03:37 PST 2012


I don't personally think this diagnostic is clear enough. What is a
RunAnalysis? Clang is known for its good, readable diagnostics - I'd prefer
something more human-readable.

error:<command line>: Using functionality that has been compiled out of
Clang
note:<command line>: Recompile without -DXXXX to enable this functionality

On 19 November 2012 11:53, Roman Divacky <rdivacky at freebsd.org> wrote:

> Ok, I made it emit an error like this:
>
> witten ~/llvm$ ./Release+Asserts/bin/clang -cc1 -analyze
> -analyzer-checker=alpha.cplusplus.VirtualCall -analyzer-store region
> tools/clang/test/Analysis/virtualcall.cpp
> error: action RunAnalysis not compiled in
>
>
> This happens to uncover a small bug though. We are emitting diagnostics in
> ExecuteCompilerInvocation.cpp which then gets warn about with -verify:
>
>
> witten ~/llvm$ ./Release+Asserts/bin/clang -cc1 -fsyntax-only -load
> /tmp/bah -plugin foobar -verify ~/hello.c
> error: 'error' diagnostics seen but not expected:
>   (frontend): unable to load plugin '/tmp/bah': '/tmp/bah: cannot open
> shared object file: No such file or directory'
>
> but thats a separate issue, just fwiw :)
>
>
> With the patch like that (#ifndef + emitting diagnostic), is it ok?
>
> Roman
>
>
> On Sun, Nov 18, 2012 at 06:50:37PM +0000, James Molloy wrote:
> > Agreed. If this is user facing, there should be a proper, explanatory
> > diagnostic message. Executing llvm_unreachable is a bug, not a feature!
> >
> > On 18 November 2012 17:11, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> >
> > > On Sun, Nov 18, 2012 at 7:06 PM, Roman Divacky <rdivacky at freebsd.org>
> > > wrote:
> > > > On Sun, Nov 18, 2012 at 02:45:10PM +0200, Dmitri Gribenko wrote:
> > > >> On Sun, Nov 18, 2012 at 2:16 PM, Roman Divacky <
> rdivacky at freebsd.org>
> > > wrote:
> > > >> > I would like to ask about your opinion on the attached trivial
> patch,
> > > which
> > > >> > introduces #ifndef CLANG_IS_COMPILER_ONLY in two places.
> > > >>
> > > >> --- lib/FrontendTool/ExecuteCompilerInvocation.cpp    (revision
> 168286)
> > > >> +++ lib/FrontendTool/ExecuteCompilerInvocation.cpp    (working copy)
> > > >> @@ -79,11 +81,13 @@
> > > >>      return new PrintPreprocessedAction();
> > > >>    }
> > > >>
> > > >> +#ifndef CLANG_IS_COMPILER_ONLY
> > > >>    case RewriteMacros:          return new RewriteMacrosAction();
> > > >>    case RewriteObjC:            return new RewriteObjCAction();
> > > >>    case RewriteTest:            return new RewriteTestAction();
> > > >>    case RunAnalysis:            return new ento::AnalysisAction();
> > > >>    case MigrateSource:          return new
> arcmt::MigrateSourceAction();
> > > >> +#endif
> > > >>    case RunPreprocessorOnly:    return new PreprocessOnlyAction();
> > > >>    }
> > > >>    llvm_unreachable("Invalid program action!");
> > > >>
> > > >> Won't this cause Clang to crash if the user asks for an action that
> is
> > > >> not compiled-in?
> > > >
> > > > It will execute llvm_unreachable("Invalid program action!"); which is
> > > fine
> > > > for me. FreeBSD really needs just the compiler bits.
> > > >
> > > > Note that I am not advocating making this the default, just having a
> way
> > > > to make this possible without modifying the sources.
> > >
> > > Well, I am just suggesting that Clang crashing on command line
> > > parameter invoking an action that is disabled during compile-time is
> > > not the user experience we want to provide for any Clang
> > > configuration.  A proper error message would be much better.
> > >
> > > Dmitri
> > >
> > > --
> > > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> > > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> > > _______________________________________________
> > > cfe-dev mailing list
> > > cfe-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121119/7bd17387/attachment.html>


More information about the cfe-dev mailing list