If a function declaration is found inside a template function as in:
template<class T> void f() {
void g(int x = T::v) except(T::w);
}
it must be instantiated along with the enclosing template function,
including default arguments and exception specification.
Together with the patch committed in r240974 this implements DR1484.
Differential Revision: http://reviews.llvm.org/D11194
llvm-svn: 245810
So, we now reject that. We also warn for any external-linkage global
variable named main in C, because it results in undefined behavior.
PR: 24309
Differential Revision: http://reviews.llvm.org/D11658
Reviewed by: rsmith
llvm-svn: 245051
the identifier table. This is redundant, since the TU-scope lookups are also
serialized as part of the TU DeclContext, and wasteful in a number of ways. We
still emit the decls for PCH / preamble builds, since for those we want
identical results, not merely semantically equivalent ones.
llvm-svn: 242855
We referred to all declaration in definitions in our diagnostic messages
which is can be inaccurate. Instead, classify the declaration and emit
an appropriate diagnostic for the new declaration and an appropriate
note pointing to the old one.
This fixes PR24116.
llvm-svn: 242190
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620
We didn't check the return result of BuildDecltypeType, resulting in us
crashing when we tried to grab the canonical version of the type.
This fixes PR23995.
llvm-svn: 241131
This patch implements the functionality specified by DR948.
The changes are two fold. First, the parser was modified
to allow 'constexpr's to appear in condition declarations
(which was a hard error before). Second, Sema was modified
to cleanup maybe odr-used declarations by way of a call to
'ActOnFinishFullExpr'. As 'constexpr's were not allowed in
condition declarations before the cleanup wasn't necessary
(such declarations were always odr-used).
This fixes PR22491.
Differential Revision: http://reviews.llvm.org/D8978
llvm-svn: 240707
The method wasn't an overrider but didn't have 'virtual' textually
written because our CXXMethodDecl was an out-of-line definition. Make
sure we use the canonical decl instead.
This fixes PR23629.
llvm-svn: 237999
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
llvm-svn: 237482
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
We didn't correctly expect a QualifiedTypeLoc when faced with fixing a
variable array type into a constant array type.
Differential Revision: http://reviews.llvm.org/D8958
llvm-svn: 235251
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
llvm-svn: 235166
Previously, many error messages would simply be "read-only variable is not
assignable" This change provides more information about why the variable is
not assignable, as well as note to where the const is located.
Differential Revision: http://reviews.llvm.org/D4479
llvm-svn: 234677
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
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
This reapplies r230044 with a fixed configure+make build and updated
dependencies and testcase requirements. Over the last iteration this
version adds
- missing target requirements for testcases that specify an x86 triple,
- a missing clangCodeGen.a dependency to libClang.a in the make build.
rdar://problem/19104245
llvm-svn: 230423
template partial ordering rules. This rule applies per pair of types being
compared, not per pair of function templates being compared.
llvm-svn: 229965
This fixes PR22492, which is in response to CWG issue #1204.
Per the CWG issue 'contexpr' variables are now allowed in
for range loops.
llvm-svn: 229716
This fixes PR22492, which is in response to CWG issue #1204.
Per the CWG issue 'contexpr' variables are now allowed in
for range loops.
llvm-svn: 229543
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
NAKAMURA Takumi