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
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
llvm-svn: 226751
We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type. Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'? It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
llvm-svn: 226653
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
There was already an explicit check for that for the first decl. Move that
to a different place so that it's called for the following decls too. Also
don't randomly set the BitfieldSize ExprResult to true (this sets a pointer to
true internally).
Found by SLi's bot.
llvm-svn: 226306
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
clang tries to produce a helpful diagnostic for the traiilng '...', but the
code that r216778 added for this doesn't expect an invalid trailing return type.
Add code to explicitly handle this.
Having explicit code for this but not for other things looks a bit strange, but
trailing return types are special in that they have a separate existence bit in
addition to the type (see r158348).
llvm-svn: 224974
hasDeclaratorForAnonDecl, getDeclaratorForAnonDecl and
getTypedefNameForAnonDecl are expected to handle the case where
NamedDeclOrQualifier holds the wrong type or nothing at all.
llvm-svn: 224912
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
This code was written with the intent that a pointer could be null but
we dyn_cast'd it anyway. Change the dyn_cast to a dyn_cast_or_null.
This fixes PR21933.
llvm-svn: 224411
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
llvm-svn: 224375
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
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
Specifically, when we have this situation:
struct A {
template <typename T> struct B {
int m1 = sizeof(A);
};
B<int> m2;
};
We can't parse m1's initializer eagerly because we need A to be
complete. Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.
Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.
Fixes PR19195.
Reviewed By: rsmith
Differential Revision: http://reviews.llvm.org/D5690
llvm-svn: 222192
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
This is a re-commit of r219977:
r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2.
(That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of
'this' within a template.)
r219977 was a re-commit of r217995, r218011, and r218053:
r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC.
(Incorrect overload resolution in the presence of using-declarations.)
It was re-committed in r219977 with a workaround for the MSVC rejects-valid.
r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of
unbraced range-based for loop).
llvm-svn: 221750
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
It broke some builders. I guess it'd be reproducible with --vg.
Failing Tests (3):
Clang :: CXX/except/except.spec/p1.cpp
Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp
Clang :: SemaTemplate/instantiate-exception-spec.cpp
llvm-svn: 220038
non-dependent types, in CXXScalarValueInitExprs and in the
nested-name-specifier or template arguments of a DeclRefExpr in particular.
llvm-svn: 220028
reverted in r218058 because they triggered a rejects-valid bug in MSVC.
Original commit message from r217995:
Instantiate exception specifications when instantiating function types (other
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
llvm-svn: 219977
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
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
r218053: Use exceptions() instead of getNumExceptions()/getExceptionType() to avoid
r218011: Work around MSVC parser bug by putting redundant braces around the body of
r217997: Skip parens when detecting whether we're instantiating a function declaration.
r217995: Instantiate exception specifications when instantiating function types (other
The Windows build was broken for 16 hours and no one had any good ideas of how to
fix it. Reverting for now to make the builders green. See the cfe-commits thread [1] for
more info.
This was the build error (from [2]):
C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1590) : error C2668: '`anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType' : ambiguous call to overloaded function
C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1313): could be 'clang::QualType `anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)'
with
[
Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>
]
c:\bb-win7\ninja-clang-i686-msc17-r\llvm-project\clang\lib\sema\TreeTransform.h(4532): or 'clang::QualType clang::TreeTransform<Derived>::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)'
with
[
Derived=`anonymous-namespace'::TemplateInstantiator,
Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>
]
while trying to match the argument list '(clang::TypeLocBuilder, clang::FunctionProtoTypeLoc, clang::CXXRecordDecl *, unsigned int, clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>)'
1. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115011.html
2. http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10515/steps/build_clang_tools_1/logs/stdio
llvm-svn: 218058
The reasoning is that this construct is accepted by all compilers and valid in
C++11, so it doesn't seem like a useful warning to have enabled by default.
Building with -pedantic, -Wbind-to-temporary-copy, or -Wc++98-compat still
shows the warning.
The motivation is that I built re2, and this was the only warning that was
emitted during the build. Both changing re2 to fix the warning and detecting
clang and suppressing the warning in re2's build seem inferior than just giving
the compiler a good default for this warning.
Also move the cxx98compat version of this warning to CXX98CompatPedantic, and
update tests accordingly.
llvm-svn: 218008
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
llvm-svn: 217995
"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
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
before retrying the initialization to produce diagnostics. Otherwise, we may
fail to produce any diagnostics, and silently produce invalid AST in a -Asserts
build. Also add a note to this codepath to make it more clear why we were
trying to create a temporary.
llvm-svn: 217197
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
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
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
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.
Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.
llvm-svn: 213386
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
C++ [basic.start.main]p1: "It shall have a return type of type int"
ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode
C.
llvm-svn: 212171
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
We should treat tentative definitions as undefined for the purpose of
ODR-use linkage checking.
This broke somewhere around r149731 when tests were disabled.
Note that test coverage for these diagnostics is generally lacking due to a
separate issue (PR19910: Don't suppress unused/undefined warnings when there
are errors).
llvm-svn: 209996
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
The conventional form is '<action> to silence this warning'.
Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.
llvm-svn: 209052
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
Larisse Voufo