summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser
Commit message (Collapse)AuthorAgeFilesLines
* [ObjC] Avoid a @try/@finally/@autoreleasepool fixit when parsing an expressionAlex Lorenz2016-12-011-0/+28
| | | | | | | | | | | | This patch ensures that the typo fixit for the @try/@finally/@autoreleasepool {} directive is shown only when we're parsing an actual statement where such directives can actually be present. rdar://19669565 Differential Revision: https://reviews.llvm.org/D26916 llvm-svn: 288334
* Accept nullability qualifiers on array parameters.Jordan Rose2016-11-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since array parameters decay to pointers, '_Nullable' and friends should be available for use there as well. This is especially important for parameters that are typedefs of arrays. The unsugared syntax for this follows the syntax for 'static'-sized arrays in C: void test(int values[_Nullable]); This syntax was previously accepted but the '_Nullable' (and any other attributes) were silently discarded. However, applying '_Nullable' to a typedef was previously rejected and is now accepted; therefore, it may be necessary to test for the presence of this feature: #if __has_feature(nullability_on_arrays) One important change here is that DecayedTypes don't always immediately contain PointerTypes anymore; they may contain an AttributedType instead. This only affected one place in-tree, so I would guess it's not likely to cause problems elsewhere. This commit does not change -Wnullability-completeness just yet. I want to think about whether it's worth doing something special to avoid breaking existing clients that compile with -Werror. It also doesn't change '#pragma clang assume_nonnull' behavior, which currently treats the following two declarations as equivalent: #pragma clang assume_nonnull begin void test(void *pointers[]); #pragma clang assume_nonnull end void test(void * _Nonnull pointers[]); This is not the desired behavior, but changing it would break backwards-compatibility. Most likely the best answer is going to be adding a new warning. Part of rdar://problem/25846421 llvm-svn: 286519
* Fix off-by-one error in PPCaching.cpp token annotation assertionReid Kleckner2016-10-201-0/+17
| | | | | | | | | | | This assert is intended to defend against backtracking into the middle of a sequence of tokens that is being replaced with an annotation, but it's OK if we backtrack to the exact position of the start of the annotation sequence. Use a <= comparison instead of <. Fixes PR25946 llvm-svn: 284777
* PR26276: Fix detection of non-cast-expressions as operands of fold-expressions.Richard Smith2016-10-201-0/+7
| | | | llvm-svn: 284684
* [CUDA] Rework tests now that we emit deferred diagnostics during sema. ↵Justin Lebar2016-10-191-3/+2
| | | | | | | | | | | | | | | | | | | | | | Test-only change. Summary: Previously we had to split out a lot of our tests into a test that checked only immediate errors and a test that checked only deferred errors. This was because, if you emitted any immediate errors, we wouldn't run codegen, where the deferred errors were emitted. We've fixed this, and now emit deferred errors during sema. This lets us merge a bunch of tests, and lets us convert some other tests to -fsyntax-only. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25755 llvm-svn: 284553
* [CUDA] Emit deferred diagnostics during Sema rather than during codegen.Justin Lebar2016-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Emitting deferred diagnostics during codegen was a hack. It did work, but usability was poor, both for us as compiler devs and for users. We don't codegen if there are any sema errors, so for users this meant that they wouldn't see deferred errors if there were any non-deferred errors. For devs, this meant that we had to carefully split up our tests so that when we tested deferred errors, we didn't emit any non-deferred errors. This change moves checking for deferred errors into Sema. See the big comment in SemaCUDA.cpp for an overview of the idea. This checking adds overhead to compilation, because we have to maintain a partial call graph. As a result, this change makes deferred errors a CUDA-only concept (whereas before they were a general concept). If anyone else wants to use this framework for something other than CUDA, we can generalize at that time. This patch makes the minimal set of test changes -- after this lands, I'll go back through and do a cleanup of the tests that we no longer have to split up. Reviewers: rnk Subscribers: cfe-commits, rsmith, tra Differential Revision: https://reviews.llvm.org/D25541 llvm-svn: 284158
* [CUDA] Add #pragma clang force_cuda_host_device_{begin,end} pragmas.Justin Lebar2016-10-082-0/+77
| | | | | | | | | | | | | | | | | Summary: These cause us to consider all functions in-between to be __host__ __device__. You can nest these pragmas; you just can't have more 'end's than 'begin's. Reviewers: rsmith Subscribers: tra, jhen, cfe-commits Differential Revision: https://reviews.llvm.org/D24975 llvm-svn: 283677
* [coroutines] Rename driver flag -fcoroutines to -fcoroutines-tsGor Nishanov2016-10-021-1/+1
| | | | | | | | | | | | | | | Summary: Also makes -fcoroutines_ts to be both a Driver and CC1 flag. Patch mostly by EricWF. Reviewers: rnk, cfe-commits, rsmith, EricWF Subscribers: mehdi_amini Differential Revision: https://reviews.llvm.org/D25130 llvm-svn: 283064
* [CUDA] Emit a warning if a CUDA host/device/global attribute is placed after ↵Justin Lebar2016-09-301-2/+11
| | | | | | | | | | | | | | | | | | | | | | | '(...)'. Summary: This is probably the sane place for the attribute to go, but nvcc specifically rejects it. Other GNU-style attributes are allowed in this position (although judging from the warning it emits for host/device/global, those attributes are applied to the lambda's anonymous struct, not to the function itself). It would be nice to have a FixIt message here, but doing so, or even just getting the correct range for the attribute, including its '((' and '))'s, is apparently Hard. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25115 llvm-svn: 282911
* [CUDA] Handle attributes on CUDA lambdas appearing between [...] and (...).Justin Lebar2016-09-301-0/+33
| | | | | | | | | | | | Summary: This is ugh, but it makes us compatible with NVCC. Fixes bug 26341. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25103 llvm-svn: 282879
* C++ Modules TS: Add parsing and some semantic analysis support forRichard Smith2016-09-081-16/+27
| | | | | | | export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
* Add a few more test for []-style uuid attributes.Nico Weber2016-09-071-0/+27
| | | | | | | | - Should diag on a function (clang-cl warns; it's an error in cl) - Test the attribute on nested classes (clang-cl is more permissive and more self-consistent than cl here) llvm-svn: 280845
* Add a test Aaron asked for that I forgot to add before landing r280578.Nico Weber2016-09-031-0/+2
| | | | llvm-svn: 280580
* [ms] Add support for parsing uuid as a Microsoft attribute.Nico Weber2016-09-032-0/+149
| | | | | | | | | | | | | | | | | Some Windows SDK classes, for example Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling attributes: [uuid("....")] class IBufferByteAccess {}; To be able to use __uuidof() to grab the uuid off these types, clang needs to support uuid as a Microsoft attribute. There was already code to skip Microsoft attributes, extend that to look for uuid and parse it. Use the new "Microsoft" attribute type added in r280575 (and r280574, r280576) for this. Final part of https://reviews.llvm.org/D23895 llvm-svn: 280578
* (clang part) Implement MASM-flavor intel syntax behavior for inline MS asm ↵Yunzhong Gao2016-09-021-4/+4
| | | | | | | | | | | | | | block. Clang tests for verifying the following syntaxes: 1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not. 0xNN and NNh may come with optional U or L suffix. 2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not. NNb may come with optional U or L suffix. Differential Revision: https://reviews.llvm.org/D22112 llvm-svn: 280556
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-262-11/+37
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* C++ Modules TS: support parsing the 'module' declaration (including extensionsRichard Smith2016-08-191-3/+34
| | | | | | | | from p0273r0 approved by EWG). We'll eventually need to handle this from the lexer as well, in order to disallow preprocessor directives preceding the module declaration and to support macro import. llvm-svn: 279196
* C++ Modules TS: Add parsing support for module import declaration.Richard Smith2016-08-181-0/+22
| | | | llvm-svn: 279163
* [ObjC] Warn on unguarded use of partial declarationErik Pilkington2016-08-161-2/+0
| | | | | | | | | | | | | | This commit adds a traversal of the AST after Sema of a function that diagnoses unguarded references to declarations that are partially available (based on availability attributes). This traversal is only done when we would otherwise emit -Wpartial-availability. This commit is part of a feature I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D23003 llvm-svn: 278826
* P0217R3: Perform semantic checks and initialization for the bindings in aRichard Smith2016-08-111-2/+15
| | | | | | | decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
* Update Clang Parser test error message to match new parser errorsNirav Dave2016-08-021-1/+1
| | | | | | Update clang tests in light of r277489. llvm-svn: 277490
* Revert r276896 "Update Clang Parser test error message to match new parser ↵Hans Wennborg2016-08-011-1/+1
| | | | | | | | errors" This depended on r276895, which was reverted in r277402. llvm-svn: 277405
* [Parse] Let declarations follow labels in -fms-extensions modeDavid Majnemer2016-08-011-0/+9
| | | | | | | | | MSVC permits declarations in these places as conforming extension (it is a constraint violation otherwise). This fixes PR28782. llvm-svn: 277352
* [GCC] Support for __final specifierAndrey Bokhanko2016-07-291-0/+9
| | | | | | | | | | | | | | 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
* Update Clang Parser test error message to match new parser errorsNirav Dave2016-07-271-1/+1
| | | | llvm-svn: 276896
* P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith2016-07-221-0/+135
| | | | | | | | | | | 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
* [ObjC] Implement @available in the Parser and ASTErik Pilkington2016-07-161-0/+24
| | | | | | | | | | | | | | | | This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the Parser and Sema to generate it. This node represents an availability check of the form: @available(macos 10.10, *); Which will eventually compile to a runtime check of the host's OS version. This is the first patch of the feature I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential Revision: https://reviews.llvm.org/D22171 llvm-svn: 275654
* P0305R0: Semantic analysis and code generation for C++17 init-statement for ↵Richard Smith2016-07-141-13/+15
| | | | | | | | | | 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
* Fix typo-correction crash if a typo occurs within the operand of aRichard Smith2016-06-301-3/+5
| | | | | | | | | function-style cast to a non-dependent type which is then used in an invalid way. We'd lose the "type dependent" bit here, and downstream Sema processing would then discard the expression if it was used in a context where its type rendered it invalid. llvm-svn: 274267
* P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.Richard Smith2016-06-292-1/+47
| | | | | | | | | | | | | | | | | | No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
* Re-commit r273548, reverted in r273589, with a fix to not produceRichard Smith2016-06-231-2/+2
| | | | | | | | | | | | | | | | -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
* Revert r273548, "Rearrange condition handling so that semantic checks on a ↵Peter Collingbourne2016-06-231-2/+2
| | | | | | | | condition variable" as it caused a regression in -Wfor-loop-analysis. llvm-svn: 273589
* Rearrange condition handling so that semantic checks on a condition variableRichard Smith2016-06-231-2/+2
| | | | | | | | | are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273548
* Add loop pragma for Loop DistributionAdam Nemet2016-06-142-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
* [Parser] Handle __pragma(pack, etc. after type definitionsDavid Majnemer2016-06-141-0/+4
| | | | | | | | | Support certain MS pragmas right after the closing curly brace of a class. Clang did not expect __pragma in this position. This fixes PR28094. llvm-svn: 272628
* Disable warning about core features by defaultJan Vesely2016-06-011-1/+1
| | | | | | | | Reviewers: Anastasia, yaxunl Differential Revision: http://reviews.llvm.org/D20744 llvm-svn: 271414
* [Parser] Fix look ahead after EOF while parsing objc message and lambdasBruno Cardoso Lopes2016-05-311-0/+11
| | | | | | | | | | | | | If a closing ')' isn't found for a macro instantiation inside a '[', the next token is EOF, this leads to crashes if we try to look ahead of that. This could be triggered whenever trying to parse lambdas or objs message expressions. Differential Revision: http://reviews.llvm.org/D20451 rdar://problem/25662647 llvm-svn: 271314
* [OpenCL] Add supported OpenCL extensions to target info.Yaxun Liu2016-05-164-15/+17
| | | | | | | | | | Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line. Re-commit after fixing build error due to missing override attribute. Differential Revision: http://reviews.llvm.org/D19484 llvm-svn: 269670
* Warn when a reference is bound to an empty l-value (dereferenced null pointer).Nick Lewycky2016-05-141-1/+1
| | | | llvm-svn: 269572
* Revert "[OpenCL] Add supported OpenCL extensions to target info."Yaxun Liu2016-05-134-17/+15
| | | | | | | | | Revert r269431 due to build failure caused by warning msg: llvm/tools/clang/lib/Basic/Targets.cpp:2090:9: error: 'setSupportedOpenCLOpts' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override] void setSupportedOpenCLOpts() { llvm-svn: 269435
* [OpenCL] Add supported OpenCL extensions to target info.Yaxun Liu2016-05-134-15/+17
| | | | | | | | Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line. Differential Revision: http://reviews.llvm.org/D19484 llvm-svn: 269431
* [OpenCL] Output OpenCL version in diagnostics.Anastasia Stulova2016-05-122-10/+10
| | | | | | | | | | | | | | Diagnostics should note version dependent issues by giving a hint about current version being compiled for. This patch changes diagnostics of static storage class specifier and generic type qualifier to specify OpenCL version as well as converts other diagnostics to match the style. Patch by Vedran Miletic! Review: http://reviews.llvm.org/D19780 llvm-svn: 269305
* Expose cxx constructor and method properties through libclang and python ↵Jonathan Coe2016-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | bindings. Summary: I have exposed the following function through libclang and the clang.cindex python bindings: clang_CXXConstructor_isConvertingConstructor, clang_CXXConstructor_isCopyConstructor, clang_CXXConstructor_isDefaultConstructor, clang_CXXConstructor_isMoveConstructor, clang_CXXMethod_isDefaulted I need (some of) these methods for a C++ code model I am building in Python to drive a code generator. Reviewers: compnerd, skalinichev Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15469 llvm-svn: 267706
* Add a test case to check a member's default constructor is also run.Akira Hatanaka2016-04-191-0/+4
| | | | | | This is a follow-up to r266645. llvm-svn: 266706
* [Parser][ObjC] Make sure c++11 in-class initialization is done when theAkira Hatanaka2016-04-181-0/+17
| | | | | | | | | | | | | | | | | | | | constructor's definition is in an implementation block. Without this commit, ptr doesn't get initialized to null in the following code: struct S { S(); void *ptr = nullptr; }; @implementation I S::S() {} @end rdar://problem/25693624 llvm-svn: 266645
* Lit C++11 Compatibility Patch #8Charles Li2016-04-143-20/+113
| | | | | | 24 tests have been updated for C++11 compatibility. llvm-svn: 266387
* ObjC class properties: add diagnostics for unimplemented class properties.Manman Ren2016-04-121-1/+0
| | | | | | rdar://24711047 llvm-svn: 266146
* Diagnose missing macro argument following charize operator.Andy Gibbs2016-04-011-0/+3
| | | | | | | For completeness, add a test-case for the equivalent stringize operator diagnostic too. llvm-svn: 265177
* [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier ↵Faisal Vali2016-03-261-0/+31
| | | | | | | | | | | | | | | | | | | | | | (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
* The time when -faltivec (or, on clang only, -maltivec) will magicallyEric Christopher2016-03-241-0/+1
| | | | | | | | | include altivec.h has come and gone. Rationale: This causes modules, rewrite-includes, etc to be sad and people should just include altivec.h in their source. llvm-svn: 264235
OpenPOWER on IntegriCloud