| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 207681
|
|
|
|
|
|
| |
base classes.
llvm-svn: 207680
|
|
|
|
|
|
| |
non-member declaration. Patch by Dinesh Dwivedi!
llvm-svn: 207677
|
|
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
|
|
|
|
|
|
|
| |
statements, don't diagnose; the return type might end up being 'void'.
Patch by Rahul Jain! Tiny tweaks by me.
llvm-svn: 206929
|
|
|
|
|
|
| |
imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.
llvm-svn: 206680
|
|
|
|
|
|
| |
template-id after its scope specifier into a single place.
llvm-svn: 206442
|
|
|
|
|
|
| |
if the member is already 'const'. Don't assert in that case.
llvm-svn: 206205
|
|
|
|
|
|
|
|
|
|
|
| |
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
|
|
|
|
|
|
| |
to suggest a different syntax to get the same effect.
llvm-svn: 205467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
|
|
|
|
|
|
|
|
| |
This commit also adds an additional test case for the global destructor warning.
Reviewed in http://llvm-reviews.chandlerc.com/D3205
llvm-svn: 204954
|
|
|
|
|
|
| |
Fixes PR19253.
llvm-svn: 204825
|
|
|
|
|
|
| |
resolved, emit an update record.
llvm-svn: 204403
|
|
|
|
|
|
|
|
| |
unlock_function attributes with the acquire_capability and release_capability attributes. The old spellings will continue to work, but the underlying semantic attributes have been replaced.
Downgraded the capability diagnostics from error to warning to match the desired behavior, and updated the existing test cases.
llvm-svn: 204350
|
|
|
|
|
|
| |
exception_end() with iterator_range exceptions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204046
|
|
|
|
|
|
| |
iterator_range body(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204040
|
|
|
|
|
|
| |
iterator_range decls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203947
|
|
|
|
|
|
| |
iterator_range inits(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203819
|
|
|
|
|
|
| |
iterator_range ctors(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203814
|
|
|
|
|
|
| |
with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203812
|
|
|
|
|
|
| |
with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203808
|
|
|
|
|
|
| |
iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203803
|
|
|
|
|
|
|
| |
that implicitly converts to 'bool' (such as pointers, and the first operand of
?:). Clean up issues found by this. Patch by Stephan Tolksdorf!
llvm-svn: 203735
|
|
|
|
|
|
|
|
| |
iterator_range attrs(). Updating all of the usages of the iterators with range-based for loops.
This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage.
llvm-svn: 203362
|
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
| |
iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203278
|
|
|
|
|
|
| |
Smith.
llvm-svn: 203262
|
|
|
|
|
|
| |
with iterator_range chains(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203261
|
|
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203248
|
|
|
|
|
|
| |
MSVC bots.
llvm-svn: 203237
|
|
|
|
|
|
| |
attrs(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203236
|
|
|
|
|
|
| |
iterator_range redecls(). Updating all of the usages of the iterators with range-based for loops, which allows the begin/end forms to be removed entirely.
llvm-svn: 203179
|
|
|
|
| |
llvm-svn: 202625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
or virtual functions, but permit that error to be downgraded to
a warning (with -Wno-error=incompatible-ms-struct), and officially
support this kind of dual, ABI-mixing layout.
The basic problem here is that projects which use ms_struct are often
not very circumspect about what types they annotate; for example,
some projects enable the pragma in a prefix header and then only
selectively disable it around system header inclusions. They may
only care about binary compatibility with MSVC for a subset of
those structs, but that doesn't mean they have no binary
compatibility concerns at all for the rest; thus we are essentially
forced into supporting this hybrid ABI. But it's reasonable for
us to at least point out the places where we're not making
any guarantees.
The original diagnostic was for dynamic classes, i.e. those with
virtual functions or virtual bases; I've extended it to include
all classes with bases, because we are not actually making any
attempt to duplicate MSVC's base subobject layout in ms_struct
(and it is indeed quite different from Itanium, even for
non-virtual bases).
rdar://16178895
llvm-svn: 202427
|
|
|
|
|
|
| |
This is a continuation of r199686.
llvm-svn: 202307
|
|
|
|
|
|
|
|
|
|
| |
We were previously checking at every destructor declaration, but that was a bit
excessive. Since the deleting destructor is emitted with the vtable, do the
check when the vtable is marked used.
Differential Revision: http://llvm-reviews.chandlerc.com/D2851
llvm-svn: 202046
|
|
|
|
|
|
|
|
| |
management: asserting a capability is held, acquiring a capability and releasing a capability. Also includes some skeleton documentation for these new attributes.
This functionality should be considered a WIP.
llvm-svn: 201890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality) and I have agreed to start migrating from lock-specific terminology to "capability"-specific terminology. This opens the door for future threading-related analysis passes so that a common nomenclature can be used.
The following attributes have been (silently) deprecated, with their replacements listed:
lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability
There are no functional changes intended.
llvm-svn: 201585
|
|
|
|
|
|
| |
spelled in an interesting way.
llvm-svn: 201536
|
|
|
|
|
|
|
|
| |
using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
|
|
|
|
|
|
|
|
| |
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
|
|
|
|
|
|
|
| |
operator--, since it might instantiate as 'int' (or, if it's a pack, it
might instantiate as an empty pack).
llvm-svn: 200496
|
|
|
|
|
|
|
|
| |
Follow up to r200082.
Spotted by Dmitri
llvm-svn: 200105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
|
|
|
| |
the defaulting because it would delete the member, produce additional notes
explaining why the member is implicitly deleted.
llvm-svn: 199829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.
Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.
Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.
llvm-svn: 199794
|
|
|
|
|
|
|
|
| |
the program, in C++. (We allow the latter as an extension, since we've always
permitted it, and GCC does the same, and our supported C++ ABIs don't do
anything special in main.)
llvm-svn: 199782
|
|
|
|
| |
llvm-svn: 199699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
|