summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaAttr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move vtordisp mode from Attr class to LangOptions.h, NFCReid Kleckner2019-11-221-4/+4
| | | | | This removes one of the two uses of Attr.h in DeclCXX.h, reducing the need to include Attr.h as widely. LangOptions is already very popular.
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-151-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-131-5/+10
| | | | | | | | | | | | In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 llvm-svn: 371875
* Reland [LifetimeAnalysis] Support more STL idioms (template forward ↵Matthias Gehre2019-09-061-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declaration and DependentNameType) Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics. Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 371182
* Revert "[LifetimeAnalysis] Support more STL idioms (template forward ↵Richard Smith2019-08-221-4/+7
| | | | | | | | | | declaration and DependentNameType)" This reverts commit r369591, because it causes the formerly-reliable -Wreturn-stack-address warning to start issuing false positives. Testcase provided on the commit thread. llvm-svn: 369677
* [LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre2019-08-211-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DependentNameType) Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 369591
* gsl::Owner/gsl::Pointer: Add implicit annotations for some std typesMatthias Gehre2019-08-071-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions some types explicitly. Generally, all containers and their iterators are covered. For iterators, we cover both the case that they are defined as an nested class or as an typedef/using. I have started to test this implementation against some real standard library implementations, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5, libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0, libstdc++ 8.3.0 and libstdc++ 9.1.0. The tests are currently here https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp I think due to their dependency on a standard library, they are not a good fit for clang/test/. Where else could I put them? Reviewers: gribozavr, xazax.hun Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64448 llvm-svn: 368147
* clang-cl: Port cl.exe's C4659 to clang-clNico Weber2019-07-091-3/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D64349 llvm-svn: 365411
* Add a priority field to availability attributes to prioritize explicitAlex Lorenz2019-01-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attributes from declaration over attributes from '#pragma clang attribute' Before this commit users had an issue when using #pragma clang attribute with availability attributes: The explicit attribute that's specified next to the declaration is not guaranteed to be preferred over the attribute specified in the pragma. This commit fixes this by introducing a priority field to the availability attribute to control how they're merged. Attributes with higher priority are applied over attributes with lower priority for the same platform. The implicitly inferred attributes are given the lower priority. This ensures that: - explicit attributes are preferred over all other attributes. - implicitly inferred attributes that are inferred from an explicit attribute are discarded if there's an explicit attribute or an attribute specified using a #pragma for the same platform. - implicitly inferred attributes that are inferred from an attribute in the #pragma are not used if there's an explicit, explicit #pragma, or an implicit attribute inferred from an explicit attribute for the declaration. This is the resulting ranking: `platform availability > platform availability from pragma > inferred availability > inferred availability from pragma` rdar://46390243 Differential Revision: https://reviews.llvm.org/D56892 llvm-svn: 352084
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Add support for namespaces on #pragma clang attributeErik Pilkington2018-12-201-11/+29
| | | | | | | | | | | | | | | | Namespaces are introduced by adding an "identifier." before a push/pop directive. Pop directives with namespaces can only pop a attribute group that was pushed with the same namespace. Push and pop directives that don't opt into namespaces have the same semantics. This is necessary to prevent a pitfall of using multiple #pragma clang attribute directives spread out in a large file, particularly when macros are involved. It isn't easy to see which pop corripsonds to which push, so its easy to inadvertently pop the wrong group. Differential revision: https://reviews.llvm.org/D55628 llvm-svn: 349845
* Revert "Revert "Support for groups of attributes in #pragma clang attribute""Erik Pilkington2018-10-291-28/+44
| | | | | | | This reverts commit r345487, which reverted r345486. I think the crashes were caused by an OOM on the builder, trying again to confirm... llvm-svn: 345517
* Revert "Support for groups of attributes in #pragma clang attribute"Erik Pilkington2018-10-291-44/+28
| | | | | | | | | This reverts commit r345486. Looks like it causes some old versions of GCC to crash, I'll see if I can work around it and recommit... llvm-svn: 345487
* Support for groups of attributes in #pragma clang attributeErik Pilkington2018-10-291-28/+44
| | | | | | | | | | | | | | | | | | This commit enables pushing an empty #pragma clang attribute push, then adding multiple attributes to it, then popping them all with #pragma clang attribute pop, just like #pragma clang diagnostic. We still support the current way of adding these, #pragma clang attribute push(__attribute__((...))), by treating it like a combined push/attribute. This is needed to create macros like: DO_SOMETHING_BEGIN(attr1, attr2, attr3) // ... DO_SOMETHING_END rdar://45496947 Differential revision: https://reviews.llvm.org/D53621 llvm-svn: 345486
* We have in place support for parsing #pragma FENV_ACCESS, but that Kevin P. Neal2018-08-141-0/+12
| | | | | | | | | | | | | information is then discarded with a warning to the user that we don't support it. This patch gets us one step closer by getting the info down into the AST in most cases. Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D49865 llvm-svn: 339693
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-2/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* Remove trailing spaceFangrui Song2018-07-301-2/+2
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [NFC] Rename clang::AttributeList to clang::ParsedAttrErich Keane2018-07-131-2/+2
| | | | | | | 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-3/+4
| | | | | | | | | | | 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
* Test commit; please ignore.George Burgess IV2018-05-261-1/+1
| | | | llvm-svn: 333333
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* -Wpragma-pack: add an additional note and fixit when warningAlex Lorenz2017-07-311-1/+15
| | | | | | | | | about unterminated push directives that are followed by a reset ('#pragma pack()') This has been suggested by Hans Wennborg. llvm-svn: 309559
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-281-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#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-54/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | '#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-36/+1
| | | | | | | | | | | | | | | | | | | | | (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-1/+36
| | | | | | | | | | | | | | | | | | 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-36/+1
| | | | | | 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-1/+36
| | | | | | | | | | | | | | | | | | 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/+30
| | | | | | | | | | | | | | | 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
* The SubjectMatchRule enum should not be used as a DenseMap key to avoidAlex Lorenz2017-04-181-12/+14
| | | | | | | | | | | UBSAN 'invalid value' failures The commit r300556 introduced a UBSAN issue that was caught by http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap. The DenseMap failed to create an empty/tombstone value as the empty/tombstone values for the SubjectMatchRule enum were not valid enum constants. llvm-svn: 300591
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+211
| | | | | | | | | | | | | | | | | 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-211/+0
| | | | | | | Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+211
| | | | | | | | | | | | | | 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-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules][PCH] Serialize #pragma packAlex Lorenz2017-03-311-0/+1
| | | | | | | | | | | This patch serializes the state of #pragma pack. It preserves the state of the pragma from a PCH/from modules in a file that uses that PCH/those modules. rdar://21359084 Differential Revision: https://reviews.llvm.org/D31241 llvm-svn: 299226
* Use FPContractModeKind universallyAdam Nemet2017-03-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. --- This is a recommit of r299027 with an adjustment to the test CodeGenCUDA/fp-contract.cu. The test assumed that even though -ffp-contract=on is passed FE-based folding of FMA won't happen. This is obviously wrong since the user is asking for this explicitly with the option. CUDA is different that -ffp-contract=fast is on by default. The test used to "work" because contract=fast and contract=on were maintained separately and we didn't fold in the FE because contract=fast was on due to the target-default. This patch consolidates the contract=on/fast/off state into a ternary state hence the change in behavior. --- Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299033
* Revert "Use FPContractModeKind universally"Adam Nemet2017-03-291-6/+3
| | | | | | | | This reverts commit r299027. It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu llvm-svn: 299029
* Use FPContractModeKind universallyAdam Nemet2017-03-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299027
* Encapsulate FPOptions and use it consistentlyAdam Nemet2017-03-271-3/+3
| | | | | | | | | | | | | | | | | | Sema holds the current FPOptions which is adjusted by 'pragma STDC FP_CONTRACT'. This then gets propagated into expression nodes as they are built. This encapsulates FPOptions so that this propagation happens opaquely rather than directly with the fp_contractable on/off bit. This allows controlled transitioning of fp_contractable to a ternary value (off, on, fast). It will also allow adding more fast-math flags later. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31166 llvm-svn: 298877
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+1
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* Use ranges to concisely express iterationDavid Majnemer2016-06-231-2/+3
| | | | | | | No functional change is intended, this should just clean things up a little. llvm-svn: 273522
* [NFC] Initialize a variable to make buildbot green.Denis Zobnin2016-04-291-1/+1
| | | | | | | | | In r268085 "[MS] Make #pragma pack use PragmaStack<> class." there was an uninitialized variable 'Alignment', which caused the following failure: http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/1758 Zero-initialize the variable to fix this failure. llvm-svn: 268129
* [MS] Make #pragma pack use PragmaStack<> class.Denis Zobnin2016-04-291-152/+37
| | | | | | | | | | | | | | | 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-24/+30
| | | | | | | | | | | | | | | | | | | | | | 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-8/+24
| | | | | | This reverts commit r267866. llvm-svn: 267870
* [MS] Improved implementation of MS stack pragmas (vtordisp, *_seg)Denis Zobnin2016-04-281-24/+8
| | | | | | | | | | | 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
* Implement support for [[maybe_unused]] in C++1z that is based off existing ↵Aaron Ballman2016-03-091-1/+2
| | | | | | support for unused, and treat it as an extension pre-C++1z. This also means extending the existing unused attribute so that it can be placed on an enum and enumerator, in addition to the other subjects. llvm-svn: 263025
OpenPOWER on IntegriCloud