| Age | Commit message (Collapse) | Author |
|---|
|
of a single if block. This is really annoying to track down and test.
Silly changes to the test case caused it to stop showing up. I wish
there were a more concrete way of asserting that a note attaches to the
intended diagnostic.
This fixes PR10195.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assert that any names we find are valid candidates for the call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133898 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'ownership', not 'lifetime'.
rdar://9477613.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as well. rdar://9660196
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.
One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.
However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
this. My suggestion assumed a viable erase method for iterators on
SmallPtrSet.
This patch restores his original pattern.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132673 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compilers incorrectly accept due to a lack of proper support for two-phase name lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compared even when one is a reference binding and the other is not
(<rdar://problem/9173984>), but the definition of an identity sequence
does not involve lvalue-to-rvalue adjustments (PR9507). Fix both
inter-related issues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132096 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
minor issues along the way:
- Non-type template parameters of type 'std::nullptr_t' were not
permitted.
- We didn't properly introduce built-in operators for nullptr ==,
!=, <, <=, >=, or > as candidate functions .
To my knowledge, there's only one (minor but annoying) part of nullptr
that hasn't been implemented: catching a thrown 'nullptr' as a pointer
or pointer-to-member, per C++0x [except.handle]p4.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131813 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Necessary to parse MFC code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.
Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.
Fixes <rdar://problem/9402499>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class constructor/destructor. Fixes PR7966.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the overloading of member and non-member functions results in arity
mismatches that don't fit well into our overload-printing scheme. This
only happens for invalid code (which breaks the arity invariants for
these cases), so just suppress the diagnostic rather than inventing
anything new. Fixes <rdar://problem/9222009>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Decl actually found via name lookup & overload resolution when that Decl
is different from the ValueDecl which is actually referenced by the
expression.
This can be used by AST consumers to correctly attribute references to
the spelling location of a using declaration, and otherwise gain insight
into the name resolution performed by Clang.
The public interface to DRE is kept as narrow as possible: we provide
a getFoundDecl() which always returns a NamedDecl, either the ValueDecl
referenced or the new, more precise NamedDecl if present. This way AST
clients can code against getFoundDecl without know when exactly the AST
has a split representation.
For an example of the data this provides consider:
% cat x.cc
namespace N1 {
struct S {};
void f(const S&);
}
void test(N1::S s) {
f(s);
using N1::f;
f(s);
}
% ./bin/clang -fsyntax-only -Xclang -ast-dump x.cc
[...]
void test(N1::S s) (CompoundStmt 0x5b02010 <x.cc:5:20, line:9:1>
(CallExpr 0x5b01df0 <line:6:3, col:6> 'void'
(ImplicitCastExpr 0x5b01dd8 <col:3> 'void (*)(const struct N1::S &)' <FunctionToPointerDecay>
(DeclRefExpr 0x5b01d80 <col:3> 'void (const struct N1::S &)' lvalue Function 0x5b01a20 'f' 'void (const struct N1::S &)'))
(ImplicitCastExpr 0x5b01e20 <col:5> 'const struct N1::S' lvalue <NoOp>
(DeclRefExpr 0x5b01d58 <col:5> 'N1::S':'struct N1::S' lvalue ParmVar 0x5b01b60 's' 'N1::S':'struct N1::S')))
(DeclStmt 0x5b01ee0 <line:7:3, col:14>
0x5b01e40 "UsingN1::;")
(CallExpr 0x5b01fc8 <line:8:3, col:6> 'void'
(ImplicitCastExpr 0x5b01fb0 <col:3> 'void (*)(const struct N1::S &)' <FunctionToPointerDecay>
(DeclRefExpr 0x5b01f80 <col:3> 'void (const struct N1::S &)' lvalue Function 0x5b01a20 'f' 'void (const struct N1::S &)' (UsingShadow 0x5b01ea0 'f')))
(ImplicitCastExpr 0x5b01ff8 <col:5> 'const struct N1::S' lvalue <NoOp>
(DeclRefExpr 0x5b01f58 <col:5> 'N1::S':'struct N1::S' lvalue ParmVar 0x5b01b60 's' 'N1::S':'struct N1::S'))))
Now we can tell that the second call is 'using' (no pun intended) the using
declaration, and *which* using declaration it sees. Without this, we can
mistake calls that go through using declarations for ADL calls, and have no way
to attribute names looked up with using declarations to the appropriate
UsingDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130670 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-CVR qualifiers as well as CVR qualifiers. For example, don't allow
a reference to an integer in address space 1 to bind to an integer in
address space 2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130411 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instance methods to have bound-member type.
Fixing that broke __unknown_anytype, which I've in turn fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
determine which is a better conversion to "void*", be sure to perform
the comparison using the safe-for-id
ASTContext::canAssignObjCInterfaces() rather than the asserts-with-id
ASTContext::canAssignObjCInterfaces().
Fixes <rdar://problem/9327203>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the qualifiers (e.g., GC qualifiers) on the type we're converting
from, rather than just blindly adopting the qualifiers of the type
we're converting to or dropping qualifiers altogether.
As an added bonus, properly diagnose GC qualifier mismatches to
eliminate a crash in the overload resolution failure diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bound
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130239 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when checking a qualification conversion
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130136 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
true.
Fixes an assertion later on, rdar://9122862 & http://llvm.org/PR9460.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Objective-C pointer to void* as a "conversion to void*". This allows
us to prefer an Objective-C object pointer conversion to a superclass
object pointer over an Objective-C object pointer conversion to
cv-void*. Fixes PR9735.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129603 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
draft standard (N3291).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129541 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://9208404
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129536 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warnings, and make its text appropriate for constant bool expressions
other than 'false'. This should finish off PR9612.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129205 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type rather than just the literal 'false'. This begins fixing PR9612,
but the message is now wrong. WIP, the cleanup of the messaging is next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129204 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129143 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I'm pretty sure this is the right fix, but I would appreciate it if someone
else would double-check.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assert-less codepath marginally more efficient.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128472 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.
The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.
Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128456 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function parameter. // rdar:// 9129552
and PR9406.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128127 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
should be resolvable, from Faisal Vali!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127521 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.
This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126920 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
possible for these to show up due to metaprogramming both in unevaluated
contexts and compile-time dead branches.
Those aren't the bugs we're looking for.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MemberExpr, the last of the expressions with qualifiers!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
where ever such attribute causes an error diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
marking selected overloads into the callers. This allows a few callers
to skip it altogether (they would have anyways because they weren't
interested in successful overloads) or defer until after further checks
take place much like the check required for PR9323 to avoid marking
unused copy constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://9046492
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declarations as referenced when in fact we're not going to even form
a call in the AST. This is significant because we attempt to allow as an
extension classes with intentionally private and undefined copy
constructors to have temporaries bound to references, and so shouldn't
warn about the lack of definition for that copy constructor when the
class is internal.
Doug, John wasn't really satisfied with the presence of overloading at
all. This is a stop-gap and there may be a better solution. If you can
give me some hints for how you'd prefer to see this solved, I'll happily
switch things over.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126480 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126391 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested-name-specifier and source range to be set at the same time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
includes explicitly-specified template arguments) to a function
template specialization in cases where no deduction is performed or
deduction fails. Patch by Faisal Vali, fixes PR7505!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125468 91177308-0d34-0410-b5e6-96231b3b80d8
|
