summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* Create a new TypeNodes.def file that enumerates all of the types,Douglas Gregor2009-02-2626-196/+248
| | | | | | | | | | | | | | | | | | | | | | | | | giving them rough classifications (normal types, never-canonical types, always-dependent types, abstract type representations) and making it far easier to make sure that we've hit all of the cases when decoding types. Switched some switch() statements on the type class over to using this mechanism, and filtering out those things we don't care about. For example, CodeGen should never see always-dependent or non-canonical types, while debug info generation should never see always-dependent types. More switch() statements on the type class need to be moved over to using this approach, so that we'll get warnings when we add a new type then fail to account for it somewhere in the compiler. As part of this, some types have been renamed: TypeOfExpr -> TypeOfExprType FunctionTypeProto -> FunctionProtoType FunctionTypeNoProto -> FunctionNoProtoType There shouldn't be any functionality change... llvm-svn: 65591
* make ASTContext::WCharTy a bit more sensical. In C++, it is a disctint type,Chris Lattner2009-02-261-12/+4
| | | | | | but in C99 it is just another int type. llvm-svn: 65590
* fix a bozobug.Chris Lattner2009-02-261-0/+1
| | | | llvm-svn: 65589
* ok, not as broken as I thought, just confusing. This allows Chris Lattner2009-02-262-3/+1
| | | | | | | initialization of wchar_t arrays with wide strings, and generalizes wchar_size.c to work on all targets. llvm-svn: 65586
* allow wide strings to initialize arrays compatible with wchar_t. Chris Lattner2009-02-261-6/+25
| | | | | | | Unfortunately this doesn't work yet because wchar_t is completely broken in C. llvm-svn: 65585
* Do not issue bogus error on __weak/__strong ivar access.Fariborz Jahanian2009-02-261-3/+3
| | | | llvm-svn: 65583
* fix some sema problems with wide strings and hook up basic codegen for them.Chris Lattner2009-02-263-17/+7
| | | | llvm-svn: 65582
* Couple of meta-data segments were wrong. This patch fixes them.Fariborz Jahanian2009-02-261-2/+2
| | | | llvm-svn: 65578
* Make the type associated with a ClassTemplateSpecializationDecl be aDouglas Gregor2009-02-266-12/+44
| | | | | | | | nicely sugared type that shows how the user wrote the actual specialization. This sugared type won't actually show up until we start doing instantiations. llvm-svn: 65577
* PathDiagnosticPiece now automatically strips off trailing periods in ↵Ted Kremenek2009-02-261-0/+27
| | | | | | diagnostic messages. llvm-svn: 65574
* Add support to emit debug info for objective-c interfaces.Devang Patel2009-02-262-3/+121
| | | | | | (This is not yet used.) llvm-svn: 65573
* Refine some grammar in the retain/release diagnostics.Ted Kremenek2009-02-261-21/+15
| | | | llvm-svn: 65571
* Introduce code modification hints into the diagnostics system. When weDouglas Gregor2009-02-2611-20/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). llvm-svn: 65570
* Add Type::hasPointerRepresentation predicate.Daniel Dunbar2009-02-264-23/+5
| | | | | | | | | - For types whose native representation is a pointer. - Use to replace ExprConstant.cpp:HasPointerEvalType, CodeGenFunction::isObjCPointerType. llvm-svn: 65569
* Use Loc::IsLocType() instead of isPointerType() and isReferenceType().Ted Kremenek2009-02-261-2/+1
| | | | llvm-svn: 65568
* Remove PointerLikeType.Daniel Dunbar2009-02-262-20/+3
| | | | | | | - Having pointers and references share a base was not a useful notion. llvm-svn: 65567
* Change PointersToResolve to list the pointee type to resolve, not theDaniel Dunbar2009-02-262-6/+12
| | | | | | | | pointer type. - Drops use of PointerLikeType. - No intended functionality change. llvm-svn: 65566
* Drop uses of getAsPointerLikeType.Daniel Dunbar2009-02-262-3/+7
| | | | | | - No functionality change. llvm-svn: 65563
* Fix <rdar://problem/6574319> clang issues error on 'readonly' property with ↵Steve Naroff2009-02-262-2/+7
| | | | | | | | a defaul setter attribute. Needed to make isPropertyReadonly() non-const (for this fix to compile). I imagine there's a way to retain the const-ness, however I have more important fish to fry. llvm-svn: 65562
* Drop uses of isPointerLikeType.Daniel Dunbar2009-02-263-5/+5
| | | | | | - No functionality change. llvm-svn: 65560
* Fix an inconsistance in objc2's meta-data related toFariborz Jahanian2009-02-261-5/+18
| | | | | | the symbol for the root meta-data. llvm-svn: 65548
* Fix <rdar://problem/6614945> method not found. Steve Naroff2009-02-261-3/+3
| | | | | | This was a fairly recent regression. llvm-svn: 65547
* Classify enum types correctlyAnders Carlsson2009-02-261-0/+3
| | | | llvm-svn: 65533
* Fix http://llvm.org/bugs/show_bug.cgi?id=3544.Steve Naroff2009-02-262-19/+31
| | | | | | | The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug. Created a helper with the correct logic and changed both methods to use it. llvm-svn: 65532
* Make more AST nodes and semantic checkers dependent-expression-aware.Sebastian Redl2009-02-263-90/+143
| | | | llvm-svn: 65529
* Fix ObjCInterfaceDecl::lookupInstanceMethod()/lookupClassMethod() to search ↵Steve Naroff2009-02-261-3/+11
| | | | | | | | | | in inherited protocols. Also changed ObjCInterfaceDecl::lookupClassMethod() to look through a categories protocols. Test/patch submitted by Jean-Daniel Dupas (thanks!). llvm-svn: 65526
* Remove short-circuit evaluation and the extension warnings. I'm Eli Friedman2009-02-261-43/+6
| | | | | | | | | pretty sure we want to keep constant expression verification outside of Evaluate. Because of that, the short-circuit evaluation doesn't generally make sense, and the comma warning doesn't make sense in its current form. llvm-svn: 65525
* Rewrite of isIntegerConstantExpr to be centered around Evaluate. This Eli Friedman2009-02-261-326/+172
| | | | | | | | | | | | | | | | | | | | | | | is a rather big change, but I think this is the direction we want to go; the code is significantly shorter now, and it doesn't duplicate Evaluate code. There shouldn't be any visible changes as far as I know. There has been some movement towards putting ICE handling into Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate instead of isICE). This patch is sort of the opposite of the approach, making ICE handling work without Evaluate being aware of it. I think this approach is better because it separates the code that does the constant evaluation from code that's calculating a rather arbitrary predicate. The one thing I don't really like about this patch is that the handling of commas in C99 complicates it signficantly. (Seriously, what was the standards committee thinking when they wrote that part?) I think I've come up with a decent approach, but it doesn't feel ideal. I might add some way to check for evaluated commas from Evaluate in a subsequent patch; that said, it might not be worth bothering. llvm-svn: 65524
* Fixup spacing.Mike Stump2009-02-261-2/+3
| | | | llvm-svn: 65519
* x86_64 ABI: Qualified id types are passed as pointers.Daniel Dunbar2009-02-261-0/+1
| | | | | | - <rdar://problem/6622451> Bad x86_64 code gen for message call taking one argument. llvm-svn: 65510
* Zap the Sema constant initializer checking code that we aren't using Eli Friedman2009-02-262-531/+2
| | | | | | | | anymore. If we want to reuse bits and pieces to add strict checking for constant initializers, we can dig them out of SVN history; the existing code won't be useful as-is. llvm-svn: 65502
* Fix for PR3663/3669: use TryToFixInvalidVariablyModifiedType for Eli Friedman2009-02-261-33/+37
| | | | | | | variable declarations where applicable. Also, a few fixes to TryToFixInvalidVariablyModifiedType for issues that this exposed. llvm-svn: 65500
* Use RecordFirst/RecordLast range checks in DeclContextDouglas Gregor2009-02-261-1/+1
| | | | llvm-svn: 65489
* Implementing parsing of template-ids as class-names, so that we canDouglas Gregor2009-02-252-10/+28
| | | | | | | | derive from a class template specialization, e.g., class B : public A<int> { }; llvm-svn: 65488
* CodeGen support for copied BlockDeclRefExprs.Mike Stump2009-02-255-38/+112
| | | | llvm-svn: 65487
* Fix subtle bug in EvalEagerlyAssume: Check if the previous node was at the ↵Ted Kremenek2009-02-251-10/+17
| | | | | | same statement. llvm-svn: 65486
* Fix recently introduced switch case fallthrough bug.Ted Kremenek2009-02-251-4/+4
| | | | llvm-svn: 65485
* Cope with use of the token '>>' inside a template argument list, e.g.,Douglas Gregor2009-02-252-14/+40
| | | | | | | | | | | | | vector<vector<double>> Matrix; In C++98/03, this token always means "right shift". However, if we're in a context where we know that it can't mean "right shift", provide a friendly reminder to put a space between the two >'s and then treat it as two >'s as part of recovery. In C++0x, this token is always broken into two '>' tokens. llvm-svn: 65484
* Add experimental logic in GRExprEngine::EvalEagerlyAssume() to handleTed Kremenek2009-02-251-3/+49
| | | | | | | | | | | expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y != 10)' lazily, the cast to another integer type currently loses the symbolic constraint. Eager evaluation of the constraint causes the paths to bifurcate and eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address <rdar://problem/6619921> until we have a better (more lazy approach) for handling promotions/truncations of symbolic integer values. llvm-svn: 65480
* Improve location information on "reused" class template specializationDouglas Gregor2009-02-251-6/+16
| | | | | | | | decls. Test and document the semantic location of class template specialization definitions that occur within a scope enclosing the scope of the class template. llvm-svn: 65478
* Perform additional semantic checking of class templateDouglas Gregor2009-02-253-11/+116
| | | | | | | | | | | | specializations. In particular: - Make sure class template specializations have a "template<>" header, and complain if they don't. - Make sure class template specializations are declared/defined within a valid context. (e.g., you can't declare a specialization std::vector<MyType> in the global namespace). llvm-svn: 65476
* Temporarily disable clearing of insert point (to indicate unreachableDaniel Dunbar2009-02-251-0/+5
| | | | | | | code) when calling noreturn functions; general expression emission isn't ready to do the right thing in all cases. llvm-svn: 65473
* Allow constant initializers to reference their defining decl.Daniel Dunbar2009-02-251-0/+9
| | | | | | - PR3662. llvm-svn: 65472
* Fold GeneraticStaticBlockVarDecl into callers.Daniel Dunbar2009-02-252-34/+14
| | | | | | - No functionality change. llvm-svn: 65470
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-2510-145/+361
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* Pull COdeGenFunction::CreateStaticBlockVarDecl (just for creating theDaniel Dunbar2009-02-254-65/+92
| | | | | | | | global variable) out of GenerateStaticBlockVarDecl. - No intended functionality change. - Prep for some mild cleanups and PR3662. llvm-svn: 65466
* add c++ search path for GCC 4.2, PR3668, patch by Pawel Worach!Chris Lattner2009-02-251-1/+3
| | | | llvm-svn: 65462
* Use CheckAssignmentConstraints for checking the cleanup attr function. Fixes ↵Anders Carlsson2009-02-251-1/+1
| | | | | | PR3656. llvm-svn: 65461
* C99 DR #316 implies that the function parameter types that are knownDouglas Gregor2009-02-254-4/+27
| | | | | | | | | | only from a function definition (that does not have a prototype) are only used to determine the compatible with other declarations of that same function. In particular, when referencing the function we pretend as if it does not have a prototype. Implement this behavior, which fixes PR3626. llvm-svn: 65460
* Minor cleanup for IntToBlockPointer so it applies to all callers of Eli Friedman2009-02-251-5/+1
| | | | | | | Sema::CheckAssignmentConstraints; not really visible, but the right thing to do. llvm-svn: 65428
OpenPOWER on IntegriCloud