* Treat compound assignment as a use, at Jordy's request.
* Always add compound assignments into the CFG, so we can correctly diagnose the use in 'return x += 1;'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160334 91177308-0d34-0410-b5e6-96231b3b80d8
use out of TransferFunctions, and compute it in advance rather than on-the-fly.
This allows us to handle compound assignments with DeclRefExprs on the RHS
correctly, and also makes it trivial to treat const& function parameters as not
initializing the argument. The patch also makes both of those changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160330 91177308-0d34-0410-b5e6-96231b3b80d8
This code is very sensitive to the difference between "columns" as printed
and "bytes" (SourceManager columns). All variables are now named explicitly
and our assumptions are (hopefully) documented as both comment and assertion.
Whether parseable fixits should use byte offsets or Unicode character counts
is pending discussion on the mailing list; currently the implementation uses
bytes (and has no problems on lines containing multibyte characters).
This has been added to the user manual.
<rdar://problem/11877454>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160319 91177308-0d34-0410-b5e6-96231b3b80d8
This function has two versions. The first one is used for a register operand.
The second one is used for an immediate number.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160308 91177308-0d34-0410-b5e6-96231b3b80d8
pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160246 91177308-0d34-0410-b5e6-96231b3b80d8
as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160245 91177308-0d34-0410-b5e6-96231b3b80d8
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160244 91177308-0d34-0410-b5e6-96231b3b80d8
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("hidden"))) zed;
Which is a bit silly and got a lot noisier now that we correctly handle
visibility pragmas. This patch fixes that and also has some extra quality
improvements:
* We now produce an error instead of a warning for
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("default"))) zed;
* The "after definition" warning now points to the new attribute that is
ignored instead of pointing to the declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160227 91177308-0d34-0410-b5e6-96231b3b80d8
instead push the terminator for the branch down into the basic blocks of the subexpressions of '&&' and '||'
respectively. This eliminates some artifical control-flow from the CFG and results in a more
compact CFG.
Note that this patch only alters the branches 'while', 'if' and 'for'. This was complex enough for
one patch. The remaining branches (e.g., do...while) can be handled in a separate patch, but they
weren't immediately tackled because they were less important.
It is possible that this patch introduces some subtle bugs, particularly w.r.t. to destructor placement.
I've tried to audit these changes, but it is also known that the destructor logic needs some refinement
in the area of '||' and '&&' regardless (i.e., their are known bugs).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160218 91177308-0d34-0410-b5e6-96231b3b80d8
AVX). Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size. Thus, very large vectors will be over-aligned with no
benefit. Target owners should set this target max.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160209 91177308-0d34-0410-b5e6-96231b3b80d8
uninitialized variable use, walk back over branches where we've reached all the
non-null successors, not just cases where we've reached all successors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160206 91177308-0d34-0410-b5e6-96231b3b80d8
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160161 91177308-0d34-0410-b5e6-96231b3b80d8
If a non-unicode locale is used, the unicode character is escaped and any
byte that is in the escaped representation but not the semicolon will
become whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160113 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were using the static type of the base object to inline
methods, whether virtual or non-virtual. Now, we try to see if the base
object has a known type, and if so ask for its implementation of the method.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160094 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR13314, clang crashing on blocks refering to an enclosing local
when the enclosing function returns void.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160089 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160078 91177308-0d34-0410-b5e6-96231b3b80d8
Filed PR13334 for the cases that cause the compiler to crash, and
PR13335 for the cases where we should be recovering more gracefully.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160070 91177308-0d34-0410-b5e6-96231b3b80d8
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160068 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation depends on the template, its arguments and parameters, but not
where it is instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160034 91177308-0d34-0410-b5e6-96231b3b80d8
there's something going on there. Remove the unconditional line entry
and only add one if we're emitting cleanups (any other statements
would be handled normally).
Fixes rdar://9199234
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160033 91177308-0d34-0410-b5e6-96231b3b80d8
C++ method calls and C function calls both appear as CallExprs in the AST.
This was causing crashes for an object that had a 'free' method.
<rdar://problem/11822244>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160029 91177308-0d34-0410-b5e6-96231b3b80d8
In order to accomplish this, we now build the callee's stack frame
as part of the CallEnter node, rather than the subsequent BlockEdge node.
This should not have any effect on perceived behavior or diagnostics.
This makes it safe to re-enable inlining of member overloaded operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160022 91177308-0d34-0410-b5e6-96231b3b80d8
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
Lots of tests are using an explicit target triple w/o first checking that the
target is actually available. Add a REQUIRES clause to a bunch of them. This should
hopefully unbreak bots which don't configure w/ all targets enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159949 91177308-0d34-0410-b5e6-96231b3b80d8
Previously it was possible to get an infinite-loop-on-invalid with a namespace
decl within @interface. Since 'namespace' is normally a safe place to retry
top-level parsing, we just didn't consume the token.
This adds a flag that tracks whether we have temporarily left Objective-C
scope to parse a C-like declaration, and uses that to better recover from
parse problems by stopping at possible method declarations and at @end. To
fix the original problem, we do /not/ stop at 'namespace' when in an
Objective-C @interface or @protocol context (but still do in @implementation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159941 91177308-0d34-0410-b5e6-96231b3b80d8
This was a regression introduced during the CallEvent changes; a call to
FunctionDecl::hasBody was also being used to replace the decl found by
lookup with the actual definition. To keep from making this mistake again
(particularly if/when we start inlining Objective-C methods), this commit
adds a "getDefinition()" method to CallEvent, which should do the right
thing under any circumstances.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159940 91177308-0d34-0410-b5e6-96231b3b80d8
Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.
Revert the release notes change (r159766) now that this is just a new warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159939 91177308-0d34-0410-b5e6-96231b3b80d8
* When substituting a reference to a non-type template parameter pack where the
corresponding argument is a pack expansion, transform into an expression
which contains an unexpanded parameter pack rather than into an expression
which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
to be inside the PackExpansionExpr, rather than outside, so the expression
still looks like a pack expansion and can be deduced.
* Teach MarkUsedTemplateParameters that we can deduce a reference to a template
parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
added during alias template substitution).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159922 91177308-0d34-0410-b5e6-96231b3b80d8
expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159909 91177308-0d34-0410-b5e6-96231b3b80d8
-ftemplate-depth limit. There are various ways to get an infinite (or merely
huge) stack of substitutions with no intervening instantiations. This is also
consistent with gcc's behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159907 91177308-0d34-0410-b5e6-96231b3b80d8
multidimensional array of class type. Also, preserve zero-initialization when
evaluating an initializer list for an array, in case the initializers refer to
later elements (which have preceding zero-initialization).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159904 91177308-0d34-0410-b5e6-96231b3b80d8
For some reason GCC decided to call the feature rdrnd instead of rdrand,
which requires translating it for LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159897 91177308-0d34-0410-b5e6-96231b3b80d8
which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159895 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
We use LazyCompoundVals to avoid copying the contents of structs and arrays
around in the store, and when we need to pass a struct around that already
has a LazyCompoundVal we just use the original one. However, it's possible
that the first field of a struct may have a LazyCompoundVal of its own, and
we currently can't distinguish a LazyCompoundVal for the first element of a
struct from a LazyCompoundVal for the entire struct. In this case we should
just drop the optimization and make a new LazyCompoundVal that encompasses
the old one.
PR13264 / <rdar://problem/11802440>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159866 91177308-0d34-0410-b5e6-96231b3b80d8
This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point operations. Available modes are:
- Fast: Form fused operations anywhere.
- On: Form fused operations where allowed by FP_CONTRACT. This is the default
mode.
- Off: Don't form fused operations (in future this may be relaxed to forming
fused operations where it can be proved that the result won't be
affected).
Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off'
modes are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159794 91177308-0d34-0410-b5e6-96231b3b80d8
that the migrator handles) but return their instances as 'id', resulting
in the compiler resolving 'objectForKey:' as the method from NSDictionary.
When checking if we can convert to subscripting syntax, check whether
the receiver is a result of a class method from a hardcoded list of
such classes. In such a case return the specific class as the interface
of the receiver.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159788 91177308-0d34-0410-b5e6-96231b3b80d8
NAKAMURA Takumi
Rafael Espindola
Richard Smith
Jordan Rose
Ted Kremenek
Simon Atanasyan
David Blaikie
Alexander Kornienko
Daniel Jasper
David Chisnall
Eric Christopher
Chad Rosier
Nuno Lopes
Tanya Lattner
Dmitri Gribenko
Timur Iskhodzhanov
Benjamin Kramer
John McCall
Nico Weber
Justin Holewinski
DeLesley Hutchins
Arnaud A. de Grandmaison
Manuel Klimek
Fariborz Jahanian
Jim Grosbach
Lang Hames
Argyrios Kyrtzidis