aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/DeclSpec.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-12-18Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu1-1/+1
with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
2016-12-16Revert r289979 due to regressionsYaxun Liu1-1/+1
llvm-svn: 289991
2016-12-16[OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu1-1/+1
Added a map to associate types and declarations with extensions. Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation. Fixed some bugs for types associated with extensions. Allow users to use pragma to declare types and functions for supported extensions, e.g. #pragma OPENCL EXTENSION the_new_extension_name : begin // declare types and functions associated with the extension here #pragma OPENCL EXTENSION the_new_extension_name : end Differential Revision: https://reviews.llvm.org/D21698 llvm-svn: 289979
2016-12-09Store decls in prototypes on the declarator instead of in the ASTReid Kleckner1-2/+15
This saves two pointers from FunctionDecl that were being used for some rare and questionable C-only functionality. The DeclsInPrototypeScope ArrayRef was added in r151712 in order to parse this kind of C code: enum e {x, y}; int f(enum {y, x} n) { return x; // should return 1, not 0 } The challenge is that we parse 'int f(enum {y, x} n)' it its own function prototype scope that gets popped before we build the FunctionDecl for 'f'. The original change was doing two questionable things: 1. Saving all tag decls introduced in prototype scope on a TU-global Sema variable. This is problematic when you have cases like this, where 'x' and 'y' shouldn't be visible in 'f': void f(void (*fp)(enum { x, y } e)) { /* no x */ } This patch fixes that, so now 'f' can't see 'x', which is consistent with GCC. 2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that they could be used in ActOnStartOfFunctionDef. This is just an inefficient way to move information around. The AST lives forever, but the list of non-parameter decls in prototype scope is short lived. Moving these things to the Declarator solves both of these issues. Reviewers: rsmith Subscribers: jmolloy, cfe-commits Differential Revision: https://reviews.llvm.org/D27279 llvm-svn: 289225
2016-11-17Fixes for r287241. Use placement new. Apply clang-format.Malcolm Parsons1-6/+2
llvm-svn: 287258
2016-11-17Use unique_ptr for cached tokens for default arguments in C++.Malcolm Parsons1-2/+8
Summary: This changes pointers to cached tokens for default arguments in C++ from raw pointers to unique_ptrs. There was a fixme in the code where the cached tokens are created about using a smart pointer. The change is straightforward, though I did have to track down and fix a memory corruption caused by the change. memcpy was being used to copy parameter information. This duplicated the unique_ptr, which led to the cached token buffer being deleted prematurely. Patch by David Tarditi! Reviewers: malcolm.parsons Subscribers: arphaman, malcolm.parsons, cfe-commits Differential Revision: https://reviews.llvm.org/D26435 llvm-svn: 287241
2016-10-21[Sema] Store a SourceRange for multi-token builtin typesMalcolm Parsons1-15/+19
Summary: clang-tidy's modernize-use-auto check uses the SourceRange of a TypeLoc when replacing the type with auto. This was producing the wrong result for multi-token builtin types like long long: -long long *ll = new long long(); +auto long *ll = new long long(); Reviewers: alexfh, hokein, rsmith, Prazek, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25363 llvm-svn: 284885
2016-07-29[GCC] Support for __final specifierAndrey Bokhanko1-0/+2
As reported in bug 28473, GCC supports "final" functionality in pre-C++11 code using the __final keyword. Clang currently supports the "final" keyword in accordance with the C++11 specification, however it ALSO supports it in pre-C++11 mode, with a warning. This patch adds the "__final" keyword for compatibility with GCC in GCC Keywords mode (so it is enabled with existing flags), and issues a warning on its usage (suggesting switching to the C++11 keyword). This patch also adds a regression test for the functionality described. I believe this patch has minimal impact, as it simply adds a new keyword for existing behavior. This has been validated with check-clang to avoid regressions. Patch is created in reference to revisions 276665. Patch by Erich Keane. Differential Revision: https://reviews.llvm.org/D22919 llvm-svn: 277134
2016-07-22P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith1-2/+34
decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-05-26[MSVC] Support for __unaligned qualifier in functionsAndrey Bokhanko1-1/+1
This implements support for MS-specific __unaligned qualifier in functions and makes the following test case both compile and mangle correctly: struct S { void f() __unaligned; }; void S::f() __unaligned { } Differential Revision: http://reviews.llvm.org/D20437 llvm-svn: 270834
2016-05-11[MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko1-2/+4
This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
2016-05-09Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic1-0/+2
This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
2016-05-06Revert r268727, it caused PR27666.Nico Weber1-4/+2
llvm-svn: 268736
2016-05-06[MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko1-2/+4
This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367. Differential Revision: http://reviews.llvm.org/D19654 llvm-svn: 268727
2016-04-15Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic1-2/+0
Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
2016-04-15Revert r266415, it broke parsing SDK headers (PR27367).Nico Weber1-4/+2
llvm-svn: 266431
2016-04-15[MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifierAndrey Bokhanko1-2/+4
This patch implements __unaligned as a type qualifier; before that, it was modeled as an attribute. Proper mangling of __unaligned is implemented as well. Some OpenCL code/tests are tangenially affected, as they relied on existing number and sizes of type qualifiers. Differential Revision: http://reviews.llvm.org/D18596 llvm-svn: 266415
2016-04-13Enable support for __float128 in ClangNemanja Ivanovic1-0/+2
This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
2016-04-13[OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library.Alexey Bader1-2/+2
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header". This fixes the modules build. Differential revision: http://reviews.llvm.org/D18954 Reviewers: Richard Smith, Vassil Vassilev. llvm-svn: 266180
2016-04-08[OpenCL] Complete image types support.Alexey Bader1-0/+6
I. Current implementation of images is not conformant to spec in the following points: 1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine: void write_image(write_only image2d_t img); kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code which is disallowed according to s6.13.14. 2. It discards access qualifier on generated code, which leads to generated code for the above example: call void @write_image(%opencl.image2d_t* %img); In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images. Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently. 3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names. 4. Default access qualifier read_only is to be added if not provided explicitly. II. This patch corrects the above points as follows: 1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type. 2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers). 3. Improves testing of images in Clang. Author: Anastasia Stulova Reviewers: bader, mgrang. Subscribers: pxli168, pekka.jaaskelainen, yaxunl. Differential Revision: http://reviews.llvm.org/D17821 llvm-svn: 265783
2016-02-01Move LocInfoType from Sema to AST.Benjamin Kramer1-1/+1
While transient and only used during parsing, LocInfoTypes are still used from ASTDumper and are part of the AST. llvm-svn: 259376
2016-01-09[OpenCL] Pipe type supportXiuli Pan1-0/+17
Summary: Support for OpenCL 2.0 pipe type. This is a bug-fix version for bader's patch reviews.llvm.org/D14441 Reviewers: pekka.jaaskelainen, Anastasia Subscribers: bader, Anastasia, cfe-commits Differential Revision: http://reviews.llvm.org/D15603 llvm-svn: 257254
2015-11-15[Sema] Fix filename in header. NFCCraig Topper1-1/+1
llvm-svn: 253174
2015-11-15[Sema] Remove unnecessary includes and forward declarations. NFCCraig Topper1-2/+0
llvm-svn: 253173
2015-11-15Fix a layering oddity by passing Sema to DeclSpec::Finish instead of ↵Craig Topper1-47/+40
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-14Move diagnostics from Parse to Sema to remove Sema's dependency on ↵Craig Topper1-1/+0
ParserDiagnostic.h diagnostics. llvm-svn: 253143
2015-11-14Fix indentation. NFCCraig Topper1-6/+6
llvm-svn: 253142
2015-11-14Merge some similar diagnostics using %select.Craig Topper1-4/+2
llvm-svn: 253136
2015-11-11Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith1-0/+2
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html Differences from the GCC extension: * __auto_type is also permitted in C++ (but only in places where it could appear in C), allowing its use in headers that might be shared across C and C++, or used from C++98 * __auto_type can be combined with a declarator, as with C++ auto (for instance, "__auto_type *p") * multiple variables can be declared in a single __auto_type declaration, with the C++ semantics (the deduced type must be the same in each case) This patch also adds a missing restriction on applying typeof to a bit-field, which GCC has historically rejected in C (due to lack of clarity as to whether the operand should be promoted). The same restriction also applies to __auto_type in C (in both GCC and Clang). This also fixes PR25449. Patch by Nicholas Allegra! llvm-svn: 252690
2015-10-03Replace double-negated !SourceLocation.isInvalid() with ↵Yaron Keren1-1/+1
SourceLocation.isValid(). llvm-svn: 249228
2015-09-14PR24595: Ignore calling convention modifiers for structors in MS ABI.Andrey Bokhanko1-0/+5
MS compiler ignores calling convention modifiers for structors. This patch makes clang do the same (for MS ABI). This fixes PR24595 and makes vswriter.h header (from Windows SDK 8.1) compilable. Differential Revision: http://reviews.llvm.org/D12402 llvm-svn: 247619
2015-08-26Modify DeclaratorChuck::getFunction to be passed an Exception Specification ↵Nathan Wilson1-2/+3
SourceRange Summary: - Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range. - Add diagnostic; function concept having an exception specification. Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11789 llvm-svn: 246005
2015-07-30Add support for System z vector language extensionsUlrich Weigand1-6/+16
The z13 vector facility has an associated language extension, closely modeled on AltiVec/VSX. The main differences are: - vector long, vector float and vector pixel are not supported - vector long long and vector double are supported (like VSX) - comparison operators return a vector rather than a scalar integer - shift operators behave like the OpenCL shift operators - vector bool is only supported as argument to certain operators; some operators allow mixing a bool with a non-bool vector This patch adds clang support for the extension. It is closely modelled on the AltiVec support. Similarly to the -faltivec option, there's a new -fzvector option to enable the extensions (as well as an -mzvector alias for compatibility with GCC). There's also a separate LangOpt. The extension as implemented here is intended to be compatible with the -mzvector extension recently implemented by GCC. Based on a patch by Richard Sandiford. Differential Revision: http://reviews.llvm.org/D11001 llvm-svn: 243642
2015-07-07C++ support for Objective-C lightweight generics.Douglas Gregor1-25/+0
Teach C++'s tentative parsing to handle specializations of Objective-C class types (e.g., NSArray<NSString *>) as well as Objective-C protocol qualifiers (id<NSCopying>) by extending type-annotation tokens to handle this case. As part of this, remove Objective-C protocol qualifiers from the declaration specifiers, which never really made sense: instead, provide Sema entry points to make them part of the type annotation token. Among other things, this properly diagnoses bogus types such as "<NSCopying> id" which should have been written as "id <NSCopying>". Implements template instantiation support for, e.g., NSArray<T>* in C++. Note that parameterized classes are not templates in the C++ sense, so that cannot (for example) be used as a template argument for a template template parameter. Part of rdar://problem/6294649. llvm-svn: 241545
2015-07-07Handle Objective-C type arguments.Douglas Gregor1-0/+11
Objective-C type arguments can be provided in angle brackets following an Objective-C interface type. Syntactically, this is the same position as one would provide protocol qualifiers (e.g., id<NSCopying>), so parse both together and let Sema sort out the ambiguous cases. This applies both when parsing types and when parsing the superclass of an Objective-C class, which can now be a specialized type (e.g., NSMutableArray<T> inherits from NSArray<T>). Check Objective-C type arguments against the type parameters of the corresponding class. Verify the length of the type argument list and that each type argument satisfies the corresponding bound. Specializations of parameterized Objective-C classes are represented in the type system as distinct types. Both specialized types (e.g., NSArray<NSString *> *) and unspecialized types (NSArray *) are represented, separately. llvm-svn: 241542
2015-06-30[CONCEPTS] Parsing of concept keywordHubert Tong1-0/+12
Summary: This change adds parsing for the concept keyword in a declaration and tracks the location. Diagnostic testing added for invalid use of concept keyword. Reviewers: faisalv, fraggamuffin, rsmith, hubert.reinterpretcast Reviewed By: rsmith, hubert.reinterpretcast Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10528 Patch by Nathan Wilson! llvm-svn: 241060
2015-03-30Add check for kind of UnqualifiedId in Declarator::isStaticMember()Petar Jovanovic1-2/+3
Method CXXMethodDecl::isStaticOverloadedOperator expects Operator field from the struct OperatorFunctionId, which is a member of the union in the class UnqualifiedId. If the kind of UnqualifiedId is not checked, there is no guarantee that the value that this method receives will be correct, because it can be the value of another union member and not OperatorFunctionId. This bug manifests itself when running make check-all on mips64 BE. This fix resolves the following regression tests: Clang :: CXX/special/class.dtor/p9.cpp Clang :: CodeGenCXX/2006-09-12-OpaqueStructCrash.cpp Clang :: CodeGenCXX/ctor-dtor-alias.cpp Clang :: CodeGenCXX/debug-info-windows-dtor.cpp Clang :: CodeGenCXX/dllexport-members.cpp Clang :: CodeGenCXX/dllexport.cpp Patch by Violeta Vukobrat. Differential Revision: http://reviews.llvm.org/D8437 llvm-svn: 233508
2015-03-25Diagnose declspecs occuring after virt-specifier-seq and generate fixit hintsEhsan Akhgari1-0/+3
Summary: This fixes PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6828 llvm-svn: 233160
2015-03-24Revert "Diagnose declspecs occuring after virt-specifier-seq and generate ↵Ehsan Akhgari1-3/+0
fixit hints" This reverts commit 2131e63e2fdff7c831ab3bfe31facf2e3ebab03d. llvm-svn: 233074
2015-03-24Diagnose declspecs occuring after virt-specifier-seq and generate fixit hintsEhsan Akhgari1-0/+3
Summary: This fixes PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6828 llvm-svn: 233069
2015-03-11Add builtins for the 64-bit vector integer arithmetic instructions added in ↵Kit Barton1-1/+3
POWER8. These are the Clang-related changes for the instructions added to LLVM in http://reviews.llvm.org/D7959. Phabricator review: http://reviews.llvm.org/D8041 llvm-svn: 231931
2015-03-03[PowerPC]Activate "vector bool long long" (and alternate spellings) as a ↵Bill Seurer1-2/+7
valid type for Altivec support for Power. There are two test case updates for very basic testing. While I was editing cxx-altivec.cpp I also updated it to better match some other changes in altivec.c. Note: "vector bool long" was not also added because its use is considered deprecated. http://reviews.llvm.org/D7235 llvm-svn: 231118
2014-11-26[OpenCL] Generic address space has been added in OpenCL v2.0.Anastasia Stulova1-2/+2
To support it in the frontend, the following has been added: - generic address space type attribute; - documentation for the OpenCL address space attributes; - parsing of __generic(generic) keyword; - test code for the parser and diagnostics. llvm-svn: 222831
2014-11-13PR21437, final part of DR1330: delay-parsing of exception-specifications. ThisRichard Smith1-0/+8
is a re-commit of Doug's r154844 (modernized and updated to fit into current Clang). llvm-svn: 221918
2014-10-31[PowerPC] Initial VSX intrinsic support, with min/max for vector doubleBill Schmidt1-5/+8
Now that we have initial support for VSX, we can begin adding intrinsics for programmer access to VSX instructions. This patch performs the necessary enablement in the front end, and tests it by implementing intrinsics for minimum and maximum using the vector double data type. The main change in the front end is to no longer disallow "vector" and "double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector" and "long double" must still be disallowed. The new intrinsics are accessed via vec_max and vec_min with changes in lib/Headers/altivec.h. Note that for v4f32, we already access corresponding VMX builtins, but with VSX enabled we should use the forms that allow all 64 vector registers. The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def. I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is similar to, but much smaller than, builtins-ppc-altivec.c. This allows us to test VSX IR generation without duplicating CHECK lines for the existing bazillion Altivec tests. Since vector double is now legal when VSX is available, I've modified the error message, and changed where we test for it and for vector long double, since the target machine isn't visible in the old place. This serendipitously removed a not-pertinent warning about 'long' being deprecated when used with 'vector', when "vector long double" is encountered and we just want to issue an error. The existing tests test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been updated accordingly, and I've added test/Parser/vsx.c to verify that "vector double" is now legitimate with VSX enabled. There is a companion patch for LLVM. llvm-svn: 220989
2014-10-20Add RestrictQualifierLoc to DeclaratorChunk::FunctionTypeInfoHal Finkel1-0/+3
Clang supports __restrict__ as a function qualifier, but DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's source location (as we do with volatile, etc.). This was the subject of a FIXME in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as we add more warnings regarding questionable uses of the restrict qualifier. There is no significant functional change (except for an improved source range associated with the err_invalid_qualified_function_type diagnostic fixit generated by GetFullTypeForDeclarator). llvm-svn: 220215
2014-09-26-ms-extensions: Implement __super scope specifier (PR13236).Nikola Smiljanic1-0/+12
We build a NestedNameSpecifier that records the CXXRecordDecl in which __super appeared. Name lookup is performed in all base classes of the recorded CXXRecordDecl. Use of __super is allowed only inside class and member function scope. llvm-svn: 218484
2014-08-24Move __vector long deprecation checking into DeclSpec::FinishHal Finkel1-6/+3
__vector long is deprecated, but __vector long long is not. As a result, we cannot check for __vector long (to issue the deprecation warning) as we parse the type because we need to know how many 'long's we have first. DeclSpec::Finish seems like a more-appropriate place to perform the check (which places it with several other similar Altivec vector checks). Fixes PR20720. llvm-svn: 216342
2014-06-09[C++11] Use 'nullptr'.Craig Topper1-6/+6
llvm-svn: 210448
2014-04-30Sema: Implement DR477David Majnemer1-2/+29
Summary: Friend declarations shouldn't mention explicit or virtual. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3562 llvm-svn: 207682
generated by cgit v1.1 at 2025-10-11 12:04:59 +0000