1400 Commits

Author SHA1 Message Date
Sean Perry
97189492a1
The real option name and not the alias used is displayed in msgs when using a config file (#107613)
An example of this is the -mpure-code option. Without a config file
being used, an error message will print `-mpure-code`. But if a config
file is used, the error message will print `-mexecute-only`.
2024-09-25 10:51:55 -04:00
Prabhuk
fb78495376
Reland "[Driver] Add toolchain for X86_64 UEFI target" (#109364)
Reverts llvm/llvm-project#109340

Addressing the failed MAC Clang Driver test as part of this reland.
2024-09-20 11:16:36 -07:00
Alex Rønne Petersen
72a218056d
[llvm][Triple] Add Environment members and parsing for glibc/musl parity. (#107664)
This adds support for:

* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)

As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.

I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.

Note: I don't have commit access.
2024-09-20 08:53:03 +08:00
Prabhuk
d2df2e41ca
Revert "[Driver] Add toolchain for X86_64 UEFI target" (#109340)
Reverts llvm/llvm-project#76838

Appears to be causing failures in MAC builders. First reverting the
patch and will investigate after.
2024-09-19 15:28:07 -07:00
Prabhuk
d1335fb864
[Driver] Add toolchain for X86_64 UEFI target (#76838)
Introduce changes necessary for UEFI X86_64 target Clang driver.
Addressed the review comments originally suggested in Phabricator.

Differential Revision: https://reviews.llvm.org/D159541
2024-09-19 11:46:55 -07:00
dyung
4e09d7bc2c
Revert "[HIP] Use original file path for CUID" (#108771)
Reverts llvm/llvm-project#107734

The test modified in this commit, hip-cuid-hash.hip is failing on MacOS:
- https://lab.llvm.org/buildbot/#/builders/190/builds/5764
- https://lab.llvm.org/buildbot/#/builders/23/builds/3020
2024-09-15 09:40:55 -07:00
Yaxun (Sam) Liu
9fc789d922
[HIP] Use original file path for CUID (#107734)
to avoid being nondeterministic due to random path in distributed build.
2024-09-15 00:37:15 -04:00
Artem Belevich
4a501a4556
[CUDA/HIP] propagate -cuid to a host-only compilation. (#107483)
Right now we're bailing out too early, and `-cuid` does not get set for
the host-only compilations.
2024-09-09 11:14:41 -07:00
Simon Tatham
26bf0b4ae7
[clang][Driver] Add a custom error option in multilib.yaml. (#105684)
Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.

For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.

In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.

This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.

In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
2024-09-02 16:56:03 +01:00
Kim Gräsman
924a7d83b4
Use CLANG_RESOURCE_DIR more consistently (#103388)
When Clang is consumed as a library, the CLANG_RESOURCE_DIR definition
is not exported from the CMake system, so external clients will be
unable to compute the same resource dir as Clang itself would, because
they don't know what to pass for the optional CustomResourceDir
argument.

All call sites except one would pass CLANG_RESOURCE_DIR to
Driver::GetResourcesPath. It seems the one exception in libclang
CIndexer was an oversight.

Move the use of CLANG_RESOURCE_DIR into GetResourcesPath and remove the
optional argument to avoid this inconsistency between internal and
external clients.
2024-08-26 14:49:56 -03:00
Martin Storsjö
8ca5ff2743
Revert "[clang][driver] Fix -print-target-triple OS version for apple targets" (#104563)
This reverts llvm/llvm-project#104037 /
7227b44f928a87b5d7fb05bd1539fdfb6d4958dc.

This change had the unintended consequence of making e.g. `clang -target
armv7-windows-gnu --print-target-triple` output
`thumbv7-unknown-windows-gnu` rather than `armv7-unknown-windows-gnu`.
2024-08-16 11:38:22 +03:00
Gábor Horváth
7227b44f92
[clang][driver] Fix -print-target-triple OS version for apple targets (#104037)
The target needs to be initialized in order to compute the correct
target triple from the command line. Without initialized targets the OS
component of the triple might not reflect what would be computed by the
driver for an actual compiler invocation.

Fixes https://github.com/llvm/llvm-project/issues/61762
2024-08-15 10:04:59 +01:00
Johannes Doerfert
80525dfcde
[Offload][CUDA] Allow CUDA kernels to use LLVM/Offload (#94549)
Through the new `-foffload-via-llvm` flag, CUDA kernels can now be
lowered to the LLVM/Offload API. On the Clang side, this is simply done
by using the OpenMP offload toolchain and emitting calls to `llvm*`
functions to orchestrate the kernel launch rather than `cuda*`
functions. These `llvm*` functions are implemented on top of the
existing LLVM/Offload API.

As we are about to redefine the Offload API, this wil help us in the
design process as a second offload language.

We do not support any CUDA APIs yet, however, we could:
  https://www.osti.gov/servlets/purl/1892137

For proper host execution we need to resurrect/rebase
  https://tianshilei.me/wp-content/uploads/2021/12/llpp-2021.pdf
(which was designed for debugging).

```
❯❯❯ cat test.cu
extern "C" {
void *llvm_omp_target_alloc_shared(size_t Size, int DeviceNum);
void llvm_omp_target_free_shared(void *DevicePtr, int DeviceNum);
}

__global__ void square(int *A) { *A = 42; }

int main(int argc, char **argv) {
  int DevNo = 0;
  int *Ptr = reinterpret_cast<int *>(llvm_omp_target_alloc_shared(4, DevNo));
  *Ptr = 7;
  printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
  square<<<1, 1>>>(Ptr);
  printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
  llvm_omp_target_free_shared(Ptr, DevNo);
}

❯❯❯ clang++ test.cu -O3 -o test123 -foffload-via-llvm --offload-arch=native

❯❯❯ llvm-objdump --offloading test123

test123:        file format elf64-x86-64

OFFLOADING IMAGE [0]:
kind            elf
arch            gfx90a
triple          amdgcn-amd-amdhsa
producer        openmp

❯❯❯ LIBOMPTARGET_INFO=16 ./test123
Ptr 0x155448ac8000, *Ptr 7
Ptr 0x155448ac8000, *Ptr 42
```
2024-08-12 17:44:58 -07:00
Kazu Hirata
7a6acd9844
[clang] Use llvm::is_contained (NFC) (#102720) 2024-08-09 22:39:19 -07:00
macurtis-amd
13dd795ef1
[clang][NFC] Make OffloadLTOMode getter a separate method (#101200)
Minor readability improvement (IMHO). Also makes it easier to find the
places where we are getting the offload lto mode.
2024-08-05 10:06:51 -05:00
Gábor Horváth
7d8375b86e
[clang][driver] Fix -print-libgcc-file-name on Darwin platforms (#98325)
On Darwin, -print-libgcc-file-name was returning a nonsensical result.
It would return the name of the library that would be used by the
default toolchain implementation, but that was something that didn't
exist on Darwin.

Fixing this requires initializing the Darwin toolchain before processing
`-print-libgcc-file-name`. Previously, the Darwin toolchain would only
be initialized when building the jobs for this compilation, which is too
late since `-print-libgcc-file-name` requires the toolchain to be
initialized in order to provide the right results.

rdar://90633749

Co-authored-by: Gabor Horvath <gaborh@apple.com>
2024-07-19 13:24:38 +01:00
Michael Maitland
eee5d2d37c
[RISCV] Add ability to list extensions enabled for a target (#98207)
bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this option. This patch
adds documentation for this option.

`riscvExtensionsHelp` is renamed to `printSupportedExtensions` to by
synonymous with AArch64 and so it is clear what that function does.
2024-07-10 15:39:08 -04:00
Yingwei Zheng
9acaccbaee
[RISCV][Driver] Refactor riscv::getRISCVArch to return std::string. NFC. (#97965)
See the discussion in
https://github.com/llvm/llvm-project/pull/94352#discussion_r1657074801
2024-07-09 14:34:37 +08:00
Jakub Chlanda
ab20086422
[CUDA][NFC] CudaArch to OffloadArch rename (#97028)
Rename `CudaArch` to `OffloadArch` to better reflect its content and the
use.
Apply a similar rename to helpers handling the enum.
2024-06-30 07:56:07 +02:00
Fangrui Song
592abf29f9 [Driver] BuildOffloadingActions: Actually stabilize iteration order
In
```
/tmp/StaticDebug/bin/clang -ccc-print-phases -lsomelib -fopenmp=libomp --target=powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu clang/test/Driver/openmp-offload.c clang/test/Driver/openmp-offload.c
```

Both ToolChains have one single empty arch. llvm::sort in
LLVM_ENABLE_EXPENSIVE_CHECKS=on builds could swap the two entries.

Fixes: 255986e27fcf9f0b36f7a23fbe030fcca1ba0249
2024-06-28 11:06:29 -07:00
Lucas Duarte Prates
bb83a3df25
Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
2024-06-28 09:20:16 +01:00
Lucas Duarte Prates
b579aacc30
Revert "[AArch64] Add ability to list extensions enabled for a target" (#96768)
Reverts llvm/llvm-project#95805 due to test failures caught by the
buildbots.
2024-06-26 14:59:01 +01:00
Lucas Duarte Prates
b6240c3715
[AArch64] Add ability to list extensions enabled for a target (#95805)
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
2024-06-26 14:28:26 +01:00
Alex Voicu
9acb533c38
[clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (#95061)
This patch augments the HIPAMD driver to allow it to target AMDGCN
flavoured SPIR-V compilation. It's mostly straightforward, as we re-use
some of the existing SPIRV infra, however there are a few notable
additions:

- we introduce an `amdgcnspirv` offload arch, rather than relying on
using `generic` (this is already fairly overloaded) or simply using
`spirv` or `spirv64` (we'll want to use these to denote unflavoured
SPIRV, once we bring up that capability)
- initially it is won't be possible to mix-in SPIR-V and concrete AMDGPU
targets, as it would require some relatively intrusive surgery in the
HIPAMD Toolchain and the Driver to deal with two triples
(`spirv64-amd-amdhsa` and `amdgcn-amd-amdhsa`, respectively)
- in order to retain user provided compiler flags and have them
available at JIT time, we rely on embedding the command line via
`-fembed-bitcode=marker`, which the bitcode writer had previously not
implemented for SPIRV; we only allow it conditionally for AMDGCN
flavoured SPIRV, and it is handled correctly by the Translator (it ends
up as a string literal)

Once the SPIRV BE is no longer experimental we'll switch to using that
rather than the translator. There's some additional work that'll come
via a separate PR around correctly piping through AMDGCN's
implementation of `printf`, for now we merely handle its flags
correctly.
2024-06-25 12:19:28 +01:00
David Truby
a2d340ba16
Revert "[Flang][Driver] Add -print-resource-dir command line flag to emit Flang's resource directory" (#96557)
Reverts llvm/llvm-project#90886

These changes broke linking to compiler-rt on Windows
2024-06-25 00:46:50 +01:00
Fangrui Song
255986e27f [Driver] BuildOffloadingActions: Stabilize iteration order
Otherwise hip-phases.hip could fail when llvm::hash_value(StringRef)
changes.
2024-06-20 21:45:40 -07:00
Braden Helmer
83a54e75c1
[clang] Implement -Wmissing-include-dirs (#94827)
Implements -Wmissing-include-dirs #92015 

This is my first contribution and would love some feedback. Thanks!
2024-06-12 11:30:10 +02:00
huangqinjin
06b5a7c205
[clang][driver] Support -x for all languages in CL mode (#89772)
After https://github.com/llvm/llvm-project/pull/68921, clang-cl gained
option `-x` but only for CUDA/HIP. This commit simply removes the
restriction on parameters to `-x`. Especially, it is able to use `-x
c++-module` and `-x c++-system-header` to build C++20 modules and header
units with clang-cl.

This effectively reverts commit
fe082124faa8455cc9a68be5fdf10fc46a4d066c.

Closes https://github.com/llvm/llvm-project/issues/88006.
2024-05-23 22:39:17 -07:00
Michael Klemm
2df06e42d7
[Flang][Driver] Add -print-resource-dir command line flag to emit Flang's resource directory (#90886)
This should be a NFC change for all drivers, but Flang.
2024-05-14 09:01:51 +02:00
Kazu Hirata
135d92f903
[Driver] Use StringRef::operator== instead of StringRef::equals (NFC) (#91698)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
  13 under clang/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
  std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
  !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-09 23:12:08 -07:00
Nathan Lanza
359ab3aebb
[CIR] Add options to emit ClangIR and enable the ClangIR pipeline
Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.

Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay

Reviewed By: erichkeane

Pull Request: https://github.com/llvm/llvm-project/pull/89030
2024-04-29 15:46:18 -04:00
Craig Topper
733a87783c
[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
2024-04-23 15:12:36 -07:00
Chuanqi Xu
f811d7b509
[C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (#85050)
This is the driver part of
https://github.com/llvm/llvm-project/pull/75894.

This patch introduces '-fexperimental-modules-reduced-bmi' to enable
generating the reduced BMI.

This patch did:
- When `-fexperimental-modules-reduced-bmi` is specified but
`--precompile` is not specified for a module unit, we'll skip the
precompile phase to avoid unnecessary two-phase compilation phases. Then
if `-c` is specified, we will generate the reduced BMI in CodeGenAction
as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified and
`--precompile` is specified, we will generate the reduced BMI in
GenerateModuleInterfaceAction as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified for a
non-module unit. We don't do anything nor try to give a warn. This is
more user friendly so that the end users can try to test and experiment
with the feature without asking help from the build systems.

The core design idea is that users should be able to enable this easily
with the existing cmake mechanisms.

The future plan for the flag is:
- Add this to clang19 and make it opt-in for 1~2 releases. It depends on
the testing feedback to decide how long we like to make it opt-in.
- Then we can announce the existing BMI generating may be deprecated and
suggesting people (end users or build systems) to enable this for 1~2
releases.
- Finally we will enable this by default. When that time comes, the term
`BMI` will refer to the reduced BMI today and the existing BMI will only
be meaningful to build systems which loves to support two phase
compilations.

I'll send release notes and document in seperate commits after this get
landed.
2024-04-15 11:55:45 +08:00
Cassie Jones
68b939f931
[driver] Make --version show if assertions, etc. are enabled (#87585)
It's useful to have some significant build options visible in the
version when investigating problems with a specific compiler artifact.
This makes it easy to see if assertions, expensive checks, sanitizers,
etc. are enabled when checking a compiler version.

Example config line output:
Build configuration: +unoptimized, +assertions, +asan, +ubsan
2024-04-05 10:01:09 -07:00
Daniel Grumberg
e05c1b46d0
Reenable external categories (#87357)
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.

Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
2024-04-03 10:18:05 +01:00
Daniel Grumberg
209a1e8dfd Revert "[clang][ExtractAPI] Add ability to create multiple symbol graphs (#86676)"
This failed the test suite due to missing DiagGroup for a new warning.

This reverts commit b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
2024-04-02 15:34:52 +01:00
Daniel Grumberg
b31414bf4f
[clang][ExtractAPI] Add ability to create multiple symbol graphs (#86676)
This extends ExtractAPI to take into account symbols defined in categories to types defined in an external module.
This introduces 2 new command line flags, `--symbol-graph-dir=DIR` and `--emit-extension-symbol-graphs`, when used together this generates additional symbol graph files at `DIR/ExtendedModule@ProductName.symbols.json` for each external module that is extended in this way.

Additionally this makes some cleanups to tests to make them more resilient and cleans up the `APISet` data structure.
2024-04-02 15:03:46 +01:00
Chuanqi Xu
21f85e2300 [NFC] [C++20] [Modules] Pulling out getCXX20NamedModuleOutputPath into a seperate function
Required in the review process of
https://github.com/llvm/llvm-project/pull/85050.
2024-04-02 09:58:59 +08:00
Mark de Wever
2152094a45
[clang] Improves -print-library-module-manifest-path. (#85943)
This adds a libc++ to modules.json as is currently used by libc++. When
libc++.so is not found the function will search for libc++.a as
fallback.
2024-03-21 15:11:45 +01:00
Joseph Huber
357f00dddb
[HIP] Correctly omit bundling with the new driver (#85842)
Summary:
The HIP phases do not emit the offload bundler output when we do not
invoke the final linker phase in device only mode. Check this propery.
2024-03-20 07:15:49 -05:00
Joseph Huber
280c7a9526 [Clang] Fix preprocessing device only in HIP mode
Summary:
A recent change made the HIP compilation bundle by default. However we
don't want to do this for `-E`, which silently broke some handling.
2024-03-18 12:12:17 -05:00
Chuanqi Xu
0e1e1fc8f0
Reland Print library module manifest path again (#84881)
Following of https://github.com/llvm/llvm-project/pull/82160

The reason why the above PR fails is that the `--sysroot` has lower
priority than the libc++ built from the same source. On the one hand, it
matches the codes behavior. We will add the built libc++ project paths
in the ToolChain class. But we will only add the path related to sysroot
in Linux class, which is derived from the ToolChain classes. So the
paths of just built libc++ is in the front of the paths relative to
sysroot. On the other hand, the behavior should be good from the higher
level. Since the just built libc++ has the same version number with the
just built clang, so it makes sense that these 2 compilers just matches.

So for patch it self, I hacked it by using resource dir in the test
since the resource dir has the higher priority, which is not strongly
correct since we won't do that in practice.

@kaz7 would you like to test on your environment to avoid this get
reverted again?

On the libc++ side, it shows that it lacks a `modules.json` file for the
just built libc++ directory. If we don't have that, it will be
problematic to use std modules from the just built clang and libc++
pair. Then it is not good. And I feel it may be problematic for future
compiler/standard library developers. So I feel this is somewhat a
libc++ issue that need to be fixed.

Also if we don't like the hacked test in the current patch, we must wait
for libc++ to fix this to proceed. But I feel this is somewhat odd since
the test of clang shouldn't dependent on libc++.

CC: @mordante

---------

Co-authored-by: Mark de Wever <koraq@xs4all.nl>
2024-03-17 21:14:53 +08:00
Dave Lee
8d7ee4691d
[clang] Move CCC_OVERRIDE_OPTIONS implementation to Driver (#85425)
Move CCC_OVERRIDE_OPTIONS support to clangDriver so that it may be used outside of the 
clang driver binary.

The override functionality will be used in LLDB, to apply adjustments to ClangImporter 
flags. This will be useful as an escape hatch when there are issues that can be fixed 
by adding or removing clang flags.

The only thing changed is the name, from `ApplyQAOverride` to `applyOverrideOptions`.
2024-03-15 16:09:56 -07:00
Joseph Huber
d1d80cc319
[HIP] Make the new driver bundle outputs for device-only (#84534)
Summary:
The current behavior of HIP is that when --offload-device-only is set it
still bundles the outputs into a fat binary. Even though this is
different from how all the other targets handle this, it seems to be
dependned on by some tooling so just make it backwards compatible for
the `-fno-gpu-rdc` case.
2024-03-11 14:09:59 -05:00
Joseph Huber
4d1d1271b8
[HIP] Make the HIP default architecture use the enum value (#84400)
Summary:
This default enum is used in other places, we should keep it consistent.
2024-03-08 06:54:52 -06:00
Joseph Huber
3a56b5a27d
[CUDA] Include PTX in non-RDC mode using the new driver (#84367)
Summary:
The old driver embed PTX in rdc-mode and so does the `nvcc` compiler.
The new drivers currently does not do this, so we should keep it
consistent in this case. This simply requires adding the assembler
output as an input to the offloading action that gets fed to fatbin.
2024-03-07 16:53:41 -06:00
Joseph Huber
433b71188d
[CUDA] Correctly set CUDA default architecture (#84017)
Summary:
We already had a special CUDA default that better tracked the state as
of modern CUDA installations. Recently this was bumped up to `sm_52`,
but there was a location that wasn't respecting this. Fix that.
2024-03-05 22:03:00 -06:00
Kazushi (Jam) Marukawa
c240aca7a8 Revert "Reland "[clang][modules] Print library module manifest path." (#82160)"
This reverts commit 0c89427b99f6f6d7c217c70ff880ca097340f9a4.
2024-03-05 01:34:48 +09:00
Fangrui Song
2b5cd8be3a [Driver] Remove InstallDir and getInstalledDir. NFC
Follow-up to #80527.
2024-03-03 18:10:46 -08:00
Mark de Wever
0c89427b99
Reland "[clang][modules] Print library module manifest path." (#82160)
This implements a way for the compiler to find the modules.json
associated with the C++23 Standard library modules.

This is based on a discussion in SG15. At the moment no Standard library
installs this manifest. #75741 adds this feature in libc++.

This reverts commit 82f424f766be00b037a706a835d0a0663a2680f1.

Disables the tests on non-X86 platforms as suggested.
2024-03-03 17:58:08 +01:00