| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
hierarchy inversion with regards to other catch handlers for the same block.
llvm-svn: 234375
|
|
|
|
| |
llvm-svn: 233391
|
|
|
|
|
|
|
|
| |
A parameter pack after a default argument is now valid.
PR23029.
llvm-svn: 233377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
llvm-svn: 232788
|
|
|
|
| |
llvm-svn: 229829
|
|
|
|
| |
llvm-svn: 229828
|
|
|
|
| |
llvm-svn: 229827
|
|
|
|
| |
llvm-svn: 229826
|
|
|
|
| |
llvm-svn: 229825
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 229338
|
|
|
|
|
|
| |
macro. NFC; Clang edition.
llvm-svn: 229336
|
|
|
|
| |
llvm-svn: 229229
|
|
|
|
|
|
|
|
|
| |
always use the normal copy-initialization rules. Remove a special case that
tries to stay within the list initialization checker here; that makes us do the
wrong thing when list-initialization of an aggregate would not perform
aggregate initialization.
llvm-svn: 228897
|
|
|
|
|
|
|
|
| |
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
llvm-svn: 228896
|
|
|
|
|
|
|
|
|
|
| |
initializer of the form {x}, where x is of type C or a type derived from C,
perform *non-list* initialization of the entity from x, but create a
CXXConstructExpr that knows that we used list-initialization syntax.
Plus some fixes to ensure we mangle correctly in this and related cases.
llvm-svn: 228276
|
|
|
|
| |
llvm-svn: 227279
|
|
|
|
|
|
| |
overlooked a few things, but this implementation comes straight from the DR resolution itself.
llvm-svn: 227224
|
|
|
|
|
|
|
| |
selects a deleted function, the outer function is still a candidate even though
the initialization sequence is "otherwise ill-formed".
llvm-svn: 227169
|
|
|
|
|
|
|
|
|
|
| |
same-type object.
Only the first two items for now, changing Sections 8.5.4 [dcl.init.list] paragraph 3 and 13.3.1.7 [over.match.list] paragraph 1,
so that defining class objects and character arrays using uniform initialization syntax is actually treated as list initialization
and before it is treated aggregate initialization.
llvm-svn: 227022
|
|
|
|
|
|
| |
Warn on inaccessible direct base
llvm-svn: 226423
|
|
|
|
|
|
|
|
|
|
|
| |
even though every basic source character literal has the same numerical value
as a narrow or wide character literal.
It appears that the FreeBSD folks are trying to use this macro to mean
something other than what the relevant standards say it means, but their usage
is conforming, so put up with it.
llvm-svn: 225751
|
|
|
|
|
|
| |
lambda-expression in C++11, to match the C++14 rules.
llvm-svn: 224620
|
|
|
|
|
|
| |
declared return type (including a trailing-return-type in C++14).
llvm-svn: 224561
|
|
|
|
| |
llvm-svn: 224401
|
|
|
|
|
|
| |
type.
llvm-svn: 224388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.
While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.
Fixes PR21839.
llvm-svn: 224287
|
|
|
|
|
|
| |
having a deleted default constructor.
llvm-svn: 223953
|
|
|
|
|
|
|
|
|
| |
arguments).
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
|
|
|
|
|
|
|
| |
is a re-commit of Doug's r154844 (modernized and updated to fit into current
Clang).
llvm-svn: 221918
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows 'namespace A::B { ... }' as a shorthand for 'namespace A {
namespace B { ... } }'. We already supported this correctly for error recovery;
promote that support to a full implementation.
This is not the right implementation: we do not maintain source fidelity
because we desugar the nested namespace definition in the parser. This is
tricky to avoid, since the definition genuinely does inject one named
entity per level in the namespace name.
llvm-svn: 221574
|
|
|
|
|
|
|
|
| |
complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.
llvm-svn: 220343
|
|
|
|
|
|
| |
tests showing what we get wrong.
llvm-svn: 220009
|
|
|
|
| |
llvm-svn: 218591
|
|
|
|
| |
llvm-svn: 218580
|
|
|
|
|
|
|
|
|
| |
that function, and apart from being slow, this is unnecessary: ADL can trigger
instantiations that are not permitted here. The standard isn't *completely*
clear here, but this seems like the intent, and in any case this approach is
permitted by [temp.inst]p7.
llvm-svn: 218330
|
|
|
|
| |
llvm-svn: 217844
|
|
|
|
| |
llvm-svn: 217606
|
|
|
|
|
|
|
|
| |
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.
llvm-svn: 217293
|
|
|
|
|
|
|
|
| |
x64 but x86.
Note, i686-cygwin doesn't use thiscall.
llvm-svn: 217234
|
|
|
|
|
|
|
|
| |
use __thiscall. (This doesn't actually work for MSVC; they don't allow the
__thiscall qualifier here, but it's sufficient to demonstrate that we do
implement the intent of the DR.)
llvm-svn: 217213
|
|
|
|
|
|
| |
This is a follow-up to r216841.
llvm-svn: 217204
|
|
|
|
|
|
| |
directly written in strictly-conforming source code).
llvm-svn: 216969
|
|
|
|
| |
llvm-svn: 216953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to incompatibility of attribute(thiscall).
With targeting i686-win32,
error: 'error' diagnostics seen but not expected:
File clang/test/CXX/drs/dr5xx.cpp Line 521: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
File clang/test/CXX/drs/dr5xx.cpp Line 518: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
File clang/test/CXX/drs/dr5xx.cpp Line 518: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
error: 'note' diagnostics seen but not expected:
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
File clang/test/CXX/drs/dr5xx.cpp Line 521: in instantiation of function template specialization 'dr547::f<void () __attribute__((thiscall)) const, dr547::S>' requested here
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
7 errors generated.
llvm-svn: 216841
|
|
|
|
| |
llvm-svn: 216834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang forgot that '++s.m' was a bitfield l-value and permit it's address
to be taken; this would crash at CodeGen-time.
Instead, propagate the object-kind when we see the prefix
increment/decrement.
This fixes PR20496.
Differential Revision: http://reviews.llvm.org/D4733
llvm-svn: 214386
|
|
|
|
|
|
|
|
| |
This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the diagnostic, see
the review thread linked to from the bug for a few notes on that approach.
llvm-svn: 213725
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
namespace.
llvm-svn: 210080
|