| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
!. Fixes PR9865.
llvm-svn: 141537
|
|
|
|
| |
llvm-svn: 141171
|
|
|
|
|
|
|
|
|
| |
conversion function whose result type is an lvalue reference. The
initialization code already handled this properly, but overload
resolution was allowing the binding. Fixes PR11003 /
<rdar://problem/10233078>.
llvm-svn: 141137
|
|
|
|
| |
llvm-svn: 140978
|
|
|
|
|
|
|
|
| |
some arguments types are ns_consumed and some otherwise
matching types are not. This is objc side of
// rdar://10187884
llvm-svn: 140729
|
|
|
|
|
|
|
|
| |
some arguments types are ns_consumed and some otherwise
matching types are not. This fixes the objc++ side only *auch*.
// rdar://10187884
llvm-svn: 140717
|
|
|
|
|
|
| |
macro whose only replacement token is '_Bool'.
llvm-svn: 140656
|
|
|
|
|
|
|
| |
'bool' rather than '_Bool' within types, to make things a bit more
readable. Fixes <rdar://problem/10063263>.
llvm-svn: 140650
|
|
|
|
| |
llvm-svn: 140478
|
|
|
|
|
|
|
|
|
| |
cannot be converted.
This is in preparation for overload resolution of initializer lists.
Currently, you will always get this message when you try to pass an init
list to an overloaded function.
llvm-svn: 140461
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostics nor
builds a semantic (structured) initializer list, just reports on whether it can match
the given list to the target type.
Use this mode for doing init list checking in the initial step of initialization, which
will eventually allow us to do overload resolution based on the outcome.
llvm-svn: 140457
|
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
| |
conversions (rather than just call-arguments).
llvm-svn: 140244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
floating-to-integral conversion if the integral conversion is between types of the same size.
For example:
void f(float);
void f(int);
int main {
long a;
f(a);
}
Here, MSVC will call f(int) instead of generating a compile error as clang will do in standard mode.
This fixes a few errors when parsing MFC code with clang.
llvm-svn: 140007
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
| |
assert.
llvm-svn: 139474
|
|
|
|
|
|
| |
enumeration type.
llvm-svn: 139445
|
|
|
|
| |
llvm-svn: 139417
|
|
|
|
|
|
|
|
|
|
|
|
| |
converting to an arbitrary Objective-C pointer type is. Without
significantly re-implementing anything, change the API to reflect this,
and as a minor optimization, strip the pointer conversion off before
potentially building it.
Mostly, this removes a really bizarre-looking bit of code from
BuildInstanceMessage.
llvm-svn: 139354
|
|
|
|
|
|
|
|
| |
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
llvm-svn: 139352
|
|
|
|
|
|
|
|
| |
can't resolve a function call then create a type-dependent CallExpr even if the function has no type dependent arguments. The goal is to postpone name lookup to instantiation time to be able to search into type dependent base classes.
With this patch in, clang will generate only 37 errors (down from 212) when parsing a typical MFC source file.
llvm-svn: 139210
|
|
|
|
|
|
|
| |
Doing this happens to disrupt the pattern that ARC was looking for
for move optimizations, so we need to fix that simultaneously.
llvm-svn: 138789
|
|
|
|
|
|
| |
deleted operators. Fixes PR10757.
llvm-svn: 138645
|
|
|
|
|
|
|
| |
conversion to initialize the standard conversion *after* the
user-defined conversion properly. Fixes PR10644.
llvm-svn: 137608
|
|
|
|
|
|
| |
functions when performing function overload resolution.
llvm-svn: 136948
|
|
|
|
|
|
|
|
| |
Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.
llvm-svn: 136807
|
|
|
|
|
|
| |
simple conversion checking function.
llvm-svn: 136376
|
|
|
|
|
|
|
|
|
|
| |
considering explicit conversion operators when determining surrogate
functions. Fixes PR10453. Note that there are a few test cases where
Clang is still wrong because it does not implement DR899; see PR10456.
Patch by Jonathan Sauer!
llvm-svn: 135857
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
| |
IsIntegralPromotion should consider the signedness of FromType when
calculating promotions. This, as of now, cannot be exercised on any
platform so there is no corresponding test.
llvm-svn: 135803
|
|
|
|
|
|
| |
C++ function call is missing * or & operators on
llvm-svn: 135643
|
|
|
|
|
|
|
| |
fails because of lifetime differences of parameter and argument type.
// rdar://9790531
llvm-svn: 135593
|
|
|
|
|
|
| |
one/several of it's parameters (addresses http://llvm.org/PR5941).
llvm-svn: 135509
|
|
|
|
| |
llvm-svn: 135275
|
|
|
|
|
|
| |
require A to be a complete type.
llvm-svn: 135101
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 133907
|
|
|
|
|
|
| |
assert that any names we find are valid candidates for the call.
llvm-svn: 133898
|
|
|
|
|
|
|
|
| |
'ownership', not 'lifetime'.
rdar://9477613.
llvm-svn: 133779
|
|
|
|
|
|
| |
as well. rdar://9660196
llvm-svn: 133672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 133327
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 133103
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 132744
|
|
|
|
|
|
|
|
|
| |
this. My suggestion assumed a viable erase method for iterators on
SmallPtrSet.
This patch restores his original pattern.
llvm-svn: 132673
|
|
|
|
|
|
| |
compilers incorrectly accept due to a lack of proper support for two-phase name lookup.
llvm-svn: 132672
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 132660
|
|
|
|
| |
llvm-svn: 132096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 131813
|
|
|
|
|
|
| |
Necessary to parse MFC code.
llvm-svn: 131076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 131065
|