| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a few oddities when formatting multiple nested JavaScript
blocks, e.g.:
Before:
promise.then(
function success() {
doFoo();
doBar();
},
[], function error() {
doFoo();
doBaz();
});
promise.then([],
function success() {
doFoo();
doBar();
},
function error() {
doFoo();
doBaz();
});
After:
promise.then(
function success() {
doFoo();
doBar();
},
[],
function error() {
doFoo();
doBaz();
});
promise.then([],
function success() {
doFoo();
doBar();
},
function error() {
doFoo();
doBaz();
});
llvm-svn: 210097
|
| |
|
|
|
|
|
|
|
| |
This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.
Differential revision: http://reviews.llvm.org/D3778
llvm-svn: 210095
|
| |
|
|
| |
llvm-svn: 210092
|
| |
|
|
|
|
|
|
|
| |
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
llvm-svn: 210091
|
| |
|
|
| |
llvm-svn: 210090
|
| |
|
|
|
|
|
|
|
|
| |
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
llvm-svn: 210083
|
| |
|
|
|
|
|
|
|
| |
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.
llvm-svn: 210079
|
| |
|
|
| |
llvm-svn: 210075
|
| |
|
|
|
|
| |
Aliases in llvm now hold an arbitrary expression.
llvm-svn: 210063
|
| |
|
|
| |
llvm-svn: 210059
|
| |
|
|
|
|
|
|
|
| |
The only remaining user didn't actually use the non-dynamic storage facility
this class provides.
The std::string is transitional and likely to be StringRefized shortly.
llvm-svn: 210058
|
| |
|
|
|
|
|
|
| |
This corresponds to the same change for the MS ABI in r209908.
Differential Revision: http://reviews.llvm.org/D3993
llvm-svn: 210054
|
| |
|
|
| |
llvm-svn: 210047
|
| |
|
|
| |
llvm-svn: 210042
|
| |
|
|
| |
llvm-svn: 210041
|
| |
|
|
| |
llvm-svn: 210039
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instrumentation passes now use attributes
address_safety/thread_safety/memory_safety which are added by Clang frontend.
Clang parses the blacklist file and adds the attributes accordingly.
Currently blacklist is still used in ASan module pass to disable instrumentation
for certain global variables. We should fix this as well by collecting the
set of globals we're going to instrument in Clang and passing it to ASan
in metadata (as we already do for dynamically-initialized globals and init-order
checking).
This change also removes -tsan-blacklist and -msan-blacklist LLVM commandline
flags in favor of -fsanitize-blacklist= Clang flag.
llvm-svn: 210037
|
| |
|
|
| |
llvm-svn: 210033
|
| |
|
|
|
|
|
| |
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.
llvm-svn: 210026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a pattern where evaluation order is used as control flow.
This patch special-cases a commonly occuring version of this pattern.
Before:
Aaaaa *aaa = nullptr;
// ...
aaa &&aaa->f();
After:
Aaaaa *aaa = nullptr;
// ...
aaa && aaa->f();
llvm-svn: 210017
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
auto j = decltype(i) {};
After:
auto j = decltype(i){};
This fixes llvm.org/PR19892.
llvm-svn: 210013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
enum Side
{ LEFT,
RIGHT };
After:
enum Side
{
LEFT,
RIGHT
};
This fixes llvm.org/PR19911.
llvm-svn: 210011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
void someLongFunction(int someLongParameter)
const
{
}
After:
void someLongFunction(
int someLongParameter) const
{
}
This fixes llvm.org/PR19912.
llvm-svn: 210010
|
| |
|
|
| |
llvm-svn: 209993
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=18498
This code was resulting in a crash:
auto L = [](auto ... v) { };
L.operator()<int>(3);
The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.
This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.
Thanks to Richard Smith for the review!
http://reviews.llvm.org/D2135
llvm-svn: 209992
|
| |
|
|
|
|
|
|
|
|
|
| |
extension
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
|
| |
|
|
|
|
|
| |
isExternCTemplate() and getLanguageLinkageTemplate() have nothing to do with
templates despite the dubious naming scheme.
llvm-svn: 209969
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.
A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.
<rdar://problem/16616623>
llvm-svn: 209966
|
| |
|
|
|
|
|
|
|
| |
Also move the attribute-specific dumping to after dumping this and
the Implicit flag.
Differential Revision: http://reviews.llvm.org/D3971
llvm-svn: 209965
|
| |
|
|
|
|
|
|
|
|
| |
identifiers
This failure mode shows up occasionally when users try to include C headers in
C++ projects or when porting from Windows. We might as well recover in the way
the user expected, thus avoiding confusing diagnostic messages at point of use.
llvm-svn: 209963
|
| |
|
|
|
|
|
|
|
|
| |
The checks below can hypothetically apply to converted operator name
identifiers.
In practice there are no builtin macros etc. with those names so there's no
behavioural change to test.
llvm-svn: 209962
|
| |
|
|
| |
llvm-svn: 209959
|
| |
|
|
| |
llvm-svn: 209956
|
| |
|
|
| |
llvm-svn: 209955
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3973
llvm-svn: 209954
|
| |
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209949
|
| |
|
|
|
|
| |
{extract,insert} vector element instructions.
llvm-svn: 209942
|
| |
|
|
|
|
|
| |
consistently, rather than sometimes performing lookup and calling the
LookupResult form. No functionality change intended.
llvm-svn: 209941
|
| |
|
|
|
|
| |
qualified name of a NamedDecl. Patch by Volodymyr Sapsai!
llvm-svn: 209924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.
original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209922
|
| |
|
|
|
|
| |
This reverts commit r209910, which is breaking some of the bots.
llvm-svn: 209911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
|
| |
|
|
|
|
|
| |
an Objective-C object type other than 'id'.
// rdar://16739120
llvm-svn: 209906
|
| |
|
|
|
|
|
|
| |
There shouldn't be any difference in behaviour here, at least not in
any configurations people care about and possibly not in any reachable
configurations.
llvm-svn: 209899
|
| |
|
|
| |
llvm-svn: 209876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
|
| |
|
|
|
|
| |
deleted default constructor
llvm-svn: 209869
|
| |
|
|
| |
llvm-svn: 209867
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|