summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* Correctly track tags and enum members defined in the prototype of a ↵James Molloy2012-02-282-0/+14
| | | | | | | | | | | | | | | function, and ensure they are properly scoped. This fixes code such as: enum e {x, y}; int f(enum {y, x} n) { return 0; } This finally fixes PR5464 and PR5477. llvm-svn: 151638
* When evaluating integer expressions include a check for sub-expressionsArgyrios Kyrtzidis2012-02-271-1/+21
| | | | | | | | depth and error if we exceed a max value, to make sure we avoid a stack overflow. This is a hacky temporary fix. rdar://10913206. llvm-svn: 151585
* Revert testing code I committed by mistake in r151464.Argyrios Kyrtzidis2012-02-271-4/+4
| | | | llvm-svn: 151548
* Reorder members to save padding.Benjamin Kramer2012-02-261-4/+4
| | | | | | | | There's more potential here, but these Exprs aren't used that often so I don't feel like doing heroic bit packing right now. -8 bytes on every class changed (x86_64). llvm-svn: 151501
* Revert r151460 as it is not enough to address the issue.Argyrios Kyrtzidis2012-02-251-52/+38
| | | | | | | | | | | Original log: When evaluating integer expressions handle logical operators outside VisitBinaryOperator() to reduce stack pressure for source with huge number of logical operators. Fixes rdar://10913206. llvm-svn: 151464
* Richard Smith pointed out that there already is a proposal for init list ↵Sebastian Redl2012-02-251-8/+18
| | | | | | mangling. llvm-svn: 151462
* When evaluating integer expressions handle logical operators outsideArgyrios Kyrtzidis2012-02-251-34/+48
| | | | | | | | | VisitBinaryOperator() to reduce stack pressure for source with huge number of logical operators. Fixes rdar://10913206. llvm-svn: 151460
* Better mangling for new-expressions. Also, although we can't mangle ↵Sebastian Redl2012-02-251-4/+15
| | | | | | arbitrary initializer lists yet (we will need this), turn the crash into a controlled error. llvm-svn: 151455
* ArrayRef'ize various functions in the AST/Parser/Sema.Ahmed Charles2012-02-251-12/+2
| | | | llvm-svn: 151447
* Teach CXXRecordDecl::hasIrrelevantDestructor to check the base classes andRichard Smith2012-02-252-3/+25
| | | | | | | | | data members for deleted or user-provided destructors. Now it's computed in advance, serialize it, and in passing fix all the other record DefinitionData flags whose serialization was missing. llvm-svn: 151441
* When checking whether a reference to a variable is an ICE, look at the type ofRichard Smith2012-02-241-4/+5
| | | | | | | the declaration, not at the type of the DeclRefExpr, since within a lambda the DeclRefExpr can be more const than the declaration is. llvm-svn: 151399
* Revert r151357. That unreachable is reachable...Nick Lewycky2012-02-241-11/+8
| | | | llvm-svn: 151359
* Silence gcc warnings pointing out that CharByteWidth could be usedNick Lewycky2012-02-241-8/+11
| | | | | | uninitialized. While there, restyle this function! No functionality change. llvm-svn: 151357
* Remove some trivial uses of hasTrivialCopyConstructor() andDouglas Gregor2012-02-241-2/+2
| | | | | | hasTrivialMoveConstructor(). llvm-svn: 151354
* Implement a new type trait __is_trivially_constructible(T, Args...)Douglas Gregor2012-02-247-1/+80
| | | | | | | | | | | | | | | | that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
* Actually remove the duplicated elements from the vector.Benjamin Kramer2012-02-231-1/+1
| | | | llvm-svn: 151270
* Unique CXXBasePath decls with the SmallVector/pod_sort/std::unique idiom ↵Benjamin Kramer2012-02-231-6/+9
| | | | | | instead of employing a wasteful std::set. llvm-svn: 151255
* Seriously, are injected-class-names that hard?Douglas Gregor2012-02-231-1/+1
| | | | llvm-svn: 151241
* Provide the __is_trivially_assignable type trait, which providesDouglas Gregor2012-02-232-5/+61
| | | | | | | compiler support for the std::is_trivially_assignable library type trait. llvm-svn: 151240
* Two fixes to how we compute visibility:Rafael Espindola2012-02-231-19/+25
| | | | | | | | | | | | * Handle some situations where we should never make a decl more visible, even when merging in an explicit visibility. * Handle attributes in members of classes that are explicitly specialized. Thanks Nico for the report and testing, Eric for the initial review, and dgregor for the awesome test27 :-) llvm-svn: 151236
* More ArrayRef-ification of methods.Bill Wendling2012-02-222-6/+5
| | | | llvm-svn: 151152
* Generate an AST for the conversion from a lambda closure type to aDouglas Gregor2012-02-224-11/+11
| | | | | | | | | | | | | | | block pointer that returns a block literal which captures (by copy) the lambda closure itself. Some aspects of the block literal are left unspecified, namely the capture variable (which doesn't actually exist) and the body (which will be filled in by IRgen because it can't be written as an AST). Because we're switching to this model, this patch also eliminates tracking the copy-initialization expression for the block capture of the conversion function, since that information is now embedded in the synthesized block literal. -1 side tables FTW. llvm-svn: 151131
* Fix a crash in the diangostic code in EvalConstant. PR12043.Eli Friedman2012-02-211-1/+3
| | | | llvm-svn: 151100
* Improve our handling of lambda expressions that occur within defaultDouglas Gregor2012-02-212-4/+8
| | | | | | | | | | | | | | | | | | | arguments. There are two aspects to this: - Make sure that when marking the declarations referenced in a default argument, we don't try to mark local variables, both because it's a waste of time and because the semantics are wrong: we're not in a place where we could capture these variables again even if it did make sense. - When a lambda expression occurs in a default argument of a function template, make sure that the corresponding closure type is considered dependent, so that it will get properly instantiated. The second bit is a bit of a hack; to fix it properly, we may have to rearchitect our handling of default arguments, parsing them only after creating the function definition. However, I'd like to separate that work from the lambdas work. llvm-svn: 151076
* Implement non-internal linkage for lambda closure types that need aDouglas Gregor2012-02-213-7/+36
| | | | | | | | | stable mangling, since these lambdas can end up in multiple translation units. Sema is responsible for deciding when this is the case, because it's already responsible for choosing the mangling number. llvm-svn: 151029
* Implement name mangling for lambda expressions that occur within theDouglas Gregor2012-02-211-11/+29
| | | | | | initializers of data members (both static and non-static). llvm-svn: 151017
* Implement name mangling for lambda expressions that occur within theDouglas Gregor2012-02-212-58/+116
| | | | | | | | | | | | | | | | default arguments of function parameters. This simple-sounding task is complicated greatly by two issues: (1) Default arguments aren't actually a real context, so we need to maintain extra state within lambda expressions to track when a lambda was actually in a default argument. (2) At the time that we parse a default argument, the FunctionDecl doesn't exist yet, so lambda closure types end up in the enclosing context. It's not clear that we ever want to change that, so instead we introduce the notion of the "effective" context of a declaration for the purposes of name mangling. llvm-svn: 151011
* modern objc translator. Finish off first cut of theFariborz Jahanian2012-02-202-6/+16
| | | | | | | modern meta-data translation by commenting out private ivar declarations in user source. Also, added several tests. llvm-svn: 150985
* Basic support for name mangling of C++11 lambda expressions. BecauseDouglas Gregor2012-02-205-3/+83
| | | | | | | | | | | | | | | name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
* ObjCMessageExpr: Don't leave SelLocsKind uninitialized when the send is ↵Benjamin Kramer2012-02-201-1/+1
| | | | | | | | implicit. Fixes PR11929. Found by valgrind. llvm-svn: 150943
* Refuse to compile global std::initializer_lists instead of doing completely ↵Sebastian Redl2012-02-191-0/+4
| | | | | | the wrong thing. llvm-svn: 150928
* Remove dead code.Ahmed Charles2012-02-191-5/+0
| | | | llvm-svn: 150919
* Implement constant expression support for __real__ and __imag__ on lvalueRichard Smith2012-02-181-6/+85
| | | | | | | | | | | | | | | complex numbers. Treat complex numbers as arrays of the corresponding component type, in order to make std::complex behave properly if implemented in terms of _Complex T. Apparently libstdc++'s std::complex is implemented this way, and we were rejecting a member like this: constexpr double real() { return __real__ val; } because it was marked constexpr but unable to produce a constant expression. llvm-svn: 150895
* Fix crash in analyzer diagnostic generation involving subexpressions of ↵Ted Kremenek2012-02-181-0/+4
| | | | | | OpaqueValueExpr not appearing in the ParentMap. Fixes <rdar://problem/10797980>. llvm-svn: 150894
* Fix a problem in the GCC testsuite, exposed by r150557. Compound literalsRichard Smith2012-02-181-2/+7
| | | | | | | are represented as prvalues in C++; don't be fooled into thinking they're global lvalues. llvm-svn: 150870
* Basic code generation support for std::initializer_list.Sebastian Redl2012-02-171-3/+4
| | | | | | | | | | | | | | | | | | | | | | | We now generate temporary arrays to back std::initializer_list objects initialized with braces. The initializer_list is then made to point at the array. We support both ptr+size and start+end forms, although the latter is untested. Array lifetime is correct for temporary std::initializer_lists (e.g. call arguments) and local variables. It is untested for new expressions and member initializers. Things left to do: Massively increase the amount of testing. I need to write tests for start+end init lists, temporary objects created as a side effect of initializing init list objects, new expressions, member initialization, creation of temporary objects (e.g. std::vector) for initializer lists, and probably more. Get lifetime "right" for member initializers and new expressions. Not that either are very useful. Implement list-initialization of array new expressions. llvm-svn: 150803
* Make sure all remaining parts of the constant evaluator are aware that an arrayRichard Smith2012-02-171-46/+35
| | | | | | can be represented by an LValue, and use that to simplify the code a little. llvm-svn: 150789
* Block expressions always have a prototyped function type; expose thisJohn McCall2012-02-171-3/+4
| | | | | | in the AST accessor and micro-optimize it very slightly. llvm-svn: 150787
* Rework the Sema/AST/IRgen dance for the lambda closure type'sDouglas Gregor2012-02-171-0/+6
| | | | | | | | | | | | | | | | | | | | conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
* PR12012: Fix a regression in r150419 where we would try (and fail) toRichard Smith2012-02-171-0/+5
| | | | | | | zero-initialize class types with virtual bases when constant-evaluating an initializer. llvm-svn: 150770
* Pacify gcc's -Wreturn-typeMatt Beaumont-Gay2012-02-161-0/+1
| | | | llvm-svn: 150731
* Revert "Revert "Make CXXNewExpr contain only a single initialier, and not ↵Sebastian Redl2012-02-165-52/+60
| | | | | | | | hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
* Revert "Make CXXNewExpr contain only a single initialier, and not hold the ↵Sebastian Redl2012-02-165-60/+52
| | | | | | | | | | used constructor itself." It leads to a compiler crash in the Bullet benchmark. This reverts commit r12014. llvm-svn: 150684
* Make CXXNewExpr contain only a single initialier, and not hold the used ↵Sebastian Redl2012-02-165-52/+60
| | | | | | | | | | constructor itself. Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities. This breaks the static analysis of new expressions. I've filed PR12014 to track this. llvm-svn: 150682
* constexpr tidyups:Richard Smith2012-02-161-33/+80
| | | | | | | | * Fix bug when determining whether && / || are potential constant expressions * Try harder when determining whether ?: is a potential constant expression * Produce a diagnostic on sizeof(VLA) to provide a better source location llvm-svn: 150657
* Implicitly define a lambda's conversion functions (to functionDouglas Gregor2012-02-161-0/+15
| | | | | | | | | | | | | pointers and block pointers). We use dummy definitions to keep the invariant that an implicit, used definition has a body; IR generation will substitute the actual contents, since they can't be represented as C++. For the block pointer case, compute the copy-initialization needed to capture the lambda object in the block, which IR generation will need later. llvm-svn: 150645
* When overload resolution picks an implicitly-deleted special memberDouglas Gregor2012-02-151-2/+8
| | | | | | | | | function, provide a specialized diagnostic that indicates the kind of special member function (default constructor, copy assignment operator, etc.) and that it was implicitly deleted. Add a hook where we can provide more detailed information later. llvm-svn: 150611
* Implement DR1454. This allows all intermediate results in constant expressionsRichard Smith2012-02-152-166/+267
| | | | | | | | | | | | to be core constant expressions (including pointers and references to temporaries), and makes constexpr calculations Turing-complete. A Turing machine simulator is included as a testcase. This opens up the possibilty of removing CCValue entirely, and removing some copies from the constant evaluator in the process, but that cleanup is not part of this change. llvm-svn: 150557
* Split reinterpret_casts of member pointers out from CK_BitCast; thisJohn McCall2012-02-152-0/+9
| | | | | | | | | | | | | | | | | | | | | is general goodness because representations of member pointers are not always equivalent across member pointer types on all ABIs (even though this isn't really standard-endorsed). Take advantage of the new information to teach IR-generation how to do these reinterprets in constant initializers. Make sure this works when intermingled with hierarchy conversions (although this is not part of our motivating use case). Doing this in the constant-evaluator would probably have been better, but that would require a *lot* of extra structure in the representation of constant member pointers: you'd really have to track an arbitrary chain of hierarchy conversions and reinterpretations in order to get this right. Ultimately, this seems less complex. I also wasn't quite sure how to extend the constant evaluator to handle foldings that we don't actually want to treat as extended constant expressions. llvm-svn: 150551
* constexpr: evaluation support for nullptr comparisons.Richard Smith2012-02-141-0/+10
| | | | llvm-svn: 150521
OpenPOWER on IntegriCloud