| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
modifiers. (From an idea by Eric...)
<rdar://problem/12284092>
llvm-svn: 166647
|
|
|
|
|
|
| |
rebuilds a function type, and that function type has parens around its name.
llvm-svn: 166644
|
|
|
|
| |
llvm-svn: 166625
|
|
|
|
| |
llvm-svn: 166520
|
|
|
|
|
|
|
| |
method type in cateogry matches the implementation.
// rdar://12519216
llvm-svn: 166518
|
|
|
|
|
|
|
|
|
| |
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Patch by Ed Schouten.
llvm-svn: 166498
|
|
|
|
|
|
| |
even if it's dependent, in case it now names a member of the current instantiation.
llvm-svn: 166496
|
|
|
|
| |
llvm-svn: 166489
|
|
|
|
| |
llvm-svn: 166463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libraries have an incorrect definition of std::common_type (inherited from a
bug in the standard -- see LWG issue 2141), whereby they produce reference
types when they should not.
If we instantiate a typedef named std::common_type<...>::type, which is defined
in a system header as decltype(... ? ... : ...), and the decltype produces a
reference type, convert it to the non-reference type. (This doesn't affect any
LWG2141-conforming implementation of common_type, such as libc++'s, because the
default implementation of common_type<...>::type isn't supposed to produce a
reference type.)
This is horrible. I'm really sorry. :( Better ideas appreciated!
llvm-svn: 166455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.
While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).
Original message:
PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.
llvm-svn: 166385
|
|
|
|
| |
llvm-svn: 166377
|
|
|
|
|
|
|
|
|
|
|
|
| |
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
|
|
|
|
| |
llvm-svn: 166369
|
|
|
|
|
|
|
|
|
| |
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
llvm-svn: 166361
|
|
|
|
| |
llvm-svn: 166310
|
|
|
|
|
|
| |
Suggestion from Matt Beaumont-Gay reviewing r165283.
llvm-svn: 166296
|
|
|
|
| |
llvm-svn: 166293
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.
There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.
llvm-svn: 166285
|
|
|
|
|
|
| |
Richard has an unreduced testcase to work with.
llvm-svn: 166272
|
|
|
|
|
|
| |
class, diagnose if the qualified-id instantiates to a non-static class member.
llvm-svn: 166268
|
|
|
|
| |
llvm-svn: 166254
|
|
|
|
|
|
| |
which will be used by the asm matcher in the near future.
llvm-svn: 166221
|
|
|
|
|
|
|
|
|
|
|
| |
source locations in places where it is necessary for diagnostics. By itself,
this causes assertions, so while I'm here, also fix property synthesis
for properties of C++ class type so we use so we properly set up a scope
and mark variable declarations.
<rdar://problem/12514189>.
llvm-svn: 166219
|
|
|
|
|
|
|
| |
*NamedDecl. In turn, build the expressions after we're finished parsing the
asm. This avoids a crasher if the lookup fails.
llvm-svn: 166213
|
|
|
|
|
|
| |
This would make it possible for the analyzer to use the function.
llvm-svn: 166210
|
|
|
|
| |
llvm-svn: 166208
|
|
|
|
|
|
| |
namespace.
llvm-svn: 166194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Within the body of the loop the underlying map may be modified via
Sema::AddOverloadCandidate
-> Sema::CompareReferenceRelationship
-> Sema::RequireCompleteType
to avoid the use of invalid iterators the sequence is copied first.
A reliable, though large, test case is available - it will be reduced and
committed shortly.
Patch by Robert Muth. Review by myself, Nico Weber, and Rafael Espindola.
llvm-svn: 166188
|
|
|
|
|
|
|
| |
layer. Use the new ParseMSInlineAsm() API and add an implementation of the
MCAsmParserSemaCallback interface.
llvm-svn: 166184
|
|
|
|
| |
llvm-svn: 166162
|
|
|
|
| |
llvm-svn: 166158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration of a virtual function.
GCC and Clang both do not warn on:
struct a { virtual void func(); };
struct b: a { virtual void func(); void func(int); };
struct c: b { void func(int); using b::func; };
but if the "using" was using a::func GCC would still remain silent where Clang
would warn. This change makes Clang consistent with GCC's existing behavior.
llvm-svn: 166154
|
|
|
|
| |
llvm-svn: 166152
|
|
|
|
|
|
|
| |
Only deleted functions may override deleted functions and non-deleted functions
may only override non-deleted functions.
llvm-svn: 166082
|
|
|
|
|
|
| |
explicitly specified iff it was specified in the declaration.
llvm-svn: 166071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
|
|
|
|
|
|
| |
front-end and the AsmParser. No functional change intended.
llvm-svn: 166063
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)
llvm-svn: 166039
|
|
|
|
|
|
| |
// rdar://12491143
llvm-svn: 166030
|
|
|
|
|
|
|
| |
hopelessly poorly written code after spewing several
errors. // rdar://12491143
llvm-svn: 166025
|
|
|
|
| |
llvm-svn: 165988
|
|
|
|
| |
llvm-svn: 165977
|
|
|
|
| |
llvm-svn: 165976
|
|
|
|
|
|
| |
See PR14013.
llvm-svn: 165962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-The front-end now builds a single assembly string and feeds it to the
AsmParser. The front-end iterates on a per statement basis by calling the
ParseStatement() function. Please note, the calling of ParseStatement() and
and any notion of MCAsmParsedOperands will be sunk into the MC layer in the
near future. I plan to expose more basic APIs such as getClobbers, etc.
-The enumeration of the AsmString expressions have been reworked to use SMLocs
rather than assembly Pieces, which were being parsed in the front-end.
-The test case, t8(), was modified due to r129223. I'll have to find a way to
work around things such as these.
Sorry for the large commit, but breaking this in multiple smaller commits proved
too irritating.
llvm-svn: 165957
|
|
|
|
| |
llvm-svn: 165859
|
|
|
|
| |
llvm-svn: 165851
|
|
|
|
|
|
| |
Patch by Jeremiah Zanin.
llvm-svn: 165849
|
|
|
|
| |
llvm-svn: 165834
|