Age | Commit message (Collapse) | Author |
|
__builtin_ versions of these functions as well as the normal function
versions, so that it works on platforms where memset/memcpy/memmove
are macros that map down to the builtins (e.g., Darwin). Fixes
<rdar://problem/9372688>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
checks that the deduced argument type for a function call matches the
actual argument type provided. The only place we've found where the
consistency checking should actually cause template argument deduction
failure is due to qualifier differences that don't fall into the realm
of qualification conversions (which are *not* checked when we
initially perform deduction). However, we're performing the full
checking as specified in the standard to ensure that no other cases
exist.
Fixes PR9233 / <rdar://problem/9039590>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133109 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
|
|
were just punting on template argument deduction for a number of type
nodes. Most of them, obviously, didn't matter.
As a consequence of this, make extended vector types (via the
ext_vector_type attribute) actually work properly for several
important cases:
- If the attribute appears in a type-id (i.e, not attached to a
typedef), actually build a proper vector type
- Build ExtVectorType whenever the size is constant; previously, we
were building DependentSizedExtVectorType when the size was constant
but the type was dependent, which makes no sense at all.
- Teach template argument deduction to handle
ExtVectorType/DependentSizedExtVectorType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132878 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
properties.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to study it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I believe, upon, careful review, that this code causes us to incorrectly
handle exception specifications of copy assignment operators in C++03
mode. However, we currently do not seem to properly implement the subtle
distinction between copying of members and bases made by implicit copy
constructors and assignment operators in C++03 - namely that they are
limited in their overload selection - in all cases. As such, I feel that
committing this code is correct pending a careful review of our
implementation of these semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
isn't yet used for the less controlled environments of initialization.
Also a few random text fixups.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Wmismatched-tags.
- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree. Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132831 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is not a sanctioned keyword and is assumed as default.
// rdar://8790791
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"unsafe mix of type 'int' and type 'bool' in operation"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132674 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
really contain any information that the step array didn't contain too. This makes debugging dumps a bit less informative, but probably not significantly so. The advantage is that the redundancy is gone, so the code is easier to understand.
ReferenceBinding is still there, because it is used in some unclear code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132666 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SemaInit.cpp. Replace them with the boolean conversion or the new Failed() function. This is a first step towards removing InitializationSequence::SequenceKind. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132664 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
|
|
the self-host failures and Chandler's concerns.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132612 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
suggested by Chandler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132593 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
destructors are implemented but other special members are on the way,
which is where the real benefits of this will be visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointed out a better/simpler way to do it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration if the tag name is not already declared. The tag name is declared in the next outermost non record scope.
Example:
class A {
friend class B;
B* b;
};
B* global_b;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132332 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vtables! Fixes PR10020
This also allows us to revert the part of r130023 which added a big loop around
the template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I tried to use an assert to prove that I could remove each of the
arguments I did, but ended up writing my assert with inverted logic.
Doh! Reported by Xi Wang on cfe-dev. I have manually verified the source
locations and ranges for these using -ast-dump. I tried writing a test
case that would catch these, but these expressions aren't exposed in the
c-index-test's token annotation utility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132284 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132172 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
traits which uses the information embedded in the expression. Use this
to simplify several interfaces which repeated information embedded in
the expression through explicit arguments. I added an assertion that the
only extra piece of data to come in from the parser matches what is
stored in the expression. No functionality change intended here.
Also cleaned up the doxygen comments for some of these methods and some
formatting oddities.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132096 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
behind implicit moves. We now correctly identify move constructors and
assignment operators and update bits on the record correctly. Generation
of implicit moves (declarations or definitions) is not yet supported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132080 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type that turns one type into another. This is used as the basis to
implement __underlying_type properly - with TypeSourceInfo and proper
behavior in the face of templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132017 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration found is unaccessible (private) and that declaration was bring into scope via another using declaration whose target declaration is accessible (public) then no error is generated.
Example:
class A { public: int f(); };
class B : public A { private: using A::f; };
class C : public B { private: using B::f; };
Here, B::f is private so this should fail in Standard C++, but because B::f refers to A::f which is public MSVC accepts it.
This fixes 1 error when parsing MFC code with clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131727 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131633 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for destructors until the class is complete and destructors have been adjusted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
other things, libcxx not building.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131573 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131336 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'true' on detecting protocol cycles. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
One more special member to go
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131287 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131260 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't build circular AST in protocol's protocol list
when user code has introduced it. Indexer and other
clients may crash. // rdar://9221614
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131228 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Yes, I'm aware that the diagnostics are awful.
Tests to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131203 91177308-0d34-0410-b5e6-96231b3b80d8
|