Summary:
- Fixed an assert in Sema::InstantiateFunctionDefinition and added
support for instantiating a function template with skipped body.
- Properly call setHasSkippedBody for FunctionTemplateDecl passed to
Sema::ActOnSkippedFunctionBody.
Reviewers: sepavloff, bkramer
Reviewed By: sepavloff
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41237
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321174 91177308-0d34-0410-b5e6-96231b3b80d8
The two asserts are too aggressive. In C++ mode, an
enum is NOT considered an integral type, but an enum value
is allowed to be an enum. This patch relaxes the two asserts
to allow the enum value as well (as typechecking does).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320411 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is so we can implement concepts per P0734R0. Relevant failing test
cases are disabled.
Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson
Reviewed By: saar.raz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40380
Patch by Changyu Li!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319992 91177308-0d34-0410-b5e6-96231b3b80d8
cbrt() is always constant because it can't overflow or underflow. Therefore, it can't set errno.
fma() is not always constant because it can overflow or underflow. Therefore, it can set errno.
But we know that it never sets errno on GNU / MSVC, so make it constant in those environments.
Differential Revision: https://reviews.llvm.org/D39641
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318093 91177308-0d34-0410-b5e6-96231b3b80d8
Allow Obj-C ivars with incomplete array type but only as the last ivar.
Also add a requirement for ivars that contain a flexible array member to
be at the end of class too. It is possible to add in a subclass another
ivar at the end but we'll emit a warning in this case. Also we'll emit a
warning if a variable sized ivar is declared in class extension or in
implementation because subclasses won't know they should avoid adding
new ivars.
In ARC incomplete array objects are treated as __unsafe_unretained so
require them to be marked as such.
Prohibit synthesizing ivars with flexible array members because order of
synthesized ivars is not obvious and tricky to control. Spelling out
ivar explicitly gives control to developers and helps to avoid surprises
with unexpected ivar ordering.
For C and C++ changed diagnostic to tell explicitly a field is not the
last one and point to the next field. It is not as useful as in Obj-C
but it is an improvement and it is consistent with Obj-C. For C for
unions emit more specific err_flexible_array_union instead of generic
err_field_incomplete.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38773
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316381 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315871 91177308-0d34-0410-b5e6-96231b3b80d8
If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.
Differential Revision: https://reviews.llvm.org/D38678
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315787 91177308-0d34-0410-b5e6-96231b3b80d8
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315668 91177308-0d34-0410-b5e6-96231b3b80d8
overriding methods.
This should fix test case Analysis/retain-release.m that was failing on
the reverse iteration bot:
http://lab.llvm.org:8011/builders/reverse-iteration
The test used to fail because the loop in CheckObjCMethodOverrides would
merge attribute ns_returns_retained on methods while checking whether
the overriding methods were compatible. Since OverrideSearch::Overridden
is a SmallPtrSet and the order in which the elements of the set are
visited is non-deterministic, the test would fail when method 'clone' of
the protocol 'F18P' was visited before F18(Cat)'s method 'clone' was
visited.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315639 91177308-0d34-0410-b5e6-96231b3b80d8
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315379 91177308-0d34-0410-b5e6-96231b3b80d8
This is a re-commit of r315025, but making sure to only apply this to
specializations of class template member functions; i.e. not when the function
itself is a template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315330 91177308-0d34-0410-b5e6-96231b3b80d8
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315251 91177308-0d34-0410-b5e6-96231b3b80d8
As reported on cfe-commits, r314262 resulted in tentatively-defined
variables not being excluded for the warning.
Patch By: Elizabeth Andrews
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314939 91177308-0d34-0410-b5e6-96231b3b80d8
We were injecting the function into the wrong semantic context, resulting in it
failing to be registered as a global for redeclaration lookup. As a
consequence, we accepted invalid code since r310616.
Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot
more often. It turned out that warning codepath was non-conforming, because it
did not cause us to inject the implicitly-declared function into the enclosing
block scope. We now only warn if the type of the out-of-scope declaration
doesn't match the type of an implicitly-declared function; in all other cases,
we produce the normal warning for an implicitly-declared function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314871 91177308-0d34-0410-b5e6-96231b3b80d8
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute.
The main goal is to add further flexibility to the attribute and allow
for it to be used easily with templates.
The main additions are a new type (DependentAddressSpaceType) alongside
its TypeLoc and its mangling. As well as the logic required to support
dependent address spaces which mainly resides in TreeTransform.h and
SemaType.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314649 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
middle-end.
This change emits the section information for all targets.
Patch By: Elizabeth Andrews
Differential Revision:https://reviews.llvm.org/D36487
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314262 91177308-0d34-0410-b5e6-96231b3b80d8
I've been unable to find any cases whose behavior is actually changed by this,
but only because an implicitly deleted destructor also results in it being
impossible to have a trivial (non-deleted) copy constructor, which the place
where this really matters (choosing whether to pass a class in registers)
happens to also check.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313948 91177308-0d34-0410-b5e6-96231b3b80d8
Fix for too aggressive error err_type_defined_in_enum introduced in
r313386. Defining tags inside enumerations is prohibited in C++ but
allowed in C.
Reviewers: aaron.ballman, rnk, doug.gregor
Reviewed By: rnk
Subscribers: alberto_magni, cfe-commits
Differential Revision: https://reviews.llvm.org/D38109
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313894 91177308-0d34-0410-b5e6-96231b3b80d8
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313729 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR28903 by avoiding access check for inner enum constant. We
are performing access check because one enum constant references another
and because enum is defined in CXXRecordDecl. But access check doesn't
work because FindDeclaringClass doesn't expect more than one EnumDecl
and because inner enum has access AS_none due to not being an immediate
child of a record.
The change detects an enum is defined in wrong place and allows to skip
parsing its body. Access check is skipped together with body parsing.
There was no crash in C, added test case to cover the new error.
rdar://problem/28530809
Reviewers: rnk, doug.gregor, rsmith
Reviewed By: doug.gregor
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37089
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313386 91177308-0d34-0410-b5e6-96231b3b80d8
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312794 91177308-0d34-0410-b5e6-96231b3b80d8
The clang-with-lto-ubuntu bot didn't like the new regression
test, revert while I investigate the issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312784 91177308-0d34-0410-b5e6-96231b3b80d8
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312781 91177308-0d34-0410-b5e6-96231b3b80d8
This follows the scheme agreed with Nathan Sidwell, which can be found here:
https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile
This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312467 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r310706. This change has been recommended by
Bruno Cardoso Lopes and Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310829 91177308-0d34-0410-b5e6-96231b3b80d8
the class becoming complete and its inline methods being parsed.
This replaces the hack of using the "late parsed template" flag to track member
functions with bodies we've not parsed yet; instead we now use the "will have
body" flag, which carries the desired implication that the function declaration
*is* a definition, and that we've just not parsed its body yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310776 91177308-0d34-0410-b5e6-96231b3b80d8
declarations that are made visible after the dummy is parsed and ODR verified
Prior to this commit the
"(getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."),"
assertion failure was triggered during semantic analysis of the dummy
tag declaration that was declared in another tag declaration because its
lexical context did not point to the outer tag decl.
rdar://32292196
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310706 91177308-0d34-0410-b5e6-96231b3b80d8
Ilya Biryukov