| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 165829
|
| |
|
|
|
|
| |
declarations.
llvm-svn: 165826
|
| |
|
|
|
|
| |
reimplemented in the AsmParser where it belongs.
llvm-svn: 165825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 165811
|
| |
|
|
| |
llvm-svn: 165793
|
| |
|
|
| |
llvm-svn: 165772
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only applies if the type has a name. (we could potentially do something
crazy with decltype in C++11 to qualify members of unnamed types but that
seems excessive)
It might be nice to also suggest a fixit for "&this->i", "&foo->i",
and "&foo.i" but those expressions produce 'bound' member functions that have
a different AST representation & make error recovery a little trickier. Left
as future work.
llvm-svn: 165763
|
| |
|
|
|
|
| |
reimplemented in the AsmParser where it belongs.
llvm-svn: 165752
|
| |
|
|
|
|
|
|
|
| |
now unused static helper function.
The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.
llvm-svn: 165751
|
| |
|
|
| |
llvm-svn: 165733
|
| |
|
|
|
|
| |
Fix-up for r165718, should get the buildbots back online.
llvm-svn: 165723
|
| |
|
|
|
|
|
|
|
|
| |
This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.
<rdar://problem/12437490>
llvm-svn: 165719
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.
This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.
<rdar://problem/12407765>
llvm-svn: 165718
|
| |
|
|
| |
llvm-svn: 165710
|
| |
|
|
| |
llvm-svn: 165679
|
| |
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|
| |
|
|
|
|
|
| |
Reading from a weak property, casting the result, and assigning to a
strong pointer should still be considered safe.
llvm-svn: 165629
|
| |
|
|
|
|
|
|
| |
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old algorithm:
1. See if the name looks like a getter or setter.
2. Use the name to look up a property in the current ObjCContainer
and all its protocols.
3. If the current container is an interface, also look in all categories
and superclasses (and superclass categories, and so on).
New algorithm:
1. See if the method is marked as a property accessor. If so, look through
all properties in the current container and find one that has a matching
selector.
2. Find all overrides of the method using ObjCMethodDecl's
getOverriddenMethods. This collects methods in superclasses and protocols
(as well as superclass categories, which isn't really necessary), and
checks if THEY are accessors. This part is not done recursively, since
getOverriddenMethods is already recursive.
This lets us handle getters and setters that do not match the property
names.
llvm-svn: 165627
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|
| |
|
|
|
|
|
|
| |
constructor with invalid code.
rdar://12240916
llvm-svn: 165623
|
| |
|
|
|
|
|
|
|
|
|
|
| |
write out the macro history for that macro. Similarly, we need to cope
with reading a macro definition that has been #undef'd.
Take advantage of this new ability so that global code-completion
results can refer to #undef'd macros, rather than losing them
entirely. For multiply defined/#undef'd macros, we will still get the
wrong result, but it's better than getting no result.
llvm-svn: 165502
|
| |
|
|
|
|
| |
OverloadCandidateSet::clear and don't do it on destruction.
llvm-svn: 165501
|
| |
|
|
|
|
| |
canonical method; avoid storing them again for an out-of-line definition.
llvm-svn: 165472
|
| |
|
|
| |
llvm-svn: 165384
|
| |
|
|
| |
llvm-svn: 165383
|
| |
|
|
|
|
| |
what's going on, per Sean Silva's suggestion.
llvm-svn: 165286
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.
(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)
llvm-svn: 165283
|
| |
|
|
|
|
| |
import declaration.
llvm-svn: 165277
|
| |
|
|
|
|
|
|
| |
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
|
| |
|
|
| |
llvm-svn: 165259
|
| |
|
|
| |
llvm-svn: 165258
|
| |
|
|
| |
llvm-svn: 165256
|