| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
attribute on method declaration and implementation
match. This makes no sense. Most annotations are
meant for declarations only and one is for implementation.
This has been constant source of regresions and hackery to
get around special cases. I am removing this check.
Such checks must be done on a case by case basis and
when it makes sense. For example, it makes sense
for availability/deprecated and I will file a radar
for that. // rdar://15531984
llvm-svn: 195524
|
| |
|
|
| |
llvm-svn: 195503
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.
No functionality change intended.
llvm-svn: 195426
|
| |
|
|
|
|
|
|
| |
and testing of objc_bridgmutable attribute per
Aaron Ballman's comments.
// rdar://15498044
llvm-svn: 195396
|
| |
|
|
| |
llvm-svn: 195384
|
| |
|
|
|
|
|
|
| |
whose semantic is currently identical to objc_bridge,
but their differences may manifest down the road with
further enhancements. // rdar://15498044
llvm-svn: 195376
|
| |
|
|
|
|
|
|
|
|
|
| |
conformance for a class."
After implementing this patch, a few concerns about the language
feature itself emerged in my head that I had previously not considered.
I want to resolve those design concerns first before having
a half-designed language feature in the tree.
llvm-svn: 195328
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for a class.
The idea is to allow a class to stipulate that its methods (and those
of its parents) cannot be used for protocol conformance in a subclass.
A subclass is then explicitly required to re-implement those methods
of they are present in the class marked with this attribute.
Currently the attribute can only be applied to an @interface, and
not a category or class extension. This is by design. Unlike
protocol conformance, where a category can add explicit conformance
of a protocol to class, this anti-conformance really needs to be
observed uniformly by all clients of the class. That's because
the absence of the attribute implies more permissive checking of
protocol conformance.
This unfortunately required changing method lookup in ObjCInterfaceDecl
to take an optional protocol parameter. This should not slow down
method lookup in most cases, and is just used for protocol conformance.
llvm-svn: 195323
|
| |
|
|
|
|
| |
diagnostic reusable.
llvm-svn: 195322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data member definitions when the variable has an initializer
in its declaration.
For the following code:
struct S {
static const int x = 42;
};
const int S::x = 42;
This patch changes the diagnostic from:
a.cc:4:14: error: redefinition of 'x'
const int S::x = 42;
^
a.cc:2:20: note: previous definition is here
static const int x = 42;
^
to:
a.cc:4:18: error: static data member 'x' already has an initializer
const int S::x = 42;
^
a.cc:2:24: note: previous initialization is here
static const int x = 42;
^
Differential Revision: http://llvm-reviews.chandlerc.com/D2235
llvm-svn: 195306
|
| |
|
|
|
|
|
| |
expression that is not a zero literal, in C. This is a different, and more
targeted, approach than that in r194540.
llvm-svn: 195303
|
| |
|
|
|
|
| |
considerable amount of duplicated code.
llvm-svn: 195302
|
| |
|
|
|
|
|
| |
ARC and in objectiveC/ObjectiveC++ MRR mode as well.
// rdar://15454846
llvm-svn: 195288
|
| |
|
|
|
|
| |
semantic analysis. Removes some magic numbers.
llvm-svn: 195287
|
| |
|
|
|
|
| |
or from a toll free bridge cast. // rdar://15454846
llvm-svn: 195278
|
| |
|
|
|
|
| |
Switched the attribute to have the proper spelling, gave it a subject, updated the warning to be more accurate, and updated the test case as appropriate.
llvm-svn: 195277
|
| |
|
|
|
|
| |
safety annotations, and replaced it with the more general attribute diagnostic. Updated the test case in the one instance where wording changed. No functional change intended.
llvm-svn: 195275
|
| |
|
|
|
|
|
|
|
| |
- If a deprecated class refers to another deprecated class, do not warn.
- @implementations of a deprecated class can refer to other deprecated things.
Fixes <rdar://problem/15407366> and <rdar://problem/15466783>.
llvm-svn: 195259
|
| |
|
|
|
|
| |
flag the LinkageSpecDecl as being implicitly generated too.
llvm-svn: 195255
|
| |
|
|
|
|
| |
a test case to ensure the diagnostic was firing properly.
llvm-svn: 195188
|
| |
|
|
|
|
|
| |
to or from 'id' and qualified-id types.
// rdar://15454846
llvm-svn: 195178
|
| |
|
|
|
|
|
|
| |
and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolon, use that as the diagnostic
instead of producing some other mysterious error.
llvm-svn: 195163
|
| |
|
|
|
|
| |
itself.
llvm-svn: 195160
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous patches tried to deduce the correct function type. I now realize
this is not possible in general. Consider
class foo {
template <typename T> static void bar(T v);
};
extern template void foo::bar(const void *);
We will only know that bar is static after a lookup, so we have to handle this
in the template instantiation code.
This patch reverts my previous two changes (but not the tests) and instead
handles the issue in DeduceTemplateArguments.
llvm-svn: 195154
|
| |
|
|
|
|
|
| |
property is redeclared as 'weak' in class extension.
// rdar://15465916
llvm-svn: 195146
|
| |
|
|
|
|
| |
'objc_bridge' attribute. // rdar://15454846.
llvm-svn: 195135
|
| |
|
|
| |
llvm-svn: 195126
|
| |
|
|
| |
llvm-svn: 195095
|
| |
|
|
|
|
| |
// rdar://15454846
llvm-svn: 195070
|
| |
|
|
|
|
| |
per Doug/Jordan comments. // rdar://15454846.
llvm-svn: 195066
|
| |
|
|
|
|
|
| |
on struct/union/class instead of typedef of
such types. // rdar://15454846
llvm-svn: 195061
|
| |
|
|
|
|
|
|
|
|
| |
logic was not handling typedefs as free functions. This was not
causing problems with the existing tests, but does with the microsoft
abi where they have to get a different calling convention.
I will try to refactor this into a method on Declarator in a second.
llvm-svn: 195050
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch explicit template instatiations of member function templates
were failing with the microsoft abi and 32 bits. This was happening because
the expected and computed function types had different calling conventions.
This patch fixes it by considering the default calling convention in
GetFullTypeForDeclarator.
This fixes pr17973.
llvm-svn: 195032
|
| |
|
|
|
|
|
| |
CF objects with objc_bridge'ing annotaiton.
// rdar://15454846
llvm-svn: 194938
|
| |
|
|
|
|
|
| |
of ObjectiveC objects to CF types when CF type
has the objc_bridge attribute.
llvm-svn: 194930
|
| |
|
|
|
|
|
| |
it's also __attribute__((used)), since that undoes the problematic part of
'inline'.
llvm-svn: 194916
|
| |
|
|
|
|
| |
// rdar://15454846.
llvm-svn: 194915
|
| |
|
|
|
|
|
| |
projects are relying on such (questionable) practices, so we should give them
a way to opt out of this diagnostic.
llvm-svn: 194905
|
| |
|
|
|
|
|
| |
Improve on wording on illegal objc_bridge argumment.
// rdar://15454846
llvm-svn: 194881
|
| |
|
|
|
|
|
|
| |
the point of CF object type-cast and issue diagnostic
if it is not a valid ObjectiveC class. // rdar//15454846.
This is wip.
llvm-svn: 194861
|
| |
|
|
|
|
|
|
| |
ivar when property belongs to a super class and
currnt class happens to have a method with same name as
property. // rdar//15473432
llvm-svn: 194830
|
| |
|
|
|
|
|
|
|
|
|
|
| |
representing the module import rather than making the module immediately
visible. This serves two goals:
* It avoids making declarations in the module visible prematurely, if we
walk past the #include during a tentative parse, for instance, and
* It gives a diagnostic (although, admittedly, not a very nice one) if
a header with a corresponding module is included anywhere other than
at the top level.
llvm-svn: 194782
|
| |
|
|
|
|
|
| |
until after we've referenced the operator; otherwise, we might pick up a
not-yet-deduced type.
llvm-svn: 194775
|
| |
|
|
|
|
| |
variable isn't really uninitialized, it's just not initialized yet.
llvm-svn: 194767
|
| |
|
|
| |
llvm-svn: 194717
|
| |
|
|
|
|
| |
Per feedback from Jordan Rose I realized this wasn't the right way to go.
llvm-svn: 194664
|
| |
|
|
|
|
|
|
|
| |
all bridge casts.
Also refine test case to capture the intention of this suppression. Essentially
some developers use __bridge_transfer as if it were a safe CFRelease.
llvm-svn: 194663
|
| |
|
|
| |
llvm-svn: 194660
|
| |
|
|
|
|
|
|
|
|
| |
bit fields of zero size. Warnings are generated in C++ mode and if
only such type is defined inside extern "C" block.
The patch fixed PR5065.
Differential Revision: http://llvm-reviews.chandlerc.com/D2151
llvm-svn: 194653
|
| |
|
|
|
|
|
|
| |
management.
Fixes <rdar://problem/15432770>.
llvm-svn: 194647
|