| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
the semantic checking was already automated.
llvm-svn: 195866
|
|
|
|
|
|
| |
diagnostic for attribute subjects. In turn, this allows the Subjects to be enabled for some more attributes and improves diagnostics. Updated a test case based on the improved diagnostic.
llvm-svn: 195864
|
|
|
|
|
|
| |
test cases to be updated because the original diagnostic was about applying to methods as well as functions, but the semantic checking disallowed methods.
llvm-svn: 195862
|
|
|
|
|
|
| |
case. Previously, would issue a "warning ignored" diagnostic instead of the more specific "only applies to."
llvm-svn: 195851
|
|
|
|
| |
llvm-svn: 195850
|
|
|
|
|
|
| |
a Decl so they all go through a common interface. No functional change intended.
llvm-svn: 195848
|
|
|
|
| |
llvm-svn: 195846
|
|
|
|
|
|
|
|
|
|
|
|
| |
attribute subjects. This makes some modifications to the way subjects are listed in Attr.td, and updates the attr emitter to handle the new constructs.
I have disabled some attribute subject lines on purpose in Attr.td;
this part is a WIP with the goal being to restore those subjects
incrementally. By commenting them out, it leaves the original behavior
the same as before for those attributes and so those are not
functionality changes.
llvm-svn: 195841
|
|
|
|
|
|
|
|
| |
dependent context that the one we are instantiating, otherwise there will be an assertion.
rdar://15464547
llvm-svn: 195828
|
|
|
|
|
|
|
|
|
|
|
| |
We would fail to instantiate them when the surrounding function was
instantiated. Instantiate the class and add it's members to the list of
pending instantiations, they should be resolved when we are finished
with the function's body.
This fixes PR9685.
llvm-svn: 195827
|
|
|
|
|
|
|
| |
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
llvm-svn: 195814
|
|
|
|
|
|
|
| |
code for handling triviality, deletedness and constexpr. Fix a few bugs in
these, particularly related to mutable members, and remove some dead code.
llvm-svn: 195809
|
|
|
|
|
|
| |
Based on a patch by Ondřej Hošek!
llvm-svn: 195808
|
|
|
|
|
|
|
|
| |
look at the attribute spelling instead. The 'ownership_*' attributes should
probably be split into separate *Attr classes, but that's more than I wanted to
do here.
llvm-svn: 195805
|
|
|
|
|
|
| |
intended.
llvm-svn: 195770
|
|
|
|
|
|
| |
downstream code.
llvm-svn: 195687
|
|
|
|
|
|
|
|
| |
Attr.td. Also updated the related testcase.
Reviewed by Dmitri Gribenko.
llvm-svn: 195675
|
|
|
|
|
|
| |
whether a defaulted special member function should be deleted.
llvm-svn: 195620
|
|
|
|
| |
llvm-svn: 195589
|
|
|
|
|
|
| |
removing the now-unused diagnostic. Updates a test case.
llvm-svn: 195581
|
|
|
|
|
|
| |
as behaviorally in MSVC). This adds a generic diagnostic that we use for uuid, and can use for some other attributes as well, and adds a testcase.
llvm-svn: 195580
|
|
|
|
|
|
| |
the semantic checking consistent with what the attribute specifies in Attr.td. Also adds a test case.
llvm-svn: 195579
|
|
|
|
|
|
|
|
| |
diagnostic.
Reviewed by Fariborz Jahanian
llvm-svn: 195578
|
|
|
|
|
|
| |
This refines some diagnostics and reduces some boilerplate checking logic.
llvm-svn: 195560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
renamed).
This is still an experimental attribute, but I wanted it in tree
for review. It may still get yanked.
This attribute can only be applied to a class @interface, not
a class extension or category. It does not change the type
system rules for Objective-C, but rather the implementation checking
for Objective-C classes that explicitly conform to a protocol.
During protocol conformance checking, clang recursively searches
up the class hierarchy for the set of methods that compose
a protocol. This attribute will cause the compiler to not consider
the methods contributed by a super class, its categories, and those
from its ancestor classes. Thus this attribute is used to force
subclasses to redeclare (and hopefully re-implement) methods if
they decide to explicitly conform to a protocol where some of those
methods may be provided by a super class.
This attribute intentionally leaves out properties, which are associated
with state. This attribute only considers methods (at least right now)
that are non-property accessors. These represent methods that "do something"
as dictated by the protocol. This may be further refined, and this
should be considered a WIP until documentation gets written or this
gets removed.
llvm-svn: 195533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument.
This enables a micro-optimization in protocol conformance checking
to not examine the class hierarchy twice per method.
As part of this change, remove the default arguments from lookupInstanceMethod()
and lookupClassMethod(). It was becoming very redundant. For clients
needing the default arguments, have them use the full API instead of
these convenience methods.
llvm-svn: 195532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|