That's what I get for hurredly splitting the small change out of a much
bigger change that had moved where checkCorrectionVisibility was being
called.
llvm-svn: 211134
IBOutlet and weak attributes when accessed being
unpredictably set to nil because usage of such properties
are always single threaded and its ivar cannot be set
to nil asynchronously. // rdar://15885642
llvm-svn: 211132
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
We may not have the mangling for static locals vs. enums completely figured out,
but at least for my simple test cases, enums should not increment the mangling
number.
Differential Revision: http://reviews.llvm.org/D4164
llvm-svn: 211078
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
llvm-svn: 211005
CRTP-like patterns involve a class which inherits from another class
using itself as a template parameter.
However, the base class itself may try to create a pointer-to-member
which involves the derived class. This is problematic because we
may not have finished parsing the most derived classes' base specifiers
yet.
It turns out that MSVC simply uses the unspecified inheritance model
instead of doing anything fancy.
This fixes PR19987.
llvm-svn: 210886
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
llvm-svn: 210855
Previously we would do the access check from the context of
MarkVTableUsed.
Also update this test to C++11, since that is typically used with the MS
C++ ABI.
Fixes PR20005.
llvm-svn: 210850
to call themselves will get the warning:
"Capturing <itself> strongly in this block is likely to
lead to a retain cycle". Cut down on the amount of noise
by noticing that user at some point sets the captured variable
to null in order to release it (and break the cycle).
// rdar://16944538
llvm-svn: 210823
Previously we would calculate the inheritance model of a class when
requiring a pointer to member type of that class to be complete. The
inheritance model is used to figure out how many fields are used by the
member pointer.
However, once we require a pointer to member of a derived class type to
be complete, we can form pointers to members of bases without
calculating the inheritance model for those bases. This was causing
crashes on this simple test case:
struct A {
void f();
void f(int);
};
struct B : public A {};
void g() { void (B::*a)() = &B::f; }
Now we calculate the inheritance models of all base classes when
completing a member pointer type.
Fixes PR2007.
llvm-svn: 210813
Current MSVC versions don't have move assignment operators, so we
can't rely on them being available in the dll. If we have the
definition, we can just use that directly. This breaks pointer
equality, but should work fine otherwise.
When there is an MSVC version that supports move assignment,
we can key this off the -fmsc-ver option.
http://reviews.llvm.org/D4105
llvm-svn: 210715
Also move the constructor for NamespaceSpecifierSet out of line to
improve the class' readability. I meant to do these two things while
cleaning up the previous TypoCorrectionConsumer changes and have them
folded into those changes.
No functionality changed.
llvm-svn: 210686
SpecifierInfo is not used outside of NamespaceSpecifierSet except
indirectly through NamespaceSpecifierSet's iterator, so clean up the
code a bit by moving SpecifierInfo into NamespaceSpecifierSet. Also drop
SpecifierInfo's trivial yet verbose constructor since brace
initiialization is sufficient in the only two places the constructor was
being explicitly called.
No functionality changed.
llvm-svn: 210672
The SpecifierInfo and NamespaceSpecifierSet are now only used by
TypoCorrectionConsumer, so treat them as the implementation details of
TypoCorrectionConsumer that they are. Also make NamespaceSpecifierSet's
method names more style guide compliant.
No functionality changed.
llvm-svn: 210671
The only external/visible functional change that fell out of this
refactoring is that there was one less case where the typo caching
and/or counting didn't work properly. The result is that a test case
had to be moved from typo-correction.cpp to typo-correction-pt2.cpp
to avoid the hard-coded limit on per file/TU typo correction attempts.
llvm-svn: 210669
This is in preparation for moving TypoCorrection filtering
into the TypoCorrectionConsumer, to separate out some of the purely
mechanical churn. It also makes some of the method names in
NamespaceSpecifierSet be more style guide compliant.
No functionality changed.
llvm-svn: 210668
correctly when both NSAttributedString and
NSMutableAttributedString are specified on the same
CFStruct via different typedefs. // rdar://17238954
llvm-svn: 210660
We currently allow unqualified lookup for instance methods but not
static methods because we can't recover with a semantic 'this->'
insertion.
ATL headers have static methods that do unqualified lookup into
dependent base classes. The pattern looks like:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Bar; }
};
Now we recover as if the user had written:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Foo::Bar; }
};
... which will eventually look up Bar in T at instantiation time.
Now we emit a diagnostic in both cases, and delay lookup in other
contexts where 'this' is available and refers to a class with dependent
bases.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4079
llvm-svn: 210611
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
llvm-svn: 210607
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
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
llvm-svn: 207152
that looks like it might be an explicit specialization, don't recover as an
explicit specialization (bypassing the check that would reject that).
llvm-svn: 206444
Kaelyn Takata