This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
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
The vec_sld and vec_vsldoi interfaces perform a left-shift on vector
arguments for both big and little endian. However, because they rely
on the vec_perm interface which is endian-dependent, the permutation
vector needs to be reversed for LE to get the proper shift direction.
I've added some extra testing for these interfaces for LE in the
builtins-ppc-altivec.c.
llvm-svn: 210657
r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it
did not believe that there is a distinction between class templates and
function templates.
Sadly, there is. Function templates should behave in a compatible
manner with MSVC.
llvm-svn: 210642
Summary:
Previously, we would mangle nullptr pointer-to-member-functions in class
templates with a mangling we invented because contemporary versions of
MSVC would crash when trying to compile such code.
However, VS "14" can successfully compile these sorts of template
instantiations. This commit updates our mangling to be compatible with
theirs.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4059
llvm-svn: 210637
The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.
However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage. This
prevents them from getting inlined into call-sites.
This fixes PR19989.
llvm-svn: 210632
For ARM target, we can use CRYPTO and CRC features if we select
cortex-a57 by '-mcpu', but for AArch64 target, it doesn't work
unless adding with '-mfpu=crypto-neon-fp-armv8'. To keep consistency
between front-end and back-end and get end-users more easier to use,
we'd better add default feature for CPUs on AArch64 target as well.
llvm-svn: 210625
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
Fariborz Jahanian