Commit Graph

2918 Commits

Author SHA1 Message Date
Volodymyr Sapsai fa4a0f1d31 [modules] Add a flag for TagDecl if it was a definition demoted to a declaration.
For redeclaration chains we maintain an invariant of having only a
single definition in the chain. In a single translation unit we make
sure not to create duplicates. But modules are separate translation
units and they can contain definitions for the same symbol
independently. When we load such modules together, we need to demote
duplicate definitions to keep the AST invariants.

Some AST clients are interested in distinguishing
declaration-that-was-demoted-from-definition and
declaration-that-was-never-a-definition. For that purpose introducing
`IsThisDeclarationADemotedDefinition`. No functional change intended.

rdar://84677782

Differential Revision: https://reviews.llvm.org/D118855
2022-02-14 16:04:40 -08:00
Alex Lorenz 00cd6c0420 [Preprocessor] Reduce the memory overhead of `#define` directives (Recommit)
Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.

The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.

For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.

The recommit fixes the LLDB build failure.

Differential Revision: https://reviews.llvm.org/D117348
2022-02-14 09:27:44 -08:00
Alex Lorenz 3f05192c4c Revert "[Preprocessor] Reduce the memory overhead of `#define` directives"
This reverts commit 0d9b91524e.

This change broke LLDB's build. I will need to recommit after fixing LLDB.
2022-02-11 15:53:16 -08:00
Alex Lorenz 0d9b91524e [Preprocessor] Reduce the memory overhead of `#define` directives
Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.

The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.

For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.

Differential Revision: https://reviews.llvm.org/D117348
2022-02-11 15:01:10 -08:00
Chuanqi Xu 8c930cef0e [NFC] [Modules] Refactor ODR checking for default template argument in
ASTReader

This is a cleanup to reduce the lines of code to handle default template
argument in ASTReader.

Reviewed By: urnathan

Differential Revision: https://reviews.llvm.org/D118437
2022-02-10 10:10:10 +08:00
Chuanqi Xu f85ee6d56a [NFC] [AST] Move isSameEntity into ASTContext
Currently we are trying to implement the semantics of C++ Modules. A big
challenge would be the ODR checking. Previously we did this in
ASTReader, it would handle the cases like:
```
module;
export module a_module;
import another_module; //  check the ODR consistency here
```
or
```
export module m;
import a_module;
import another_module; // check the ODR consistency here
```

However, it wouldn't handle the case:
```
import another_module; // When we check ODR here, everything looks fine.
```

In the case, the read process is ended. But we need to check the ODR
still. To reuse the facility we do in ASTReader, this patch moves the
corresponding codes into ASTContext. This should be good since there
were facilities like `hasSameTemplateName` and `hasSameType`.

Although the patch is a little bit big, all of the change should be
trivial.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D118223
2022-01-27 10:30:50 +08:00
Jan Svoboda f720272330 [clang][lex] Include tracking: simplify and move to preprocessor
This patch replaces the exact include count of each file in `HeaderFileInfo` with a set of included files in `Preprocessor`.

The number of includes isn't a property of a header file but rather a preprocessor state. The exact number of includes is not used anywhere except statistic tracking.

Reviewed By: vsapsai

Differential Revision: https://reviews.llvm.org/D114095
2022-01-26 15:56:26 +01:00
David Blaikie baa9b7c3c8 unique_ptrify the ModuleManager's VisitState linked list 2022-01-19 09:57:46 -08:00
Haojian Wu ab3f100bec Reland (2) "[AST] Add RParen loc for decltype AutoTypeloc.""
The patch was reverted because it caused a crash during PCH build -- we
missed to update the RParenLoc in TreeTransform<Derived>::TransformAutoType.

This relands 55d96ac and 37ec65e with a test and fix.
2022-01-17 11:33:11 +01:00
Florian Hahn eadb4cfeef
Revert (2) "[AST] Add RParen loc for decltype AutoTypeloc."
This reverts commit 41fbdfa4d5.

The commit breaks stage 2 builds with debug info, e.g.
https://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/5088/console

Clang crashes with the following assertion when building
llvm-project/llvm/lib/Support/Timer.cpp

