from a source file and changes clang-check to make use of this.
This makes clang-check just work on in-tree builds, and allows
easy setup via a symlink per source directory to make clang-check
work without any extra configuration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159990 91177308-0d34-0410-b5e6-96231b3b80d8
- Split pedantic driver flag test into separate test file, and XFAIL on cygwin,mingw32
- Fix bug in tablegen logic where a missing '{' caused errors to be included in -Wpedantic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159892 91177308-0d34-0410-b5e6-96231b3b80d8
I suspect FileCheck might match assertion failure, even if clang/test/Misc/warning-flags.c passed the test.
> 0. Program arguments: bin/./clang -### -pedantic -Wpedantic clang/test/Driver/warning-options.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159886 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces some magic in tablegen to create a "Pedantic" diagnostic
group which automagically includes all warnings that are extensions. This
allows a user to suppress specific warnings traditionally under -pedantic used
an ordinary warning flag. This also allows users to use #pragma to silence
specific -pedantic warnings, or promote them to errors, within blocks of text
(just like any other warning).
-Wpedantic is NOT an alias for -pedantic. Instead, it provides another way
to (a) activate -pedantic warnings and (b) disable them. Where they differ
is that -pedantic changes the behavior of the preprocessor slightly, whereas
-Wpedantic does not (it just turns on the warnings).
The magic in the tablegen diagnostic emitter has to do with computing the minimal
set of diagnostic groups and diagnostics that should go into -Wpedantic, as those
diagnostics that already members of groups that themselves are (transitively) members
of -Wpedantic do not need to be included in the Pedantic group directly. I went
back and forth on whether or not to magically generate this group, and the invariant
was that we always wanted extension warnings to be included in -Wpedantic "some how",
but the bookkeeping would be very onerous to manage by hand.
-no-pedantic (and --no-pedantic) is included for completeness, and matches many of the
same kind of flags the compiler already supports. It does what it says: cancels out
-pedantic. One discrepancy is that if one specifies --no-pedantic and -Weverything or
-Wpedantic the pedantic warnings are still enabled (essentially the -W flags win). We
can debate the correct behavior here.
Along the way, this patch nukes some code in TextDiagnosticPrinter.cpp and CXStoredDiagnostic.cpp
that determine whether to include the "-pedantic" flag in the warning output. This is
no longer needed, as all extensions now have a -W flag.
This patch also significantly reduces the number of warnings not under flags from 229
to 158 (all extension warnings). That's a 31% reduction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159875 91177308-0d34-0410-b5e6-96231b3b80d8
given a cursor pointing to a C++ method call or an ObjC message,
returns non-zero if the method/message is "dynamic", meaning:
For a C++ method: the call is virtual.
For an ObjC message: the receiver is an object instance, not 'super' or a
specific class.
rdar://11779185
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159627 91177308-0d34-0410-b5e6-96231b3b80d8
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159539 91177308-0d34-0410-b5e6-96231b3b80d8
express library-level dependencies within Clang.
This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158888 91177308-0d34-0410-b5e6-96231b3b80d8
That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.
However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.
It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?
Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158807 91177308-0d34-0410-b5e6-96231b3b80d8
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158771 91177308-0d34-0410-b5e6-96231b3b80d8
diag-build acts as a wrapper for 'diagtool show-enabled', in the same way
that scan-build acts as a wrapper for the static analyzer. The common case is
simple: use 'diag-build make' or 'diag-build xcodebuild' to list the warnings
enabled for the first compilation command we see. Other build systems require
you to manually specify "dry-run" and "use $CC and $CXX"; if there is a build
system you are interested in, please add it to the switch statement.
diag-build is fairly stupid right now, but it serves its basic purpose.
Hopefully it can grow to meet any additional requirements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158682 91177308-0d34-0410-b5e6-96231b3b80d8
in the same line do not override getting a cursor for the previous declaration.
e.g:
int x, y;
@synthesize prop1, prop2;
pointing at 'x'/'prop1' would give 'y'/'prop2' because their source ranges overlap.
rdar://11361113
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158258 91177308-0d34-0410-b5e6-96231b3b80d8
AST: For auto-synthesized ivars give them the location of the related
property (previously they had no source location). This allows them
to be indexed by libclang.
libclang: Make sure synthesized ivars are indexed before the methods that
may reference them.
Fixes rdar://11607001.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158189 91177308-0d34-0410-b5e6-96231b3b80d8
The integral APSInt value is now stored in a decomposed form and the backing
store for large values is allocated via the ASTContext. This way its not
leaked as TemplateArguments are never destructed when they are allocated in
the ASTContext. Since the integral data is immutable it is now shared between
instances, making copying TemplateArguments a trivial operation.
Currently getting the integral data out of a TemplateArgument requires creating
a new APSInt object. This is cheap when the value is small but can be expensive
if it's not. If this turns out to be an issue a more efficient accessor could
be added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158150 91177308-0d34-0410-b5e6-96231b3b80d8
show-enabled uses the command line you give it to build a CompilerInstance,
so any flags you pass will be processed as if running clang proper.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157842 91177308-0d34-0410-b5e6-96231b3b80d8
Load custom plugins when running scan-build. This is useful when
additional static analysis Checkers must be provided via clang's plugin
interface.
Loading additional plugins can now be done via the scan-build call:
scan-build -load-plugin <plugin.so>
A patch by Thomas Hauth.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157452 91177308-0d34-0410-b5e6-96231b3b80d8
Plus, a patch for scan-build.
* mdoc corrections
* slightly more compact output
* same license as scan-build
* DESCRIPTION describes
* Default checkers corrected & explained
* Authors credited
The patch adds support for --help-checkers. It just lists the default
checkers by recursively invoking "scan-build -h" and looking for the
magic '+' signs.
Patch by James Lowden!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157411 91177308-0d34-0410-b5e6-96231b3b80d8
To do that, keep track of the location of the protocol id in the ObjCProtocolExpr
AST node.
rdar://11190837
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156890 91177308-0d34-0410-b5e6-96231b3b80d8
Arnaud A. de Grandmaison
Manuel Klimek
Ted Kremenek
NAKAMURA Takumi
Richard Smith
Argyrios Kyrtzidis
Dmitri Gribenko
Jordan Rose
Anna Zaks
Chandler Carruth
Rafael Espindola
Chad Rosier
Benjamin Kramer
Francois Pichet
Douglas Gregor