If definition of a class is unknown and out-of-line definition of its
member is encountered, do not parse the member declaration.
This change fixes PR18542.
Differential Revision: http://reviews.llvm.org/D8010
llvm-svn: 239483
it doesn't work correctly when a structure is declared before pragma
and then a function with the same name declared after pragma.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10187
llvm-svn: 239466
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
llvm-svn: 237299
This is needed to prevent a TypoExpr from being corrected to a variable
when the TypoExpr is a subexpression of that variable's initializer.
Also exclude more keywords from the correction candidate pool when the
subsequent token is .* or ->* since keywords like "new" or "return"
aren't valid on the left side of those operators.
Fixes PR23140.
llvm-svn: 236519
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
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
During device-side CUDA compilation clang currently complains about
all TLS variables, regardless of whether they are __host__ or
__device__.
This patch suppresses "TLS unsupported" errors for host variables
during device compilation and for device variables during host
compilation.
Differential Revision: http://reviews.llvm.org/D9269
llvm-svn: 235907
VerifyBitField must be called if we are to form a bitfield FieldDecl.
We will not verify the bitfield if the decl is known to be malformed in
other ways; pretend that we don't have a bitfield if this happens.
llvm-svn: 235816
Don't assume it's always is. This prevents a crash in Sema while
trying to merge return type for a builtin w/out function prototype.
PR: 23086
Differential Revision: http://reviews.llvm.org/D9235
Reviewed by: rsmith
llvm-svn: 235806
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
The previous implementation would copy the attribute from the class to
functions that have the class as their return type when the functions
are first declared. This proved to have two flaws:
1) if the class is forward-declared without the attribute and a
function or method with the class as a its return type is declared,
and afterward the class is defined with warn_unused_result, the
function or method would never inherit the attribute, and
2) the check simply failed for functions and methods that are part of
a template instantiation, regardless of whether the class with
warn_unused_result is part of a specific instantiation or part of
the template itself (presumably because those function/method
declaration does not hit the same code path as a non-template one
and so never inherits the attribute).
The new approach is to instead modify the two places where a function or
method call is checked for the warn_unused_result attribute on the decl
by extending the checks to also look for the attribute on the decl's
return type.
Additionally, the check for return types that have the warn_unused_result
now excludes pointers and references to such types, as such return types do
not necessarily imply a transfer of ownership for the underlying object
being referred to by the return value. This does not change the behavior
of functions that are directly given the warn_unused_result attribute.
llvm-svn: 234526
non-visible definition, skip the new definition and make the old one visible
instead of trying to parse it again and failing horribly. C++'s ODR allows
us to assume that the two definitions are identical.
llvm-svn: 233250
consider C++ that looks like:
inline int &f(bool b) {
if (b) {
static int i;
return i;
}
static int i;
return i;
}
Both 'i' variables must have distinct (and stable) names for linkage
purposes. The MSVC 2013 ABI would number the variables using a count of
the number of scopes that have been created. However, the final 'i'
returns to a scope that has already been created leading to a mangling
collision.
MSVC 2015 fixes this by giving the second 'i' the name it would have if
it were declared before the 'if'. However, this results in ABI breakage
because the mangled name, in cases where there was no ambiguity, would
now be different.
We implement the new behavior and only enable it if we are targeting the
MSVC 2015 ABI, otherwise the old behavior will be used.
This fixes PR18131.
llvm-svn: 232766
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
contained a typo correction (the auto decl was being marked as dependent
unnecessarily, which triggered an assertion in cases where the size of
the type is needed).
llvm-svn: 232568
Previously, we would error out on this code because the default argument
wasn't parsed until the end of Outer:
struct __declspec(dllexport) Outer {
struct __declspec(dllexport) Inner {
Inner(void *p = 0);
};
};
Now we do the checking on the closing brace of Outer instead of Inner.
llvm-svn: 232519
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
This is a bit more involved than I anticipated, so here's a breakdown
of the changes:
1. Call ActOnFinishFunctionBody _after_ we parsed =default and
=delete specifiers. Saying that we finished the body before parsing
=default is just wrong. Changing this allows us to use isDefaulted
and isDeleted on a decl in ActOnFinishFunctionBody.
2. Check for -Wmissing-prototypes after we parsed the function body.
3. Disable -Wmissing-prototypes when the Decl isDeleted.
llvm-svn: 232040
Using declarations which are aliases to struct types have their name
used as the struct type's name for linkage purposes. Otherwise, make
sure to give an anonymous struct defined inside a using declaration a
mangling number to disambiguate it from other anonymous structs in the
same context.
This fixes PR22809.
llvm-svn: 231909
of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).
No functionality change intended.
llvm-svn: 231538
`isTrackedVar` has been updated to also track records.
`DeclRefExpr`s appearing on the left side of a comma operator are
ignored, while those appearing on the right side are classified as
`Use`.
Patch by Enrico Pertoso.
llvm-svn: 231068
dynamic classes in the translation unit and check whether each one's key
function is defined when we got to the end of the TU (and when we got to the
end of each module). This is really terrible for modules performance, since it
causes unnecessary deserialization of every dynamic class in every compilation.
We now use a much simpler (and, in a modules build, vastly more efficient)
system: when we see an out-of-line definition of a virtual function, we check
whether that function was in fact its class's key function. (If so, we need to
emit the vtable.)
llvm-svn: 230830
Patch improves lookup into dependendt bases of dependent class and adds lookup
into non-dependent bases.
Differential Revision: http://reviews.llvm.org/D7173
llvm-svn: 229817
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
The motivation is to fix a crash on
struct S {} s;
Foo S::~S() { s.~S(); }
What was happening here was that S::~S() was marked as invalid since its
return type is invalid, and as a consequence CheckFunctionDeclaration() wasn't
called and S::~S() didn't get merged into S's implicit destructor. This way,
the class ended up with two destructors, which confused the overload printer
when it suddenly had to print two possible destructors for `s.~S()`.
In addition to fixing the crash, this change also seems to improve diagnostics
in a few other places, see test changes.
Crash found by SLi's bot.
llvm-svn: 229639
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
