summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParsePragma.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove trailing spaceFangrui Song2018-07-301-15/+15
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [NFC] Rename clang::AttributeList to clang::ParsedAttrErich Keane2018-07-131-8/+7
| | | | | | | Since The type no longer contains the 'next' item anymore, it isn't a list, so rename it to ParsedAttr to be more accurate. llvm-svn: 337005
* AttributeList de-listifying:Erich Keane2018-07-121-6/+6
| | | | | | | | | | | Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is switched to use a TinyPtrVector (and a ParsedAttributesView is created to have a non-allocating attributes list). DeclaratorChunk gets the later kind, Declarator/DeclSpec keep ParsedAttributes. Iterators are added to the ParsedAttribute types so that for-loops work. llvm-svn: 336945
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-13/+13
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Fix typos in clangAlexander Kornienko2018-04-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [ms] Parse #pragma optimize and ignore it behind its own flagHans Wennborg2018-03-201-0/+65
| | | | | | | | | This allows users to turn off warnings about this pragma specifically, while still receiving warnings about other ignored pragmas. Differential Revision: https://reviews.llvm.org/D44630 llvm-svn: 327959
* [OPENMP] Fix parsing of the directives with inner directives.Alexey Bataev2018-02-161-1/+13
| | | | | | | The parsing may lead to compiler hanging because of the incorrect processing of inner OpenMP pragmas. llvm-svn: 325369
* PR36307: Consume the #pragma options align annotation token afterAlex Lorenz2018-02-081-2/+4
| | | | | | | | | semantic analysis to prevent incorrect -Wpragma-pack warning for an included file rdar://37354951 llvm-svn: 324651
* Support `#pragma comment(lib, "name")` in the frontend for ELFSaleem Abdulrasool2018-02-071-2/+10
| | | | | | | | | | | | | This adds the frontend support required to support the use of the comment pragma to enable auto linking on ELFish targets. This is a generic ELF extension supported by LLVM. We need to change the handling for the "dependentlib" in order to accommodate the previously discussed encoding for the dependent library descriptor. Without the custom handling of the PCK_Lib directive, the -l prefixed option would be encoded into the resulting object (which is treated as a frontend error). llvm-svn: 324438
* Preserve unknown STDC pragma through preprocessorSteven Wu2018-01-051-0/+56
| | | | | | | | | | | | | | | | | | | Summary: #pragma STDC FP_CONTRACT handler is only registered in parser so we should keep the unknown STDC pragma through preprocessor and we also should not emit warning for unknown STDC pragma during preprocessor. rdar://problem/35724351 Reviewers: efriedma, rsmith, arphaman Reviewed By: efriedma Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41780 llvm-svn: 321909
* Place implictly declared functions at block scopeMomchil Velikov2017-08-101-1/+2
| | | | | | | | | | | | Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The second recommit (r309106) was reverted because the "non-default #pragma pack value chages the alignment of struct or union members in the included file" warning proved to be too aggressive for external projects like Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit makes the problematic warning a non-default one, and gives it the -Wpragma-pack-suspicious-include warning option. The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309386
* Revert r309106 "Recommit r308327 2nd time: Add a warning for missing"Hans Wennborg2017-07-261-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The warning fires on non-suspicious code in Chromium. Reverting until a solution is figured out. > Recommit r308327 2nd time: Add a warning for missing > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files > > The first recommit (r308441) caused a "non-default #pragma pack value might > change the alignment of struct or union members in the included file" warning > in LLVM itself. This recommit tweaks the added warning to avoid warnings for > #includes that don't have any records that are affected by the non-default > alignment. This tweak avoids the previously emitted warning in LLVM. > > Original message: > > This commit adds a new -Wpragma-pack warning. It warns in the following cases: > > - When a translation unit is missing terminating #pragma pack (pop) directives. > - When entering an included file if the current alignment value as determined > by '#pragma pack' directives is different from the default alignment value. > - When leaving an included file that changed the state of the current alignment > value. > > rdar://10184173 > > Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309186
* Recommit r308327 2nd time: Add a warning for missingAlex Lorenz2017-07-261-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309106
* Revert r308441 "Recommit r308327: Add a warning for missing '#pragma pack ↵Hans Wennborg2017-07-191-7/+2
| | | | | | | | | | | | | | | | | | | | | (pop)' and suspicious uses of '#pragma pack' in included files" This seems to have broken the sanitizer-x86_64-linux buildbot. Reverting until it's fixed, especially since this landed just before the 5.0 branch. > This commit adds a new -Wpragma-pack warning. It warns in the following cases: > > - When a translation unit is missing terminating #pragma pack (pop) directives. > - When entering an included file if the current alignment value as determined > by '#pragma pack' directives is different from the default alignment value. > - When leaving an included file that changed the state of the current alignment > value. > > rdar://10184173 > > Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308455
* Recommit r308327: Add a warning for missing '#pragma pack (pop)'Alex Lorenz2017-07-191-2/+7
| | | | | | | | | | | | | | | | | | and suspicious uses of '#pragma pack' in included files This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308441
* Revert r308327Alex Lorenz2017-07-181-7/+2
| | | | | | I forgot to test clang-tools-extra which is now failing. llvm-svn: 308328
* Add a warning for missing '#pragma pack (pop)' and suspicious usesAlex Lorenz2017-07-181-2/+7
| | | | | | | | | | | | | | | | | | of '#pragma pack' in included files This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308327
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+60
| | | | | | | | | | | | | | | This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
* Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith2017-05-181-22/+22
| | | | | | | | | | We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+534
| | | | | | | | | | | | | | | | | This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
* Revert r300539 - Add #pragma clang attributeAlex Lorenz2017-04-181-535/+0
| | | | | | | Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
* Fix one more 'not all control paths return a value' MSVC warningAlex Lorenz2017-04-181-0/+2
| | | | | | The warning was caused by r300539. llvm-svn: 300542
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+533
| | | | | | | | | | | | | | The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300539
* Add #pragma clang fpAdam Nemet2017-04-041-1/+150
| | | | | | | | | | | | | | | | | | | | | | | | | This adds the new pragma and the first variant, contract(on/off/fast). The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be placed at the beginning of a compound statement or at file scope. Similarly to STDC FP_CONTRACT there is no need to use attributes. First an annotate token is inserted with the parsed details of the pragma. Then the annotate token is parsed in the proper contexts and the Sema is updated with the corresponding FPOptions using the shared ActOn function with STDC FP_CONTRACT. After this the FPOptions from the Sema is propagated into the AST expression nodes. There is no change here. I was going to add a 'default' option besides 'on/off/fast' similar to STDC FP_CONTRACT but then decided against it. I think that we'd have to make option uppercase then to avoid using 'default' the keyword. Also because of the scoped activation of pragma I am not sure there is really a need a for this. Differential Revision: https://reviews.llvm.org/D31276 llvm-svn: 299470
* Publish RAIIObjectsForParser.h for external usage.Vassil Vassilev2017-03-231-1/+1
| | | | | | | | | Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
* [OpenCL] Re-enable supported core extensions based on opencl version when ↵Konstantin Zhuravlyov2017-01-061-2/+4
| | | | | | | | disabling all extensions using pragma Differential Revision: https://reviews.llvm.org/D28257 llvm-svn: 291243
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-181-42/+55
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-161-55/+42
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-161-42/+55
| | | | | | | | | | | | | | | | | | 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
* [CUDA] Add #pragma clang force_cuda_host_device_{begin,end} pragmas.Justin Lebar2016-10-081-0/+44
| | | | | | | | | | | | | | | | | 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
* Parsing MS pragma intrinsicReid Kleckner2016-09-071-0/+60
| | | | | | | | | | | | | | | Parse pragma intrinsic, display warning if the function isn't a builtin function in clang and suggest including intrin.h. Patch by Albert Gutowski! Reviewers: aaron.ballman, rnk Subscribers: aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D23944 llvm-svn: 280825
* Add loop pragma for Loop DistributionAdam Nemet2016-06-141-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [OpenCL] Add supported OpenCL extensions to target info.Yaxun Liu2016-05-161-2/+12
| | | | | | | | | | 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
* Revert "[OpenCL] Add supported OpenCL extensions to target info."Yaxun Liu2016-05-131-12/+2
| | | | | | | | | 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-131-2/+12
| | | | | | | | 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
* [MS] Make #pragma pack use PragmaStack<> class.Denis Zobnin2016-04-291-20/+17
| | | | | | | | | | | | | | | Make implementation of #pragma pack consistent with other "stack" pragmas. Use PragmaStack<> class instead of old representation of internal stack. Don't change compiler's behavior. TODO: 1. Introduce diagnostics on popping named slots from pragma stacks. Reviewer: rnk Differential revision: http://reviews.llvm.org/D19727 llvm-svn: 268085
* Recommit "[MS] Improved implementation of stack pragmas (vtordisp, *_seg)"Denis Zobnin2016-04-291-9/+9
| | | | | | | | | | | | | | | | | | | | | | Slightly updated version, double-checked build and tests. Improve implementation of MS pragmas that use stack + compatibility fixes. This patch: 1. Changes implementation of #pragma vtordisp to use PragmaStack class that other stack pragmas use; 2. Fixes "#pragma vtordisp()" behavior - it shouldn't affect the stack; 3. Supports "save-restore" of pragma stacks on enter / exit a C++ method body, as MSVC does. TODO: 1. Change implementation of #pragma pack to use the same approach; 2. Introduce diagnostics on popping named stack slots, as MSVC does. Reviewers: rnk, thakis Differential revision: http://reviews.llvm.org/D19361 llvm-svn: 268029
* Revert "[MS] Improved implementation of MS stack pragmas (vtordisp, *_seg)"Denis Zobnin2016-04-281-9/+9
| | | | | | This reverts commit r267866. llvm-svn: 267870
* [MS] Improved implementation of MS stack pragmas (vtordisp, *_seg)Denis Zobnin2016-04-281-9/+9
| | | | | | | | | | | Rework implementation of several MS pragmas that use internal stack: vtordisp, {bss|code|const|data}_seg. This patch: 1. Makes #pragma vtordisp use PragmaStack class as *_seg pragmas do; 2. Fixes "#pragma vtordisp()" behavior: it shouldn't affect stack; 3. Saves/restores the stacks on enter/exit a C++ method body. llvm-svn: 267866
* [Parse] Reuse OptionUnroll rather than matching it again. NFCAdam Nemet2016-04-191-2/+1
| | | | llvm-svn: 266829
* [Parse] Use StringSwitch to improve readability. NFCAdam Nemet2016-04-191-4/+8
| | | | | | | | A subsequent patch will propose a "distribute" loop hint. Similarly to unroll, this does not have a "assume_safety" argument either so this condition will get more complex. llvm-svn: 266827
* Serialize `pragma ms_struct` state.Nico Weber2016-03-021-6/+5
| | | | | | | | | | | pragma ms_struct has an effect on struct decls, and the effect is serialized correctly already. But the "is ms_struct currently on" state wasn't before this change. This uses the same approach as `pragma clang optimize`: When writing a module, the state isn't serialized, only when writing a pch file. llvm-svn: 262539
* Serialize `#pragma detect_mismatch`.Nico Weber2016-03-021-4/+4
| | | | | | | This is like r262493, but for pragma detect_mismatch instead of pragma comment. The two pragmas have similar behavior, so use the same approach for both. llvm-svn: 262506
* Serialize `#pragma comment`.Nico Weber2016-03-021-11/+12
| | | | | | | | | | | | | | `#pragma comment` was handled by Sema calling a function on ASTConsumer, and CodeGen then implementing this function and writing things to its output. Instead, introduce a PragmaCommentDecl AST node and hang one off the TranslationUnitDecl for every `#pragma comment` line, and then use the regular serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's eagerly deserialized.) http://reviews.llvm.org/D17799 llvm-svn: 262493
* Simplify EnterTokenStream API to make it more robust for memory managementDavid Blaikie2016-02-091-82/+56
| | | | | | | | | | | | | | | While this won't help fix things like the bug that r260219 addressed, it seems like good tidy up to have anyway. (it might be nice if "makeArrayRef" always produced a MutableArrayRef & let it decay to an ArrayRef when needed - then I'd use that for the MutableArrayRefs in this patch) If we had std::dynarray I'd use that instead of unique_ptr+size_t, ideally (but then it'd have to be threaded down through the Preprocessor all the way - no idea how painful that would be) llvm-svn: 260246
* Improve AST dumping:Richard Smith2016-01-121-0/+8
| | | | | | | | 1) When dumping a declaration that declares a name for a type, also dump the named type. 2) Add a #pragma clang __debug dump X, that dumps the lookup results for X in the current context. llvm-svn: 257529
* Put global classes into the appropriate namespace.Benjamin Kramer2015-10-281-0/+4
| | | | | | | Most of the cases belong into an anonymous namespace. No functionality change intended. llvm-svn: 251514
* Parse and ignore #pragma runtime_checks in MS extensions mode (PR25138)Hans Wennborg2015-10-121-0/+8
| | | | | | We already silently ignore the /RTC, which controls the same functionality. llvm-svn: 250099
* Add new llvm.loop.unroll.enable metadata for use with "#pragma unroll".Mark Heffernan2015-08-101-9/+12
| | | | | | | | | | | | | | | | | | | | | | This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs the optimizer to unroll a loop fully if the trip count is known at compile time, and unroll partially if the trip count is not known at compile time. This differs from "llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not known at compile time With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than "llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all". The motivating example for this change was some internal code with a loop marked with "#pragma unroll" which only sometimes had a compile-time trip count depending on template magic. When the trip count was a compile-time constant, everything works as expected and the loop is fully unrolled. However, when the trip count was not a compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!). Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable from a performance perspective. llvm-svn: 244467
OpenPOWER on IntegriCloud