| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 209389
|
| |
|
|
|
|
| |
comparison check to use this instead of calling Type::getCanonicalTypeInternal
llvm-svn: 209378
|
| |
|
|
|
|
|
|
|
|
|
| |
There are a couple of issues with writing VFS maps that are awkward to
fix within the current mutually recursive approach. Instead, replace
the algorithm with an iterative version that uses an explicit stack of
directories.
Includes tests for cases the old approach was tripping on.
llvm-svn: 209332
|
| |
|
|
| |
llvm-svn: 209322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
Reviewers: rsmith, doug.gregor
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3583
llvm-svn: 209319
|
| |
|
|
|
|
|
|
|
| |
clang was fixed some time ago to always skip "builtins and other cruft" so
tools no longer need hacks like this.
Passes nosetests.
llvm-svn: 209316
|
| |
|
|
| |
llvm-svn: 209304
|
| |
|
|
|
|
|
|
|
| |
Make better diagnostic produced by erroneous switch statement.
It fixes PR19022.
Differential Revision: http://reviews.llvm.org/D3137
llvm-svn: 209302
|
| |
|
|
|
|
|
| |
This is generally a good thing and in this case should also fix the
BUILD_SHARED_LIBS=ON build (see pr19774).
llvm-svn: 209300
|
| |
|
|
|
|
|
|
|
|
|
| |
On test files I ran this on, memory consumption overall went down from
2.5G to 2G, without performance regressions.
I also investigated making DynTypedNode by itself smaller (by pulling
out pointers for everything that doesn't fit in 8 bytes). This led to
another 200-300MB saved, but also introduced a significant regression in
performance due to the memory management overhead.
llvm-svn: 209297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
var object_literal_with_long_name = {
a: 'aaaaaaaaaaaaaaaaaa', b: 'bbbbbbbbbbbbbbbbbb'
};
After:
var object_literal_with_long_name = {
a: 'aaaaaaaaaaaaaaaaaa',
b: 'bbbbbbbbbbbbbbbbbb'
};
llvm-svn: 209296
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In:
struct A {
A()
noexcept(....) {}
};
'A()' is not a macro call.
This fixes llvm.org/PR19814.
llvm-svn: 209294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
goog.array.forEach(array, function() {
doSomething();
doSomething();
},
this);
After:
goog.array.forEach(array, function() {
doSomething();
doSomething();
}, this);
llvm-svn: 209291
|
| |
|
|
| |
llvm-svn: 209289
|
| |
|
|
| |
llvm-svn: 209285
|
| |
|
|
|
|
|
|
|
| |
Also flesh out missing tests, improve diagnostic QOI and fix a couple of corner
cases found in the process.
Fixes PR10606.
llvm-svn: 209276
|
| |
|
|
| |
llvm-svn: 209275
|
| |
|
|
| |
llvm-svn: 209272
|
| |
|
|
| |
llvm-svn: 209268
|
| |
|
|
|
|
|
|
|
|
|
| |
Eliminate createMainFileID() / createMainFileIDForMemBuffer() utility
functions. These didn't add much convenience and conflated two distinct
operations.
This change makes things easier to follow by providing a consistent interface
and getting rid of a bunch of cast-to-voids.
llvm-svn: 209266
|
| |
|
|
|
|
|
|
| |
the return type is already that.
rdar://16961577
llvm-svn: 209264
|
| |
|
|
| |
llvm-svn: 209261
|
| |
|
|
| |
llvm-svn: 209260
|
| |
|
|
| |
llvm-svn: 209257
|
| |
|
|
| |
llvm-svn: 209255
|
| |
|
|
|
|
|
|
| |
Checking if a path starts with another path isn't sufficient for
determining if one is contained within the heirarchy of the other.
We need to ensure that the substring ends at a directory boundary.
llvm-svn: 209250
|
| |
|
|
|
|
|
| |
If we're so keen on saving a dynamic allocation to add the trailing space, we
might as well do it in style.
llvm-svn: 209247
|
| |
|
|
| |
llvm-svn: 209246
|
| |
|
|
|
|
| |
Also add the missing undef in both files.
llvm-svn: 209245
|
| |
|
|
| |
llvm-svn: 209244
|
| |
|
|
|
|
|
|
|
| |
This moves the logic to write a JSON VFS mapping from the C api into
VirtualFileSystem, so that we can use it internally.
No functional change.
llvm-svn: 209241
|
| |
|
|
| |
llvm-svn: 209239
|
| |
|
|
|
|
| |
is more explicit about pointers and const. Did some minor drive-by const correctness fixes and identifier updates as well. No functional changes.
llvm-svn: 209233
|
| |
|
|
|
|
| |
According to Aaron, this is being generated on the server now.
llvm-svn: 209232
|
| |
|
|
| |
llvm-svn: 209231
|
| |
|
|
| |
llvm-svn: 209229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a testcase for r209227, a change in LLVM that automatically sets
visibility to default when the linkage is changed to local (rather than
asserting).
What this testcase triggers is hard to reproduce otherwise: the
`GlobalValue` is created (with non-local linkage), the visibility is set
to hidden, and then the linkage is set to local.
PR19760
llvm-svn: 209228
|
| |
|
|
| |
llvm-svn: 209224
|
| |
|
|
|
|
|
|
|
|
|
| |
This catches issues like:
if ((x & 8) == 4) { ... }
if ((x | 4) != 3) { ... }
Patch by Anders Rönnholm!
llvm-svn: 209221
|
| |
|
|
| |
llvm-svn: 209220
|
| |
|
|
| |
llvm-svn: 209218
|
| |
|
|
|
|
|
|
|
|
| |
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
|
| |
|
|
|
|
|
| |
Based on a patch by jfcaron3@gmail.com!
PR19806
llvm-svn: 209215
|
| |
|
|
|
|
|
|
|
|
|
| |
For targeting i686-msvc, declarations are seen as thiscall like;
void (template_test::S::*)(const int &) __attribute__((thiscall))
void (template_test::S::*)(int) __attribute__((thiscall))
It didn't affect x86_64-msvc.
llvm-svn: 209212
|
| |
|
|
|
|
|
|
| |
part of their subject definition. FunctionTemplateDecls are not what the attribute appertains to in the first place -- it attaches to the underlying FunctionDecl.
The attribute emitter was using FunctionTemplate to map the diagnostic to "functions or methods", but that isn't a particularly clear diagnostic in these cases anyway (since they do not apply to ObjC methods). Updated the attribute emitter to remove custom logic for FunctionTemplateDecl, and updated the test cases for the change in diagnostic wording.
llvm-svn: 209209
|
| |
|
|
| |
llvm-svn: 209205
|
| |
|
|
| |
llvm-svn: 209196
|
| |
|
|
|
|
|
|
|
| |
It appears that Windows doesn't like renaming over open files, which we
do in clearOutputFiles. The file being compiled should be safe to
removed, but this isn't very satisfying - we don't want to manually
manage the lifetime of files we cannot prove have no references.
llvm-svn: 209195
|
| |
|
|
| |
llvm-svn: 209192
|
| |
|
|
| |
llvm-svn: 209191
|