/usr/local/bin/sccache /Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/host-compiler/bin/clang++  -DGTEST_HAS_RTTI=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/lib/Support -Iinclude -I/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/include -fno-stack-protector -fno-common -Wno-profile-instr-unprofiled -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -fmodules -fmodules-cache-path=/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/clang-build/Build/module.cache -fcxx-modules -Xclang -fmodules-local-submodule-visibility -gmodules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -flto=thin  -O2 -g -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk   -std=c++14  -fno-exceptions -fno-rtti -MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o -MF lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o.d -o lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o -c /Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/lib/Support/Timer.cpp
Assertion failed: (((getOffset()+Offset) & MacroIDBit) == 0 && "offset overflow"), function getLocWithOffset, file /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/clang/include/clang/Basic/SourceLocation.h, line 135.
2022-01-12 10:09:37 +00:00
Haojian Wu 41fbdfa4d5 Reland "[AST] Add RParen loc for decltype AutoTypeloc."
Reland 55d96ac and 37ec65e with a clang-tidy fix.
2022-01-11 12:06:18 +01:00
Jennifer Yu 140a6b1e5c [clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause
Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:58:56 -08:00
Haojian Wu c2293bc17d Revert "[AST] Add RParen loc for decltype AutoTypeloc."
This breaks a clang-tidy check, needs to investigate and fix. Revert
them to bring the buildbot back.

This reverts commit 55d96ac3dc and
37ec65e1d7
2022-01-10 15:18:41 +01:00
Haojian Wu 55d96ac3dc [AST] Add RParen loc for decltype AutoTypeloc.
Differential Revision: https://reviews.llvm.org/D116919
2022-01-10 12:46:27 +01:00
Haojian Wu 4a4b8e4f99 [AST] Add more source information for DecltypeTypeLoc.
Adds the paren source location, and removes the hack in clangd.

Differential Revision: https://reviews.llvm.org/D116793
2022-01-10 09:34:18 +01:00
Kazu Hirata 40446663c7 [clang] Use true/false instead of 1/0 (NFC)
Identified with modernize-use-bool-literals.
2022-01-09 00:19:47 -08:00
Kazu Hirata d1b127b5b7 [clang] Remove unused forward declarations (NFC) 2022-01-08 11:56:40 -08:00
Kazu Hirata 6c335b1a45 [clang] Remove unused "using" (NFC)
Identified by misc-unused-using-decls.
2021-12-27 20:48:21 -08:00
Shilei Tian c7a589a2c4 [Clang][OpenMP] Add the support for atomic compare in parser
This patch adds the support for `atomic compare` in parser. The support
in Sema and CodeGen will come soon. For now, it simply eimits an error when it
is encountered.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D115561
2021-12-24 08:16:51 -05:00
Sam McCall af27466c50 Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit cc56c66f27.
Fixed a bad assertion, the target of a UsingShadowDecl must not have
*local* qualifiers, but it can be a typedef whose underlying type is qualified.
2021-12-20 18:03:15 +01:00
Sam McCall cc56c66f27 Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit e1600db19d.

Breaks sanitizer tests, at least on windows:
https://lab.llvm.org/buildbot/#/builders/127/builds/21592/steps/4/logs/stdio
2021-12-20 17:53:56 +01:00
Sam McCall e1600db19d [AST] Add UsingType: a sugar type for types found via UsingDecl
Currently there's no way to find the UsingDecl that a typeloc found its
underlying type through. Compare to DeclRefExpr::getFoundDecl().

Design decisions:
- a sugar type, as there are many contexts this type of use may appear in
- UsingType is a leaf like TypedefType, the underlying type has no TypeLoc
- not unified with UnresolvedUsingType: a single name is appealing,
  but being sometimes-sugar is often fiddly.
- not unified with TypedefType: the UsingShadowDecl is not a TypedefNameDecl or
  even a TypeDecl, and users think of these differently.
- does not cover other rarer aliases like objc @compatibility_alias,
  in order to be have a concrete API that's easy to understand.
- implicitly desugared by the hasDeclaration ASTMatcher, to avoid
  breaking existing patterns and following the precedent of ElaboratedType.

Scope:
- This does not cover types associated with template names introduced by
  using declarations. A future patch should introduce a sugar TemplateName
  variant for this. (CTAD deduced types fall under this)
- There are enough AST matchers to fix the in-tree clang-tidy tests and
  probably any other matchers, though more may be useful later.

Caveats:
- This changes a fairly common pattern in the AST people may depend on matching.
  Previously, typeLoc(loc(recordType())) matched whether a struct was
  referred to by its original scope or introduced via using-decl.
  Now, the using-decl case is not matched, and needs a separate matcher.
  This is similar to the case of typedefs but nevertheless both adds
  complexity and breaks existing code.

Differential Revision: https://reviews.llvm.org/D114251
2021-12-20 17:15:38 +01:00
Chuanqi Xu e166755a69 [C++20] [Modules] [Concepts] Recognize same concepts more precisely in Serialization
The compiler would judge two concepts is same by their addresses.
However, when we use modules, the addresses wouldn't be the same all the
time since one is parsed in their TU and another is imported in another
TU.
This patch fixes this by using isSameEntity to judge the two concepts.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D114769
2021-12-08 15:00:04 +08:00
Aaron Ballman 6c75ab5f66 Introduce _BitInt, deprecate _ExtInt
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:

* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.

I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:52:01 -05:00
Alexey Bataev 80256605f8 [OpenMP] support depend clause for taskwait directive, by Deepak
Eachempati.

This patch adds clang (parsing, sema, serialization, codegen) support for the 'depend' clause on the 'taskwait' directive.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D113540
2021-11-19 06:30:17 -08:00
Ilya Kuteev 8a4fcfc242 Remove non-affecting module maps from PCM files.
Problem:
PCM file includes references to all module maps used in compilation which created PCM. This problem leads to PCM-rebuilds in distributed compilations as some module maps could be missing in isolated compilation. (For example in our distributed build system we create a temp folder for every compilation with only modules and headers that are needed for that particular command).

Solution:
Add only affecting module map files to a PCM-file.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D106876
2021-11-18 11:18:26 +01:00
Kazu Hirata 74115602e8 [clang] Use range-based for loops with llvm::reverse (NFC) 2021-11-17 19:40:48 -08:00
Nathan Ridge 7a8c7946fc [clang] Allocate 2 bits to store the constexpr specifier kind when serializing
Now that consteval and constinit are possible values, 1 bit
is no longer enough.

Fixes https://github.com/clangd/clangd/issues/887

Differential Revision: https://reviews.llvm.org/D111971
2021-11-17 16:56:46 -05:00
David Pagan b0de656bdf Initial parsing/sema for 'align' clause
Added basic parsing/sema/serialization support for 'align' clause for use with
'allocate' directive.
2021-11-09 07:34:18 -05:00
Volodymyr Sapsai 7ad693a322 [modules] Update visibility for merged ObjCProtocolDecl definitions.
Merge definition visibility the same way we do for other decls. Without
the fix the added test emits `-Wobjc-method-access` as it cannot find a
visible protocol. Make this warning `-Werror` so the test would fail
when protocol visibility regresses.

rdar://83600696

Differential Revision: https://reviews.llvm.org/D111860
2021-11-08 13:54:00 -08:00
Mike Rice 4eac7bcf1a [OpenMP] Add parsing/sema/serialization for 'bind' clause.
Differential Revision: https://reviews.llvm.org/D113154
2021-11-04 14:40:30 -07:00
Volodymyr Sapsai 0a35cc40b8 [clang][objc] Speed up populating the global method pool from modules.
For each selector encountered in the source code, we need to load
selectors from the imported modules and check that we are calling a
selector with compatible types.

At the moment, for each module we are storing methods declared in the
headers belonging to this module and methods from the transitive closure
of imported modules. When a module is imported by a few other modules,
methods from the shared module are duplicated in each importer. As the
result, we can end up with lots of identical methods that we try to add
to the global method pool. Doing this duplicate work is useless and
relatively expensive.

Avoid processing duplicate methods by storing in each module only its
own methods and not storing methods from dependencies. Collect methods
from dependencies by walking the graph of module dependencies.

The issue was discovered and reported by Richard Howell. He has done the
hard work for this fix as he has investigated and provided a detailed
explanation of the performance problem.

Differential Revision: https://reviews.llvm.org/D110123
2021-11-03 17:11:14 -07:00
Mike Rice 6f9c25167d [OpenMP] Initial parsing/sema for the 'omp loop' construct
Adds basic parsing/sema/serialization support for the #pragma omp loop
directive.

Differential Revision: https://reviews.llvm.org/D112499
2021-10-28 08:26:43 -07:00
Nico Weber c7aaa2efef [clang] Add range accessor for ObjCAtTryStmt catch_stmts and use it
No behavior change.

Differential Revision: https://reviews.llvm.org/D112543
2021-10-27 08:57:05 -04:00
Kazu Hirata 16ceb44e62 [clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC) 2021-10-25 09:14:45 -07:00
Volodymyr Sapsai 048d2c76ef [modules] Update visibility for merged ObjCInterfaceDecl definitions.
We keep using the first encountered definition and need to take into
account visibility from subsequent definitions. For example, if the
first definition is hidden and the second is visible, we need to make
the first one visible too.

rdar://82263843

Differential Revision: https://reviews.llvm.org/D110453
2021-10-21 15:06:39 -07:00
Volodymyr Sapsai c5931267db [modules] While merging ObjCInterfaceDecl definitions, merge them as decl contexts too.
While working on https://reviews.llvm.org/D110280 I've tried to merge
decl contexts as it seems to be correct and matching our handling of
decl contexts from different modules. It's not required for the fix in
https://reviews.llvm.org/D110280 but it revealed a missing diagnostic,
so separating this change into a separate commit.

Renamed some variables to distinguish diagnostic like "declaration of
'x' does not match" for different cases.

Differential Revision: https://reviews.llvm.org/D110287
2021-10-20 18:48:29 -07:00
Kazu Hirata d245f2e859 [clang] Use llvm::erase_if (NFC) 2021-10-17 13:50:29 -07:00
Kazu Hirata e567f37dab [clang] Use llvm::is_contained (NFC) 2021-10-13 20:41:55 -07:00
Jan Svoboda 28fa77feeb [clang][modules] Avoid using uninitialized SourceLocation
At this point, `F.ImportLoc` has not been initialized by the `ASTReader` yet and using it leads to an assertion failure.

Introduced in 638c673a8c and 4445135109.
2021-10-13 11:24:01 +02:00
Jan Svoboda 6a1f50b84a [clang][deps] Prune unused header search paths
To reduce the number of explicit builds of a single module, we can try to squash multiple occurrences of the module with different command-lines (and context hashes) by removing benign command-line options. The greatest contributors to benign differences between command-lines are the header search paths.

In this patch, the lookup cache in `HeaderSearch` is used to identify paths that were actually used when implicitly building the module during scanning. This information is serialized into the unhashed control block of the implicitly-built PCM. The dependency scanner then loads this and may use it to prune the header search paths before computing the context hash of the module and generating the command-line.

We could also prune the header search paths when serializing `HeaderSearchOptions` into the PCM. That way, we could do it only once instead of every load of the PCM file by dependency scanner. However, that would result in a PCM file whose contents don't produce the same context hash as the original build, which is probably highly surprising.

There is an alternative approach to storing extra information into the PCM: wire up preprocessor callbacks to capture the used header search paths on-the-fly during preprocessing of modularized headers (similar to what we currently do for the main source file and textual headers). Right now, that's not compatible with the fact that we do an actual implicit build producing PCM files during dependency scanning. The second run of dependency scanner loads the PCM from the first run, skipping the preprocessing altogether, which would result in different results between runs. We can revisit this approach when we stop building implicitly during dependency scanning.

Depends on D102923.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102488
2021-10-12 12:39:23 +02:00
Jan Svoboda 638c673a8c [clang][modules] NFC: Propagate import `SourceLocation` into `HeaderSearch::lookupModule`
This patch propagates the import `SourceLocation` into `HeaderSearch::lookupModule`. This enables remarks on search path usage (implemented in D102923) to point to the source code that initiated header search.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D111557
2021-10-12 09:31:51 +02:00
Volodymyr Sapsai 9fad9de5c0 [modules] Fix IRGen assertion on accessing ObjC ivar inside a method.
When have ObjCInterfaceDecl with the same name in 2 different modules,
hitting the assertion

> Assertion failed: (Index < RL->getFieldCount() && "Ivar is not inside record layout!"),
> function lookupFieldBitOffset, file llvm-project/clang/lib/AST/RecordLayoutBuilder.cpp, line 3434.

on accessing an ivar inside a method. The assertion happens because
ivar belongs to one module while its containing interface belongs to
another module and then we fail to find the ivar inside the containing
interface. We already keep a single ObjCInterfaceDecl definition in
redecleration chain and in this case containing interface was correct.
The issue is with ObjCIvarDecl. IVar decl for IRGen is taken from
ObjCIvarRefExpr that is created in `Sema::BuildIvarRefExpr` using ivar
decl returned from `Sema::LookupIvarInObjCMethod`. And ivar lookup
returns a wrong decl because basically we take the first ObjCIvarDecl
found in `ASTReader::FindExternalVisibleDeclsByName` (called by
`DeclContext::lookup`). And in `ASTReader.Lookups` lookup table for a
wrong module comes first because `ASTReader::finishPendingActions`
processes `PendingUpdateRecords` in reverse order and the first
encountered ObjCIvarDecl will end up the last in `ASTReader.Lookups`.

Fix by merging ObjCIvarDecl from different modules correctly and by
using a canonical one in IRGen.

rdar://82854574

Differential Revision: https://reviews.llvm.org/D110280
2021-10-07 17:09:31 -07:00
Michael Kruse 2130117f92 [Clang][OpenMP] Allow loop-transformations with template parameters.
Clang would reject

    #pragma omp for
    #pragma omp tile sizes(P)
    for (int i = 0; i < 128; ++i) {}

where P is a template parameter, but the loop itself is not
template-dependent. Because P context-dependent, the TransformedStmt
cannot be generated and therefore is nullptr (until the template is
instantiated by TreeTransform). The OMPForDirective would still expect
the a loop is the dependent context and trigger an error.

Fix by introducing a NumGeneratedLoops field to OMPLoopTransformation.
This is used to distinguish the case where no TransformedStmt will be
generated at all (e.g. #pragma omp unroll full) and template
instantiation is needed. In the latter case, delay resolving the
iteration space like when the for-loop itself is template-dependent
until the template instatiation.

A more radical solution would always delay the iteration space analysis
until template instantiation, but would also break many test cases.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D111124
2021-10-06 12:21:04 -05:00
Michael Kruse f37e8b0b83 [Clang][OpenMP] Infix OMPLoopTransformationDirective abstract class. NFC.
Insert OMPLoopTransformationDirective between OMPLoopBasedDirective and the loop transformations OMPTileDirective and OMPUnrollDirective. This simplifies handling of loop transformations not requiring distinguishing between OMPTileDirective and OMPUnrollDirective anymore.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D111119
2021-10-06 10:49:07 -05:00
Simon Pilgrim b9b90bb542 [clang] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)
As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.
2021-10-06 11:43:19 +01:00
Corentin Jabot 424733c12a Implement if consteval (P1938)
Modify the IfStmt node to suppoort constant evaluated expressions.

Add a new ExpressionEvaluationContext::ImmediateFunctionContext to
keep track of immediate function contexts.

This proved easier/better/probably more efficient than walking the AST
backward as it allows diagnosing nested if consteval statements.
2021-10-05 08:04:14 -04:00
alokmishra.besu 000875c127 OpenMP 5.0 metadirective
This patch supports OpenMP 5.0 metadirective features.
It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind.

A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h

Currently this function return the index of the when clause with the highest score from the ones applicable in the Context.
But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 13:40:44 -05:00
Nico Weber 31cca21565 Revert "OpenMP 5.0 metadirective"
This reverts commit c7d7b98e52.
Breaks tests on macOS, see comment on https://reviews.llvm.org/D91944
2021-09-18 09:10:37 -04:00
alokmishra.besu 347f3c186d OpenMP 5.0 metadirective
This patch supports OpenMP 5.0 metadirective features.
It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind.

A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h

Currently this function return the index of the when clause with the highest score from the ones applicable in the Context.
But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D91944
2021-09-17 16:30:06 -05:00