off by default, issue a warning if %s directive is used
in formart argument of a function/method declared as
__attribute__((format(CF/NSString, ...)))
To complete rdar://18182443
llvm-svn: 217619
Summary:
cl.exe recognizes /o as a deprecated and undocumented option similar to
/Fe. This patch adds support for this option to clang-cl for /Fe, /Fo
and /Fi. It also ensures that the last option among /o and /F* wins,
if both specified.
This is required at least for building autoconf based software, since
autoconf uses -o to specify the executable output.
This fixes http://llvm.org/PR20894.
Test Plan: The patch includes automated tests.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5308
llvm-svn: 217615
Summary:
http://llvm.org/bugs/show_bug.cgi?id=20892
Add support of C-style formatting enabling/disabling directives. Now the following two styles are supported:
// clang-format on
/* clang-format on */
The flexibility in comments (support of extra spaces and/or slashes, etc.) is deliberately avoided to simplify search in large code bases.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, curdeius, klimek
Differential Revision: http://reviews.llvm.org/D5309
llvm-svn: 217588
Numerous changes, including:
* Changed the way variables and instructions are handled in basic blocks to
be more efficient.
* Eliminated SExprRef.
* Simplified futures.
* Fixed documentation.
* Compute dominator and post dominator trees.
llvm-svn: 217556
1. We were hitting the NextIsPrevious assertion because we were trying
to merge decl chains that were independent of each other because we had
no Sema object to allow them to find existing decls. This is fixed by
delaying loading the "preloaded" decls until Sema is available.
2. We were trying to get identifier info from an annotation token, which
asserts. The fix is to special-case the module annotations in the
preprocessed output printer.
Fixed in a single commit because when you hit 1 you almost invariably
hit 2 as well.
llvm-svn: 217550
actually different. Fixes a surprising link error with nodejs on rpi,
where armv6-netbsd-eabihf turned into armv5e-netbsd-eabihf, which
doesn't lacks the necessary VFP support.
llvm-svn: 217546
This prevents initializers for comdat-folded globals from running multiple times.
Differential Revision: http://reviews.llvm.org/D5281
llvm-svn: 217534
Summary:
Currently, this is done implicitly in Driver::BuildInputs by considering
any invalid input type as linker input.
Test Plan: I don't think this behavior is observable for the reason stated above.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5294
llvm-svn: 217522
On a single line:
switch (a) {
case 1: x = 1; return;
case 2: x = 2; return;
default: break;
}
Not on a single line:
switch (a) {
case 1:
x = 1;
return;
case 2:
x = 2;
return;
default:
break;
}
This partly addresses llvm.org/PR16535. In the long run, we probably want to
lay these out in columns.
llvm-svn: 217501
Pointer-sized alignment is sufficient as we only ever read single values
from the table. Otherwise we'd bump the alignment to 16 bytes in the
backend if the vtable is larger than 16 bytes. This is great for
structures that are accessed with vector instructions or copied around, but
that's simply not the case for vtables.
Shrinks the data segment of a Release x86_64 clang by 0.3%. The wins are
larger for i386 and code bases that use vtables more often than we do.
This matches the behavior of GCC 5.
llvm-svn: 217495
off by default, issue a warning if %s directive is used in
certain CF/NS formatting APIs, to assist user in deprecating
use of such %s in these APIs. rdar://18182443
llvm-svn: 217467
Before:
var regex = / a\//; int i;
After:
var regex = /a\//;
int i;
This required pushing the Lexer into its wrapper class and generating a
new one in this specific case. Otherwise, the sequence get lexed as a
//-comment. This is hacky, but I don't know a better way (short of
supporting regex literals in the Lexer).
Pushing the Lexer down seems to make all the call sites simpler.
llvm-svn: 217444
This was horribly broken due to how the sort predicate works. We would
report a conflict for files with a replacement in the same position but
different names if the length differed. Just ignore paths as this is often
what the user wants. Files can occur with different names (due to symlinks
or relative paths) and we don't ever want to do the same edit in one file
twice.
llvm-svn: 217439
Summary: This fixes PR20883.
Test Plan: The patch includes an automated test.
Reviewers: hansw
Differential Revision: http://reviews.llvm.org/D5256
llvm-svn: 217413
Summary:
This patch implements a new UBSan check, which verifies
that function arguments declared to be nonnull with __attribute__((nonnull))
are actually nonnull in runtime.
To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs
(where applicable) and if function declaration has nonnull attribute specified
for a certain formal parameter, we compare the corresponding RValue to null as
soon as it's calculated.
Test Plan: regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rnk
Differential Revision: http://reviews.llvm.org/D5082
llvm-svn: 217389
Because we may change the name of a FileEntry inside getFile, the name
returned by FileEntry::getName() could be destroyed. This was causing a
use-after-free when searching the HeaderFileInfo on-disk hashtable for a
module or pch.
llvm-svn: 217385
There were code paths that are duplicated for constructors and destructors just
because we have both CXXCtorType and CXXDtorsTypes.
This patch introduces an unified enum and reduces code deplication a bit.
llvm-svn: 217383
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
llvm-svn: 217349
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
This innocuous statement to get the identifier info for __va_list_tag
was causing an assertion failure:
NextIsPrevious() && "decl became non-canonical unexpectedly"
if the __va_list_tag identifier was found in a PCH in some
circumstances, because it was looked up before the ASTReader had a Sema
object to use to find existing decls to merge with.
We could possibly move getting the identifier info even later, or make
it lazy if we wanted to, but this seemed like the minimal change.
Now why a PCH would have this identifier in the first place is a bit
mysterious. This seems to be related to the global module index in some
way, because when the test case is built without the global module index
it will not emit an identifier for __va_list_tag into the PCH, but with
the global module index it does.
llvm-svn: 217275
Summary:
Separate the matchers by type and statically dispatch to the right list.
For any node type that we support, it reduces the number of matchers we
run it through.
For node types we do not support, it makes match() a noop.
This change improves our clang-tidy related benchmark by ~30%.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5197
llvm-svn: 217274
It is very common to include headers with DOS-style line endings, such
as windows.h, from source files with Unix-style line endings.
Previously, we would end up with mixed line endings and #endifs that
appeared to be on the same line:
#if 0 /* expanded by -frewrite-includes */
#include <windows.h>^M#endif /* expanded by -frewrite-includes */
Clang treats either of \r or \n as a line ending character, so this is
purely a cosmetic issue.
This has no automated test because most Unix tools on Windows will
implictly convert CRLF to LF when reading files, making it very hard to
detect line ending mismatches. FileCheck doesn't understand {{\r}}
either.
Fixes PR20552.
llvm-svn: 217259
This patch adds support for the 32bit numeric max/min and directed round-to-integral NEON intrinsics that were added as part of v8, along with unit tests.
Patch by Graham Hunter!
llvm-svn: 217242
Before:
e&& e.SomeFunction();
After:
e && e.SomeFunction();
Yeah, this might be useful for C++, too, but it is not such a frequent
pattern there (plus the fix is much harder).
llvm-svn: 217237
Fariborz Jahanian