We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
llvm-svn: 210550
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.
llvm-svn: 210505
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
These cases in particular were incurring an extra strlen() when we already knew
the length. They appear to be leftovers from when the interfaces worked with C
strings that have continued to compile due to the implicit StringRef ctor.
llvm-svn: 210403
MSVC delays parsing of default arguments until instantiation. If the
default argument is never used, it is never parsed. We don't model
this.
Instead, if lookup of a type name fails in a template argument context,
we form a DependentNameType, which will be looked up at instantiation
time.
This fixes errors about 'CControlWinTraits' in atlwin.h.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3995
llvm-svn: 210382
A previous patch r210330 (and possibly another) introduced DOS-style newlines
into a UNIX newline formatted file.
Patch by Mark Heffernan (http://reviews.llvm.org/D4046)
llvm-svn: 210369
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.
llvm-svn: 210350
This patch adds support for pointer types in global named registers variables.
It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls.
Also adds some early checks on types on SemaDecl to avoid the assert.
Tests changed accordingly. (PR19837)
llvm-svn: 210274
Fix post-commit review comments by Carlo Bertolli
for commit r209660 - OMP collapse clause.
Re-formatted TransformOMP* functions in TreeTransform.h with clang-format.
llvm-svn: 210169
This allows us to compile the following kind of code, which occurs in MSVC
headers:
template <typename> struct S {
__declspec(dllimport) static int x;
};
template <typename T> int S<T>::x;
The definition works similarly to a dllimport inline function definition and
gets available_externally linkage.
Differential Revision: http://reviews.llvm.org/D3998
llvm-svn: 210141
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
llvm-svn: 210137
This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.
Differential revision: http://reviews.llvm.org/D3778
llvm-svn: 210095
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
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
llvm-svn: 210083
http://llvm.org/bugs/show_bug.cgi?id=18498
This code was resulting in a crash:
auto L = [](auto ... v) { };
L.operator()<int>(3);
The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.
This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.
Thanks to Richard Smith for the review!
http://reviews.llvm.org/D2135
llvm-svn: 209992
This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.
A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.
<rdar://problem/16616623>
llvm-svn: 209966
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
These note diags have the same message and can be unified further but for now
let's just bring them together.
Incidental change: Display a source range in the final attr diagnostic.
llvm-svn: 209728
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
The previous code that was supposed to handle this didn't work
since parsing of inline method definitions is delayed to the end
of the outer class definition. Thus, when HandleTagDeclDefinition()
got called for the inner class, the inline functions in that class
had not been parsed yet.
Richard suggested that the way to do this is by handling inline
method definitions through a new ASTConsumer callback.
I really wanted to call ASTContext::DeclMustBeEmitted() instead of
checking for attributes, but doing that causes us to compute linkage,
and then we fail with "error: unsupported: typedef changes linkage
of anonymous type, but linkage was already computed" on tests like
this: (from SemaCXX/undefined-internal.cpp) :-/
namespace test7 {
typedef struct {
void bar();
void foo() { bar(); }
} A;
}
Differential Revision: http://reviews.llvm.org/D3809
llvm-svn: 209549
It's true the MSVC doesn't warn about dllimport when applied to e.g. a typedef,
but that applies to dllexport too. I'd like us to be consistent, and I think
the right thing to do is to warn.
The original test that came with implementing the old behaviour doesn't provide
a good motivation, and it said it was checking that we're not repoting an *error*,
which is still true since this is just a warning.
There are plenty of tests e.g. in Sema/dllimport.c to check that we do warn
about dllimport on non functions or variables.
Differential Revision: http://reviews.llvm.org/D3832
llvm-svn: 209546
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
llvm-svn: 209510
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
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
This is a GNU attribute that allows split stacks to be turned off on a
per-function basis.
Differential Revision: http://reviews.llvm.org/D3817
llvm-svn: 209167
This patch implements global named registers in Clang, lowering to the just
created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue
had to be created (Register), which just adds support to carry the metadata
node containing the name of the register. Two new methods to emit loads and
stores interoperate with another to emit the named metadata node.
No guarantees are being made and only non-allocatable global variable named
registers are being supported. Local named register support is unchanged.
llvm-svn: 209149
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
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
caused us to perform copy-initialization for the parameters of an allocation
function called by a new-expression multiple times, resulting in us rejecting
allocations that passed non-copyable parameters (and much worse things in
MSVC compat mode, where we potentially called this function multiple times).
llvm-svn: 208724
source that provides a declaration from a hidden module would not have the
visibility of the produced definition checked. This might matter if an
external source chose to import a new module to provide an extra definition,
but is not observable with our current external sources.
llvm-svn: 208659
The base class is the culprit/risk here - a sealed/final derived class
with virtual functions and a non-virtual dtor can't accidentally be
polymorphically destroyed (if the base class's dtor is protected - which
also suppresses this warning).
llvm-svn: 208449
This lets us diagnose and perform more complete semantic analysis when faced
with errors in the function body or declaration.
By recovering here we provide more consistent diagnostics, particularly during
interactive editing.
llvm-svn: 208394
A template declaration of a template name can be null in case we have a dependent name or a set of function templates.
Hence use dyn_cast_or_null instead of dyn_cast. Also improve the diagnostic emitted in this case.
llvm-svn: 208313
C++. This seems like a pointless (and indeed harmful) restriction to me, so
I've suggested removing it to -core and disabled this diagnostic by default.
llvm-svn: 208254
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
llvm-svn: 208150
Testcase coming out of creduce will land in a separate commit shortly.
Also, it appears that this callback is used even in a SFINAE context where the results are never displayed.
llvm-svn: 208062
Ideally, importing Foo.a from Foo.b would "do the right thing", but
until it does, this patch makes it an error rather than allow it to
silently be ignored.
llvm-svn: 207948
* Fixes a "return" that was indented at the same level as the continuation
from the previous line
* Wrap several lines to 80 columns
* Remove an if check that was always true
* Move a variable declaration slightly closer to its use
llvm-svn: 207922
class template member classes (PR19613)
Also improve this code in general by implementing suggestions
from Richard.
Differential Revision: http://reviews.llvm.org/D3555?id=9020
llvm-svn: 207822
order by the number of missing or extra parameters. This is useful if
there are more than a few overload candidates with arity mismatches,
particularly in the presence of -fshow-overloads=best.
llvm-svn: 207796
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
We accept 'void *p; p->~void();' for MSVC compatibility since r148682.
However, we were returning ExprError, rather than producing an AST,
despite only diagnosing it with a warning. CodeGen noticed that the
template function specialization had an invalid AST, and therefore
didn't generate code for it. This change makes us produce an AST with a
void pseudo-dtor call.
Part of PR18256.
llvm-svn: 207771
We were emitting dynamic initializers for __thread variables if there
was no explicit initializer, as in this test case:
struct S { S(); };
__thread S s;
llvm-svn: 207675
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
Libraries specify enabled/disabled features using macro defs of 0/1, in such cases the -Wconstant-logical-operand
is noise.
rdar://15410291
llvm-svn: 207386
Richard Smith