Richard Smith [Thu, 4 Jul 2013 00:13:48 +0000 (00:13 +0000)]
PR16480: Reimplement token-caching for constructor initializer lists. This
previously didn't work if a mem-initializer-id had a template argument which
contained parentheses or braces.
We now implement a simple rule: just look for a ') {' or '} {' that is not
nested. The '{' is assumed to start the function-body. There are still two
cases which we misparse, where the ') {' comes from a compound literal or
from a lambda. The former case is not valid C++, and the latter will probably
not be valid C++ once DR1607 is resolved, so these seem to be of low value,
and we do not regress on them with this change. EDG and g++ also misparse
both of these cases.
Bill Schmidt [Wed, 3 Jul 2013 20:54:09 +0000 (20:54 +0000)]
"bool" should be a context-sensitive keyword in Altivec mode.
PR16456 reported that Clang implements a hybrid between AltiVec's
"Keyword and Predefine Method" and its "Context Sensitive Keyword
Method," where "bool" is always a keyword, but "vector" and "pixel"
are context-sensitive keywords. This isn't permitted by the AltiVec
spec. For consistency with gcc, this patch implements the Context
Sensitive Keyword Method for bool, and stops treating true and false
as keywords in Altivec mode.
The patch removes KEYALTIVEC as a trigger for defining these keywords
in include/clang/Basic/TokenKinds.def, and adds logic for "vector
bool" that mirrors the existing logic for "vector pixel." The test
case is taken from the bug report.
Eli Bendersky [Wed, 3 Jul 2013 19:19:12 +0000 (19:19 +0000)]
Add target hook CodeGen queries when generating builtin pow*.
Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.
Jordan Rose [Wed, 3 Jul 2013 16:20:29 +0000 (16:20 +0000)]
With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check.
Previously, the CMake build still tried to link clang against the static
analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off.
Furthermore, clang-check depends on the analyzer, so it should be disabled
(in both CMake and configure builds).
In theory, clang-check could be made to conditionally include analyzer
support (like clang itself), but for now this at least gets a CMake ALL_BUILD
working.
Bill Schmidt [Wed, 3 Jul 2013 15:36:02 +0000 (15:36 +0000)]
Fix PR16454: Don't #include altivec.h when preprocessing assembly.
When the -maltivec flag is present, altivec.h is auto-included for the
compilation. This is not appropriate when the job action is to
preprocess a file containing assembly code. So don't do that.
I was unable to convert the test in the bug report into a regression
test. The original symptom was exposed with:
However, this test passes for some reason even on a clang built
without the fix. I'd be happy to add a test case but at this point
I'm not able to figure one out, and I don't want to hold up the patch
unnecessarily. Please let me know if you have ideas.
Daniel Jasper [Wed, 3 Jul 2013 10:34:47 +0000 (10:34 +0000)]
Don't insert confusing line breaks in comparisons.
In general, clang-format breaks after an operator if the LHS spans
multiple lines. Otherwise, this can lead to confusing effects and
effectively hide the operator precendence, e.g. in
This patch removes this rule for comparisons, if the LHS is not a binary
expression itself as many users were wondering why clang-format inserts
an unnecessary linebreak.
Pavel Labath [Wed, 3 Jul 2013 08:23:49 +0000 (08:23 +0000)]
[analyzer] Improve handling of noreturn destructors
Summary:
The analyzer incorrectly handled noreturn destructors which were hidden inside
function calls. This happened because NoReturnFunctionChecker only listened for
PostStmt events, which are not executed for destructor calls. I've changed it to
listen to PostCall events, which should catch both cases.
Allow typo correction to try removing nested name specifiers.
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
Look for corrections in enclosing namespaces that require a global NestedNameSpecifier.
CorrectTypo will now see and consider those corrections that are effectively
shadowed by other declarations in a closer context when resolved via an
unqualified lookup. This involves adding any parent namespaces to the set of
namespaces as fully-qualified name specifiers, and also adding potential
corrections that passed name lookup but were rejected by the given
CorrectionCandidateCallback into the set of failed corrections that should be
tried with the set of namespace specifiers.
Unlike Itanium, there is no code to indicate the beginning of a
parameter pack. I tested this with MSVC 2013, which is the only version
that implements variadic templates so far.
This is needed to compile APInt.cpp for the MS C++ ABI.
Eli Friedman [Tue, 2 Jul 2013 17:52:28 +0000 (17:52 +0000)]
More fixes for block mangling.
Make sure we properly treat names defined inside a block as local
names. There are basically three fixes here. One, correctly
treat blocks as a context where we need to use local-name mangling using
the new isLocalContainerContext helper. Two, make
CXXNameMangler::manglePrefix handle local names in a consistent way.
Three, extend CXXNameMangler::mangleLocalName so it can mangle a block
correctly.
Jordan Rose [Tue, 2 Jul 2013 16:50:24 +0000 (16:50 +0000)]
[analyzer] Pointers-to-members are (currently) Locs, not NonLocs.
While we don't model pointers-to-members besides "null" and "non-null",
we were using Loc symbols for valid pointers and NonLoc integers for the
null case. This hit the assert committed in r185401.
Fixed by using a true (Loc) null for null member pointers.
Daniel Jasper [Tue, 2 Jul 2013 13:20:35 +0000 (13:20 +0000)]
Fix ranges computed by git clang-format.
Before, the computed byte range would include the trailing newline.
clang-format on the other hand counts whitespace as belonging to the
following token, so that git-clang-format inadvertendly reformats the
first unmodified line as well.
It is not entirely clear whether clang-format's behavior itself should
be modified, but for now this seems to be a safe change.
Pavel Labath [Tue, 2 Jul 2013 09:38:48 +0000 (09:38 +0000)]
Teach static analyzer about AttributedStmts
Summary:
Static analyzer used to abort when encountering AttributedStmts, because it
asserted that the statements should not appear in the CFG. This is however not
the case, since at least the clang::fallthrough annotation makes it through.
This commit simply makes the analyzer ignore the statement attributes.
Eli Friedman [Tue, 2 Jul 2013 02:01:18 +0000 (02:01 +0000)]
Don't skip lambdas when mangling local vars.
This commit rearranges the logic in CXXNameMangler::mangleLocalName and
GetLocalClassDecl so that it doesn't accidentally skip over lambdas. It
also reduces code duplication a bit.
Eli Friedman [Mon, 1 Jul 2013 20:53:07 +0000 (20:53 +0000)]
Simplify linkage code for static local vars.
The key insight here is that weak linkage for a static local variable
should always mean linkonce_odr, because every file that needs it will
generate a definition. We don't actually care about the precise linkage
of the parent context. I feel a bit silly that I didn't realize this before.
Eli Friedman [Mon, 1 Jul 2013 20:22:57 +0000 (20:22 +0000)]
Fix mangling for block literals.
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
Daniel Jasper [Mon, 1 Jul 2013 16:43:38 +0000 (16:43 +0000)]
Fix incorrect token counting introduced by r185319.
This lead to weird formatting.
Before:
DoSomethingWithVector({ {} /* No data */ }, {
{ 1, 2 }
});
After:
DoSomethingWithVector({ {} /* No data */ }, { { 1, 2 } });
Avoid column limit violation in block comments in certain cases.
Summary:
Add penalty when an excessively long line in a block comment can not be
broken on a leading whitespace. Lack of this addition can lead to severe column
width violations when they can be easily avoided.
Following the modification introduced in llvm by commit 185311
The build system is currently miss-identifying GNU/kFreeBSD as FreeBSD.
This kind of simplification is sometimes useful, but in general it's not correct.
As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.
The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.
Stephen Lin [Sun, 30 Jun 2013 20:40:16 +0000 (20:40 +0000)]
Restore r184205 and associated commits (after commit of r185290)
This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs.
Richard Smith [Sun, 30 Jun 2013 10:40:20 +0000 (10:40 +0000)]
Teach -Wunsequenced that the side-effects of a function evaluation are sequenced
before the value computation of the result. In C, this is implied by there being
a sequence point after their evaluation, and in C++, it's implied by the
side-effects being sequenced before the expressions and statements in the
function body.
Richard Smith [Sun, 30 Jun 2013 09:48:50 +0000 (09:48 +0000)]
Reinstate r185229, reverted in r185256, with a tweak: further ignore the
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.
Original commit message:
PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.
When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.
When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).
James Dennett [Sun, 30 Jun 2013 03:05:49 +0000 (03:05 +0000)]
Add enumerators to TestVisitor::Language to allow visitor tests to
explicitly specify use of C++98 or C++11. Lang_CXX is preserved as
an alias for Lang_CXX98.
This does not add Lang_CXX1Y or Lang_C11, on the assumption that it's
better to add them if/when they are needed.
(This is a prerequisite for a test in a later patch for RecursiveASTVisitor.)
Richard Smith [Fri, 28 Jun 2013 22:03:51 +0000 (22:03 +0000)]
PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.
When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.
When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).
Summary:
Some valid pre-C++11 constructs change meaning when lexed in C++11
mode, e.g.
#define x(_a) printf("foo"_a);
(example from http://llvm.org/bugs/show_bug.cgi?id=16342). "foo"_a is treated as
a user-defined string literal when parsed in C++11 mode.
In order to deal with this correctly, we need to set lexing mode according to
which standard the code conforms to. We already have a configuration value for
this (FormatStyle.Standard), which seems to be appropriate to use in this case
as well.
Richard Smith [Fri, 28 Jun 2013 04:37:53 +0000 (04:37 +0000)]
Lazily deserialize function template specializations. This fixes a cycle in
module deserialization / merging, and more laziness here is general goodness.
Eli Friedman [Thu, 27 Jun 2013 23:21:55 +0000 (23:21 +0000)]
Switch Decl instantiation to DeclNodes.inc.
This replaces a long list of declarations for visitor functions with
a list generated from DeclNodes.inc. Nothing really interesting came
out of it; we had comprehensive coverage anyway
(excluding FriendTemplateDecls).
John McCall [Thu, 27 Jun 2013 22:43:24 +0000 (22:43 +0000)]
Ensure that debugger calls to signature-less functions default to
passing arguments in the fixed style.
We have an abstraction for deciding this, but it's (1) deep in
IR-generation, (2) necessarily tied to exact argument lists, and
(3) triggered by unprototyped function types, which we can't
legitimately make in C++ mode. So this solution, wherein Sema
rewrites the function type to an exact prototype but leaves the
variadic bit enabled so as to request x86-64-like platforms to
pass the extra variadic info, is very much a hack, but it's one
that works in practice on the platforms that LLDB will support
in the medium term --- the only place we know of where it's a
problem is instance methods in Windows, where variadic functions
are implicitly cdecl. We may have a more abstracted base on which
to build a solution by then.
This reverts commit r184817. The failure Chandler was seeing was most likely the
bug that Bob Wilson fixed in r184870 (which was a bug caught by these tests).
To be safe, I just checked again on x86-64 mac os x/linux that this test passed
(which it did).
Douglas Gregor [Thu, 27 Jun 2013 20:42:30 +0000 (20:42 +0000)]
Under -fms-extensions, only inject a friend tag name when we didn't see a tag with that name in an enclosing scope.
r177473 made us correctly consider only those declarations in the
enclosing namespace scope when looking for a friend declaration. Under
ms-extensions mode, where we do some level of friend injection, this
meant that we were introducing a new tag type into a different scope
than what Microsoft actually does. Address this by only doing the
friend injection when we didn't see any tag with that name in any
outer scope. Fixes <rdar://problem/14250378>.
Rafael Espindola [Thu, 27 Jun 2013 18:26:26 +0000 (18:26 +0000)]
Small improvements to createOutputFile.
* Use a single stat to find out if the file exists and if it is a regular file.
* Use early returns when possible.
* Add comments explaining why we have each check.
projects / clang / log