|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 142695 | 
| | 
| 
| 
| 
| 
| | have an unambiguous accessible copying constructor; this is ill-formed in C++98.
llvm-svn: 142533 | 
| | 
| 
| 
| | llvm-svn: 142426 | 
| | 
| 
| 
| 
| 
| 
| | passing/receiving CF objects at +0 to/from Objective-C methods
or audited C functions.
llvm-svn: 142219 | 
| | 
| 
| 
| 
| 
| | This also applies to C99-style aggregate literals, should they be used in C++11, since they are effectively identical to constructor call list-initialization syntax.
llvm-svn: 142147 | 
| | 
| 
| 
| 
| 
| | an init list can be value-initialized, at least when designated initializers are not involved. No test case yet, since early failures cannot be distinguished from late failures until overload resolution works.
llvm-svn: 142146 | 
| | 
| 
| 
| 
| 
| 
| 
| | of a pointer.
Passing a pointer was a bad idea as it collides with the overload for void*.
llvm-svn: 141971 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | - Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
   and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
   behaviour.
 - Factor out evaluation of bitfield bit widths.
 - Fix a few places which would evaluate an expression twice: once to determine
   whether it is a constant expression, then again to get the value.
llvm-svn: 141561 | 
| | 
| 
| 
| | llvm-svn: 141549 | 
| | 
| 
| 
| 
| 
| | Found by valgrind.
llvm-svn: 141510 | 
| | 
| 
| 
| | llvm-svn: 141171 | 
| | 
| 
| 
| 
| 
| 
| 
| | InitListChecker::getStructuredSubobjectInit which was increasing the reserved size for an init list past its maximum possible size. Fixes PR11056, a case where we were reserving a bunch of memory for arrays that was never actually used.
(No testcase because I don't think we have any way to actually write a testcase for this; the chosen value of NumElements has no effects on anything other than performance and memory usage.)
llvm-svn: 141106 | 
| | 
| 
| 
| | llvm-svn: 140642 | 
| | 
| 
| 
| 
| 
| | references.
llvm-svn: 140594 | 
| | 
| 
| 
| 
| 
| 
| 
| | mode, at least for the moment.  <rdar://problem/10185490>.
Sebastian, please take a look at this; I'm not entirely sure it is the right thing to do.
llvm-svn: 140552 | 
| | 
| 
| 
| 
| 
| | difference at the moment, as far as I can tell.
llvm-svn: 140546 | 
| | 
| 
| 
| 
| 
| | Also make sure we set the error flag when correcting a typo.
llvm-svn: 140466 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Allow empty initializer lists for scalars, which mean value-initialization.
Constant evaluation for single-element and empty initializer lists for scalars.
Codegen for empty initializer lists for scalars.
Test case comes in next commit.
llvm-svn: 140459 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| | resolves to a constructor call in C++11) and failure kind
FK_ListInitializationFailed (early InitListChecker run failed).
llvm-svn: 140456 | 
| | 
| 
| 
| | llvm-svn: 140455 | 
| | 
| 
| 
| | llvm-svn: 140454 | 
| | 
| 
| 
| | llvm-svn: 140367 | 
| | 
| 
| 
| 
| 
| 
| 
| | "_Complex float x = {1.0f, 2.0f};".  See changes to docs/LanguageExtensions.html for a longer description.
<rdar://problem/9397672>.
llvm-svn: 140090 | 
| | 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| | llvm-svn: 139466 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | itself upon initialization, such as using itself within its own copy constructor.
struct S {};
S s(s);
llvm-svn: 138969 | 
| | 
| 
| 
| 
| 
| | aren't considered narrowing conversions.
llvm-svn: 138838 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | qualification of a type doesn't affect whether a conversion is a narrowing
conversion.
This doesn't work in template cases because SubstTemplateTypeParmType gets in
the way.
llvm-svn: 138735 | 
| | 
| 
| 
| 
| 
| 
| 
| | old version had the checks scattered across the code, missed some checks, and had a couple nasty bugs in existing checks.
Fixes PR10648 and another similar accepts-invalid bug.
llvm-svn: 138398 | 
| | 
| 
| 
| | llvm-svn: 138368 | 
| | 
| 
| 
| 
| 
| | mode even if c++0x is enabled. This necessary to parse MSVC code in C++0x mode.
llvm-svn: 137904 | 
| | 
| 
| 
| 
| 
| | the C++0x narrowing error.
llvm-svn: 137512 | 
| | 
| 
| 
| | llvm-svn: 136210 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | [dcl.init.list] as is possible without generalized initializer lists or full
constant expression support, and adds a c++0x-compat warning in C++98 mode.
The FixIt currently uses a typedef's basename without qualification, which is
likely to be incorrect on some code.  If it's incorrect on too much code, we
should write a function to get the string that refers to a type from a
particular context.
The warning is currently off by default. I'll fix LLVM and clang before turning
it on.
llvm-svn: 136181 | 
| | 
| 
| 
| 
| 
| 
| 
| | LLVM.h imports
them into the clang namespace.
llvm-svn: 135852 | 
| | 
| 
| 
| 
| 
| | Test cases provided by Anton Lokhmot.
llvm-svn: 135322 | 
| | 
| 
| 
| 
| 
| 
| 
| | Revert "For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either."
This reverts commit ac420c5053d6aa41d59f782caad9e46e5baaf2c2.
llvm-svn: 135210 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either.
This is a first baby step towards supporting generalized initializer lists. This also removes an aggregate
test case that was just plain wrong, assuming that non-aggregates couldn't be initialized with initializer lists
in C++11 mode.
llvm-svn: 135177 | 
| | 
| 
| 
| 
| 
| | kind.
llvm-svn: 135175 | 
| | 
| 
| 
| 
| 
| | initialized via initializer lists. Fixes <rdar://problem/9694686>.
llvm-svn: 134099 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | vector<int>
to
  std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007 | 
| | 
| 
| 
| 
| 
| | only to pointers to locals.  But it should work inside blocks, too.
llvm-svn: 133969 | 
| | 
| 
| 
| 
| 
| 
| | Removes dead code found in the process.
Adds a test to verify that ParenListExprs do not have NULL types.
llvm-svn: 133637 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | retain/release the temporary object appropriately. Previously, we
would only perform the retain/release operations when the reference
would extend the lifetime of the temporary, but this does the wrong
thing across calls.
llvm-svn: 133620 | 
| | 
| 
| 
| 
| 
| | to, including cv-qualifications.
llvm-svn: 133618 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given
  const int& r = 1.0;
The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value. 
IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.
llvm-svn: 133521 | 
| | 
| 
| 
| | llvm-svn: 133215 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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
llvm-svn: 132868 |