| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 229450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
|
| |
|
|
|
|
|
|
|
| |
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case that we diagnosed an invalid attribute due to missing or present
arguments, we would return false, indicating to the caller that the parsing
failed. However, we would have added the attribute in ParseAttributeArgsCommon
(which may have been called indirectly through ParseGNUAttributeArgs).
Returning true in this case ensures that a second copy of the attribute is not
added.
I haven't added a test case for this as the existing test will cover this with
the next commit which diagnoses a C++14 attribute applied in C++11 mode. Rather
than duplicating the existing test case, allow the tree to remain without a test
between this and the next change. We would see double warnings in the
[[deprecated()]] applied to a declaration in C++11 mode, which will cause an
error in the cxx0x-attributes test.
llvm-svn: 229446
|
| |
|
|
| |
llvm-svn: 229435
|
| |
|
|
|
|
| |
Update for the API change in r229433
llvm-svn: 229434
|
| |
|
|
| |
llvm-svn: 229432
|
| |
|
|
| |
llvm-svn: 229428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass and return in registers
This is a patch for PR22563 ( http://llvm.org/bugs/show_bug.cgi?id=22563 ).
We were not correctly unwrapping a single 256-bit AVX vector that was defined as an array of 1 inside a struct.
We would generate a <4 x float> param/return value instead of <8 x float> and lose half of the vector.
Differential Revision: http://reviews.llvm.org/D7614
llvm-svn: 229408
|
| |
|
|
| |
llvm-svn: 229404
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug report: http://llvm.org/bugs/show_bug.cgi?id=22561
Clang tries to create ObjCBoxedExpression of type 'NSNumber'
when 'NSNumber' has only forward declaration, this cause a crash later,
when 'Sema' refers to a nil QualType of the whole expression.
Please, refer to the bug report for the better explanation.
llvm-svn: 229402
|
| |
|
|
|
|
|
|
|
| |
For #pragma comment(linker, ...) MSVC expects the comment string to be quoted, but for #pragma comment(lib, ...) the compiler itself quotes the library name.
Since this distinction disappears by the time the directive reaches the backend, move quoting for the "lib" version to the frontend.
Differential Revision: http://reviews.llvm.org/D7653
llvm-svn: 229376
|
| |
|
|
|
|
|
|
| |
subobject initialization is not possible, be sure to note the overall
initialization as having failed so that overload resolution knows that the
relevant candidate is not viable.
llvm-svn: 229353
|
| |
|
|
|
|
| |
__builtin_ia32_pslldqi256 to vector shuffles the backend recognizes. This is a step towards removing the corresponding intrinsics from the backend.
llvm-svn: 229348
|
| |
|
|
|
|
| |
requiring the macro. NFC; Clang edition.
llvm-svn: 229339
|
| |
|
|
| |
llvm-svn: 229338
|
| |
|
|
|
|
| |
macro. NFC; Clang edition.
llvm-svn: 229336
|
| |
|
|
| |
llvm-svn: 229329
|
| |
|
|
| |
llvm-svn: 229327
|
| |
|
|
| |
llvm-svn: 229326
|
| |
|
|
| |
llvm-svn: 229325
|
| |
|
|
| |
llvm-svn: 229295
|
| |
|
|
| |
llvm-svn: 229291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229288
|
| |
|
|
| |
llvm-svn: 229282
|
| |
|
|
| |
llvm-svn: 229264
|
| |
|
|
|
|
|
|
|
|
| |
We had two bugs:
- We were missing the "on" prefix for unresolved operators.
- We didn't handle the mangling of destructors at all.
This fixes PR22584.
llvm-svn: 229255
|
| |
|
|
| |
llvm-svn: 229242
|
| |
|
|
|
|
|
|
| |
generate weak definitions of the sized operator delete (in terms of unsized operator delete). Instead, provide the funcitonality via a new compiler flag, -fdef-sized-delete.
The current implementation causes link-time ODR violations when the delete symbols are exported into the dynamic table.
llvm-svn: 229241
|
| |
|
|
|
|
| |
accident, and accept them even when they begin '//*'.
llvm-svn: 229240
|
| |
|
|
| |
llvm-svn: 229219
|
| |
|
|
|
|
|
| |
they're given a null pointer as an argument, so we do not need to emit null
checks on their results.
llvm-svn: 229213
|
| |
|
|
|
|
|
| |
We could be a little kinder if we did a compare-exchange loop instead of
an atomic-load/store pair.
llvm-svn: 229212
|
| |
|
|
|
|
|
| |
This reverts commit r229123. It was a red herring, the bug was present
without r229082.
llvm-svn: 229205
|
| |
|
|
|
|
|
|
|
| |
Bools are a little tricky, they are i8 in memory and must be coerced
back to i1 before further operations can be performed on them.
This fixes PR22577.
llvm-svn: 229204
|
| |
|
|
|
|
| |
a prebuilt form from a module, prefer the modular form, all else being equal.
llvm-svn: 229188
|
| |
|
|
|
|
|
| |
in the middle of emitting an ODR violation diagnostic. I don't yet have a
reduced testcase for this issue, working on it...
llvm-svn: 229167
|
| |
|
|
|
|
| |
visible through multiple imported modules. No functionality change.
llvm-svn: 229147
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 229145
|
| |
|
|
| |
llvm-svn: 229123
|
| |
|
|
| |
llvm-svn: 229093
|
| |
|
|
| |
llvm-svn: 229092
|
| |
|
|
|
|
|
|
|
|
|
|
| |
declarations and just use the legacy namespace qualifier in this file
and the permanent header name.
The old wrapper header is going away to make LLVM's build more modular,
and without updating Clang I can't easily start to add usage of the new
pass manager to Clang. This should make it more clear in the code which
set of types is doing what.
llvm-svn: 229090
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The /volatile:ms semantics turn volatile loads and stores into atomic
acquire and release operations. This distinction is important because
volatile memory operations do not form a happens-before relationship
with non-atomic memory. This means that a volatile store is not
sufficient for implementing a mutex unlock routine.
Differential Revision: http://reviews.llvm.org/D7580
llvm-svn: 229082
|
| |
|
|
| |
llvm-svn: 229067
|
| |
|
|
|
|
| |
and _mm_srli_si128. This matches Intel documentation and gcc.
llvm-svn: 229066
|
| |
|
|
|
|
| |
header.
llvm-svn: 229065
|
| |
|
|
|
|
| |
We don't need a bool to track this now that we have a stack for it.
llvm-svn: 228982
|
| |
|
|
|
|
|
|
|
|
| |
entity, put the originally-canonical decl IDs in the right places in the redecl
chain rather than reordering them all to the start. If we don't ensure that the
redecl chain order is consistent with the topological module order, we can fail
to make a declaration visible if later declarations are in more IDNSs than
earlier ones (for instance, because the earlier decls are invisible friends).
llvm-svn: 228978
|
| |
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D7575
llvm-svn: 228977
|