aboutsummaryrefslogtreecommitdiff
path: root/lib/Parse/ParseDecl.cpp
AgeCommit message (Collapse)Author
2011-09-04Support code-completion for C++ inline methods and ObjC buffering methods.Argyrios Kyrtzidis
Previously we would cut off the source file buffer at the code-completion point; this impeded code-completion inside C++ inline methods and, recently, with buffering ObjC methods. Have the code-completion inserted into the source buffer so that it can be buffered along with a method body. When we actually hit the code-completion point the cut-off lexing or parsing. Fixes rdar://10056932&8319466 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139086 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-30objc - fixes a regression in declaring c decls nested inFariborz Jahanian
objective-c containers due to recent changes to objc decl contexts. // rdar://10041908 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138803 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-25Add support for Microsoft __ptr32 keyword. Francois Pichet
Patch by Chris Cudmore! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138533 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-22Restore patch I reversed in r138040. Known buildbotFariborz Jahanian
failures are resolved. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138234 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-19Revers r138040. Need to look at a few buildbot failures.Fariborz Jahanian
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138049 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-19objective-c: Bring objective-c handling of decl contextFariborz Jahanian
to modernity. Instead of passing down individual context objects from parser to sema, establish decl context in parser and have sema access current context as needed. I still need to take of Doug's comment for minor cleanups. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138040 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-18Add support for MSVC __unaligned attribute. Necessary to parse MSVC headers ↵Francois Pichet
in 64-bit mode (ie: when _M_IA64 or _M_AMD64 is defined) more info: http://msdn.microsoft.com/en-us/library/ms177389.aspx git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137935 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-09Thread Safety: Added basic argument parsing for all new attributes.Caitlin Sadowski
This patch special cases the parser for thread safety attributes so that all attribute arguments are put in the argument list (instead of a special parameter) since arguments may not otherwise resolve correctly without two-token lookahead. This patch also adds checks to make sure that attribute arguments are lockable objects. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137130 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-04Parsing of C++0x lambda expressions, from John Freeman with help fromDouglas Gregor
David Blaikie! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136876 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-23remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner
LLVM.h imports them into the clang namespace. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135852 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-13Add 'mutable' to the function declarator chunk, to be used whenDouglas Gregor
parsing lambda expressions, from John Freeman! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135090 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-06Properly protect colons when parsing a nested-name-specifier as partJohn McCall
of an enum specifier in dialects which permit fixed underlying types. Fixes the rejects-valid part of PR10264. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134468 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-05Clean up and refactor ParseFunctionDeclarator to reduce codeDouglas Gregor
repetition and better reflect the actual grammar, from John Freeman! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134417 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-01Fix AST representations of alias-declarations which define tag types. Inside ↵Richard Smith
classes, the tag types need to have an associated access specifier, and inside function definitions, they need to be included in the declarations of the DeclStmt. These issues manifested as assertions during template instantiation, and also in a WIP constexpr patch. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134250 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-22Introduce DelayedCleanupPool useful for simplifying clean-up of certain ↵Argyrios Kyrtzidis
resources that, while their lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak. Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133610 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-19Handle decltype keyword in Parser::isDeclarationSpecifier.Francois Pichet
Fixes PR10154. Found by parsing MFC 2010 code with clang. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133380 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-15Automatic Reference Counting.John McCall
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
2011-06-05Parse C++0x generalized initializers.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132662 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-19Implement __underlying_type for libc++.Sean Hunt
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131633 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-12Properly parse the 'default' and 'delete' keywords.Sean Hunt
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
2011-05-07Don't fail at parsing __declspec(property(get=get_func_name)). Just skip ↵Francois Pichet
everything inside property() for now while we wait for the BoostPro people to provide a complete patch. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131053 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-06Per Richard's suggestion, rename DefLoc to DefaultLoc where it appears.Sean Hunt
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131018 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-06Do defaulted constructors properly.Sean Hunt
Explictly defaultedness is correctly reflected on the AST, but there are no changes to how that affects the definition of functions or much else really. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130974 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-06Revert r130912 in order to approach defaulted functions from the otherSean Hunt
direction and not introduce things in the wrong place three different times. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130968 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-05Implement some framework for defaulted constructors.Sean Hunt
There's some unused stuff for now. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130912 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-28libstdc++ 4.4 uses __is_signed as an identifier, while Clang treats itDouglas Gregor
as a keyword for the __is_signed type trait. Cope with this conflict via some hackish recovery: if we see a declaration of the form static const bool __is_signed then we stop treating __is_signed as a keyword and instead treat it as an identifier. It's ugly, but it's better than making the __is_signed type trait conditional on some language flag. Fixes PR9804. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130399 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-28Upgrade Microsoft's __int8, __int16, __int32 and __int64 types from builtin ↵Francois Pichet
defines to real types. Otherwise statements like: __int64 var = __int64(0); would be expanded to: long long var = long long(0); and fail to compile. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130369 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-27Clean out some cruft I introduced when adding Sema::ClassifyName()Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130295 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-27Simplify the parser's handling of Sema::ClassifyName() for types, byDouglas Gregor
creating a type-annotation token rather than jumping into the declaration parsing. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130293 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-24Implement a new identifier-classification scheme where SemaDouglas Gregor
performs name lookup for an identifier and resolves it to a type/expression/template/etc. in the same step. This scheme is intended to improve both performance (by reducing the number of redundant name lookups for a given identifier token) and error recovery (by giving Sema a chance to correct type names before the parser has decided that the identifier isn't a type name). For example, this allows us to properly typo-correct type names at the beginning of a statement: t.c:6:3: error: use of undeclared identifier 'integer'; did you mean 'Integer'? integer *i = 0; ^~~~~~~ Integer t.c:1:13: note: 'Integer' declared here typedef int Integer; ^ Previously, we wouldn't give a Fix-It because the typo correction occurred after the parser had checked whether "integer" was a type name (via Sema::getTypeName(), which isn't allowed to typo-correct) and therefore decided to parse "integer * i = 0" as an expression. By typo-correcting earlier, we typo-correct to the type name Integer and parse this as a declaration. Moreover, in this context, we can also typo-correct identifiers to keywords, e.g., t.c:7:3: error: use of undeclared identifier 'vid'; did you mean 'void'? vid *p = i; ^~~ void and recover appropriately. Note that this is very much a work-in-progress. The new Sema::ClassifyName is only used for expression-or-declaration disambiguation in C at the statement level. The next steps will be to make this work for the same disambiguation in C++ (where functional-style casts make some trouble), then push it further into the parser to eliminate more redundant name lookups. Fixes <rdar://problem/7963833> for C and starts us down the path of <rdar://problem/8172000>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130082 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-21Fixit suggestion for adding missing tag name should have a space after the ↵Argyrios Kyrtzidis
tag name. Fixes rdar://9295072 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129917 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-19Avoid superfluous warning after an error is detcted and reported.Fariborz Jahanian
// rdar://9132143 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129822 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-15C1X: implement static assertsPeter Collingbourne
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129555 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith
draft standard (N3291). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129541 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-09Fix a bunch of major problems with __unknown_anytype and properly testJohn McCall
for them. The only major missing feature is references. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129234 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-26Extend the new 'availability' attribute with support for anDouglas Gregor
'unavailable' argument, which specifies that the declaration to which the attribute appertains is unavailable on that platform. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128329 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-24Insomniac refactoring: change how the parser allocates attributes so thatJohn McCall
AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128209 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-23Implement a new 'availability' attribute, that allows one to specifyDouglas Gregor
which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128127 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-18Add support for language-specific address spaces. On top of that,Peter Collingbourne
add support for the OpenCL __private, __local, __constant and __global address spaces, as well as the __read_only, _read_write and __write_only image access specifiers. Patch originally by ARM; language-specific address space support by myself. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127915 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16Use ElaboratedType also for C.Abramo Bagnara
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127755 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-14Disable 'auto' type deduction in Objective-C. It likes 'id' a bit tooDouglas Gregor
much to be useful. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127625 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-12Forgotten part of previous commit.Abramo Bagnara
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127536 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-11Add support for the OpenCL vec_step operator, by generalising andPeter Collingbourne
extending the existing support for sizeof and alignof. Original patch by Guy Benyei. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127475 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-05Propagate new-style exception spec information to Declarator.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127111 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-05Parser support for noexcept specifications.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127086 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-02Push nested-name-specifier source-location information into dependentDouglas Gregor
template specialization types. This also required some parser tweaks, since we were losing track of the nested-name-specifier's source location information in several places in the parser. Other notable changes this required: - Sema::ActOnTagTemplateIdType now type-checks and forms the appropriate type nodes (+ source-location information) for an elaborated-type-specifier ending in a template-id. Previously, we used a combination of ActOnTemplateIdType and ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped around a DependentTemplateSpecializationType, which duplicated the keyword ("class", "struct", etc.) and nested-name-specifier storage. - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which it places into the returned type-source location information. - Sema::ActOnDependentTag now creates types with source-location information. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126808 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-01Reinstate the introduction of source-location information forDouglas Gregor
nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126765 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-01Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor
location information for elaborated types. *sigh* git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126753 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-01Reinstate r126737, extending the generation of type-source locationDouglas Gregor
information for qualifier type names throughout the parser to address several problems. The commit message from r126737: Push nested-name-specifier source location information into elaborated name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126748 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-24Retain complete source-location information for C++Douglas Gregor
nested-name-specifiers throughout the parser, and provide a new class (NestedNameSpecifierLoc) that contains a nested-name-specifier along with its type-source information. Right now, this information is completely useless, because we don't actually store the source-location information anywhere in the AST. Call this Step 1/N. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126391 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-05-07 17:17:26 +0000