Commit Graph

2261 Commits

Author SHA1 Message Date
Kyle Huey
f5b023bd9c When the required discriminator value exceeds LLVM's limits, drop the debug info for the function instead of panicking.
The maximum discriminator value LLVM can currently encode is 2^12. If macro use
results in more than 2^12 calls to the same function attributed to the same
callsite, and those calls are MIR-inlined, we will require more than the maximum
discriminator value to completely represent the debug information. Once we reach
that point drop the debug info instead.
2024-11-19 05:19:09 -08:00
Kyle Huey
1e4ebb0ccd Honor collapse_debuginfo when dealing with MIR-inlined functions inside macros.
The test relies on the fact that inlining more than 2^12 calls at the same
callsite will trigger a panic (and after the following commit, a warning) due to
LLVM limitations but with collapse_debuginfo the callsites should not be the
same.
2024-11-19 05:18:56 -08:00
lcnr
9cba14b95b use TypingEnv when no infcx is available
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
2024-11-18 10:38:56 +01:00
Jiri Bobek
777003ae9f Likely unlikely fix 2024-11-17 21:49:10 +01:00
bors
3bc6916f4c Auto merge of #132965 - mati865:cfguard-gnullvm, r=wesleywiser
allow CFGuard on windows-gnullvm

No unit tests because of https://github.com/rust-lang/rust/issues/132278
2024-11-15 00:21:07 +00:00
Matthias Krüger
bd79fe7a94
Rollup merge of #132702 - 1c3t3a:issue-132615, r=rcvalle
CFI: Append debug location to CFI blocks

Currently we're not appending debug locations to the inserted CFI blocks. This shows up in #132615 and #100783. This change fixes that by passing down the debug location to the CFI type-test generation and appending it to the blocks.

Credits also belong to `@jakos-sec` who worked with me on this.
2024-11-12 23:26:41 +01:00
Mateusz Mikuła
811c1db715 allow CFGuard on windows-gnullvm 2024-11-12 01:18:53 +01:00
Matthias Krüger
35225d61f4
Rollup merge of #132820 - bjorn3:default_backend_link_impl, r=jieyouxu
Add a default implementation for CodegenBackend::link

As a side effect this should add raw-dylib support to cg_gcc as the default ArchiveBuilderBuilder that is used implements create_dll_import_lib. I haven't tested if the raw-dylib support actually works however.
2024-11-11 21:58:32 +01:00
Bastian Kersting
c2102259a0 CFI: Append debug location to CFI blocks 2024-11-11 09:17:43 +00:00
bors
71042b4b20 Auto merge of #132880 - RalfJung:implied-features, r=workingjubilee
target_features: explain what exacty 'implied' means here
2024-11-11 09:12:03 +00:00
Ralf Jung
2c7f3badcf target_features: explain what exacty 'implied' means here 2024-11-11 07:33:39 +01:00
Matthias Krüger
b95232dabb
Rollup merge of #132675 - Zalathar:empty-spans, r=jieyouxu
coverage: Restrict empty-span expansion to only cover `{` and `}`

Coverage instrumentation has some tricky code for converting a coverage-relevant `Span` into a set of start/end line/byte-column coordinates that will be embedded in the CGU's coverage metadata.

A big part of this complexity is special code for handling empty spans, which are expanded into non-empty spans (if possible) because LLVM's coverage reporter does not handle empty spans well.

This PR simplifies that code by restricting it to only apply in two specific situations: when the character after the empty span is `{`, or the character before the empty span is `}`.

(As an added benefit, this means that the expanded spans no longer extend awkwardly beyond the end of a physical line, which was common under the previous implementation.)

Along the way, this PR also removes some unhelpful code for dealing with function source code spread across multiple files. Functions currently can't have coverage spans in multiple files, and if that ever changes (e.g. to properly support expansion regions) then this code will need to be completely overhauled anyway.
2024-11-10 17:43:07 +01:00
Zalathar
925dfc8608 coverage: Pass a LocalFileId to CoverageSpan::from_source_region 2024-11-10 11:58:44 +11:00
bjorn3
0a619dbc5d Pass owned CodegenResults to link_binary
After link_binary the temporary files referenced by CodegenResults are
deleted, so calling link_binary again with the same CodegenResults
should not be allowed.
2024-11-09 21:22:00 +00:00
Kyle Huey
1dc106121b Add discriminators to DILocations when multiple functions are inlined into a single point.
LLVM does not expect to ever see multiple dbg_declares for the same variable at the same
location with different values. proc-macros make it possible for arbitrary code,
including multiple calls that get inlined, to happen at any given location in the source
code. Add discriminators when that happens so these locations are different to LLVM.

This may interfere with the AddDiscriminators pass in LLVM, which is added by the
unstable flag -Zdebug-info-for-profiling.

Fixes #131944
2024-11-09 08:01:31 -08:00
bors
80445576d0 Auto merge of #132800 - matthiaskrgr:rollup-c1kkj56, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #132552 (Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file)
 - #132745 (pointee_info_at: fix logic for recursing into enums)
 - #132777 (try_question_mark_nop: update test for LLVM 20)
 - #132785 (rustc_target: more target string fixes for LLVM 20)
 - #132794 (Use a separate dir for r-a builds consistently in helix config)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-09 12:23:47 +00:00
Matthias Krüger
b9d4ef16c9
Rollup merge of #132552 - taiki-e:sparc-target-feature, r=workingjubilee
Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file

This adds the following three unstable target features:

- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
  - Relevant to https://github.com/rust-lang/rust/pull/131222#issuecomment-2453310963
  - Relevant to https://github.com/rust-lang/rust/pull/132472#discussion_r1832606081
  - This is also needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
  - This is added in LLVM 20. In LLVM 19 and older, it is emulated to work the same way as LLVM in each LLVM version.
  - See https://github.com/rust-lang/rust/issues/132585#issuecomment-2453926257 for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
  - This is needed to implement https://github.com/taiki-e/atomic-maybe-uninit/pull/31 (depends on inline assembly support) more robustly.

[^1]: Atomic CAS instruction

[sparc-v9]: f5e4ffaa49/llvm/lib/Target/Sparc/Sparc.td (L37-L39)
[sparc-v8plus]: f5e4ffaa49/llvm/lib/Target/Sparc/Sparc.td (L37-L39)
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
2024-11-09 10:52:03 +01:00
bors
4b198d6871 Auto merge of #132584 - Zalathar:includes, r=cuviper
Trim and tidy includes in `rustc_llvm`

These includes tend to accumulate over time, and are usually only removed when something breaks in a new LLVM version, so it's nice to clean them up manually once in a while.

General strategy used for this PR:
- Remove all includes from `LLVMWrapper.h` that aren't needed by the header itself, transplanting them to individual source files as necessary.
- For each source file, temporarily remove each include if doing so doesn't cause a compile error.
- If a “required” include looks like it shouldn't be needed, try replacing it with its sub-includes, then trim that list.
- After doing all of the above, go back and re-add any removed include if the file does actually use things defined in that header, even if the header happens to also be included by something else.
2024-11-09 09:46:08 +00:00
Zalathar
89d7efaf8f Make RustString an extern type to avoid improper_ctypes warnings 2024-11-09 11:07:44 +11:00
Taiki Endo
c059eb7750 Add v8plus target feature to sparc and use it in create_object_file 2024-11-09 03:22:09 +09:00
Taiki Endo
400a690b5f Add v9 and leoncasa target feature to sparc 2024-11-09 03:17:24 +09:00
Zalathar
996bdabc2a coverage: Remove unhelpful code for handling multiple files per function
Functions currently can't have mappings in multiple files, and if that ever
changes (e.g. to properly support expansion regions), this code will need to be
completely overhauled anyway.
2024-11-08 20:43:08 +11:00
Zalathar
3f9c54caf0 coverage: Add GlobalFileId for stricter type-checking of file IDs
We already had a dedicated `LocalFileId` index type, but previously we used a
raw `u32` for global file IDs, because index types were harder to pass through
FFI.
2024-11-08 20:43:08 +11:00
Stuart Cook
3a48d80155
Rollup merge of #132590 - Zalathar:z-timings-stats, r=jieyouxu
Simplify FFI calls for `-Ztime-llvm-passes` and `-Zprint-codegen-stats`

The existing code for these unstable LLVM-infodump flags was jumping through hoops to pass an allocated C string across the FFI boundary, when it's much simpler to just write to a `&RustString` instead.
2024-11-08 18:51:30 +11:00
Stuart Cook
758a904764
Rollup merge of #132452 - Zalathar:llvm-cov-wrappers, r=jieyouxu
coverage: Extract safe FFI wrapper functions to `llvm_cov`

This PR takes all of the inline `unsafe` calls in coverage codegen, and all the safe wrapper functions in `coverageinfo/mod.rs`, and moves them to a new `llvm_cov` submodule that is dedicated to safe FFI wrapper functions. This reduces the mixing of abstraction levels in the rest of coverage codegen.

As a follow-up, this PR also tidies up the names and signatures of several of the coverage FFI functions.
2024-11-08 18:51:29 +11:00
Jubilee
97dbab9124
Rollup merge of #132741 - zmodem:mips_data_layout, r=nikic
Update mips64 data layout to match LLVM 20 change

LLVM changed the data layout in https://github.com/llvm/llvm-project/pull/112084
2024-11-07 18:48:26 -08:00
Jubilee
60e8ab6ba8
Rollup merge of #130586 - dpaoliello:fixrawdylib, r=wesleywiser
Set "symbol name" in raw-dylib import libraries to the decorated name

`windows-rs` received a bug report that mixing raw-dylib generated and the Windows SDK import libraries was causing linker failures: <https://github.com/microsoft/windows-rs/issues/3285>

The root cause turned out to be #124958, that is we are not including the decorated name in the import library and so the import name type is also not being correctly set.

This change modifies the generation of import libraries to set the "symbol name" to the fully decorated name and correctly marks the import as being data vs function.

Note that this also required some changes to how the symbol is named within Rust: for MSVC we now need to use the decorated name but for MinGW we still need to use partially decorated (or undecorated) name.

Fixes #124958

Passing i686 MSVC and MinGW build: <https://github.com/rust-lang/rust/actions/runs/11000433888?pr=130586>

r? `@ChrisDenton`
2024-11-07 18:48:20 -08:00
Hans Wennborg
eb7d95bafd remove the extra specification for llvm versions < 20 2024-11-07 20:59:50 +01:00
Taiki Endo
241f82ad91 Basic inline assembly support for SPARC and SPARC64 2024-11-07 21:19:03 +09:00
bors
a69df72bdc Auto merge of #132664 - matthiaskrgr:rollup-i27nr7i, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #131261 (Stabilize `UnsafeCell::from_mut`)
 - #131405 (bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip)
 - #132077 (Add a new `wide-arithmetic` feature for WebAssembly)
 - #132562 (Remove the `wasm32-wasi` target from rustc)
 - #132660 (Remove unused errs.rs file)

Failed merges:

 - #131721 (Add new unstable feature `const_eq_ignore_ascii_case`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-06 01:21:42 +00:00
Matthias Krüger
088e698835
Rollup merge of #132077 - alexcrichton:wide-arithmetic, r=jieyouxu
Add a new `wide-arithmetic` feature for WebAssembly

This commit adds a new rustc target feature named `wide-arithmetic` for WebAssembly targets. This corresponds to the [wide-arithmetic] proposal for WebAssembly which adds new instructions catered towards accelerating integer arithmetic larger than 64-bits. This proposal to WebAssembly is not standard yet so this new feature is flagged as an unstable target feature. Additionally Rust's LLVM version doesn't support this new feature yet since support will first be added in LLVM 20, so the feature filtering logic for LLVM is updated to handle this.

I'll also note that I'm not currently planning to add wasm-specific intrinsics to `std::arch::wasm32` at this time. The currently proposed instructions are all accessible through `i128` or `u128`-based operations which Rust already supports, so intrinsic shouldn't be necessary to get access to these new instructions.

[wide-arithmetic]: https://github.com/WebAssembly/wide-arithmetic
2024-11-05 23:43:57 +01:00
Matthias Krüger
c8247c0a19
Rollup merge of #132259 - mrkajetanp:branch-protection-pauth-lr, r=davidtwco
rustc_codegen_llvm: Add a new 'pc' option to branch-protection

Add a new 'pc' option to -Z branch-protection for aarch64 that enables the use of PC as a diversifier in PAC branch protection code.

When the pauth-lr target feature is enabled in combination with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions (pacibsppc, retaasppc, etc) will be generated.
2024-11-05 20:10:49 +01:00
bors
e8c698bb3b Auto merge of #129884 - RalfJung:forbidden-target-features, r=workingjubilee
mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature

The context for this is https://github.com/rust-lang/rust/issues/116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.

So this introduces a new concept of "forbidden" target features (on top of the existing "stable " and "unstable" categories), and makes it a hard error to (un)set such a target feature. For now, the x86 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in https://github.com/rust-lang/rust/issues/131799.)

I've made this a warning for now to give people some time to speak up if this would break something.

MCP: https://github.com/rust-lang/compiler-team/issues/780
2024-11-05 16:25:45 +00:00
Zalathar
19d5dc0ed1 coverage: Tidy up coverage-specific FFI functions 2024-11-05 15:32:36 +11:00
Zalathar
b790e4473c coverage: Extract safe FFI wrapper functions to llvm_cov 2024-11-05 15:32:34 +11:00
bors
96477c55bc Auto merge of #131341 - taiki-e:ppc-clobber-abi, r=bzEq,workingjubilee
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly

This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.

This basically does a similar thing I did in https://github.com/rust-lang/rust/pull/130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le.
- This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`.
- `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR.
  - See https://github.com/rust-lang/rust/pull/131551 (which is based on this PR) for a PR to implement this.
  - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.)

Refs:
- PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf)
- PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL)
- PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/)
- AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming)
- Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189

If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`:
- The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile).
- As for GPR, only the registers we are treating as reserved are slightly different
  - r0, r3-r12 are volatile
  - r1(sp, reserved), r14-31 are nonvolatile
  - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs)
  - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX)
- As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2.
- As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](https://github.com/rust-lang/rust/pull/131341#discussion_r1797693299)) in AIX:
  > When the default Vector enabled mode is used, these registers are reserved and must not be used.
  > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls

  I left [FIXME comment about PPC32 SysV](https://github.com/rust-lang/rust/pull/131341#discussion_r1790496095) and added ABI check for AIX.
- As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX
- As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX

We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved.
We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.)

Replaces #111335 and #124279

cc `@ecnelises` `@bzEq` `@lu-zero`

r? `@Amanieu`

`@rustbot` label +O-PowerPC +A-inline-assembly

[^r13]: callee-saved, according to [LLVM](6a6af0246b/llvm/lib/Target/PowerPC/PPCCallingConv.td (L322)) and [GCC](a9173a50e7/gcc/config/rs6000/rs6000.h (L859)).
2024-11-05 03:13:47 +00:00
Ralf Jung
ffad9aac27 mark some target features as 'forbidden' so they cannot be (un)set
For now, this is just a warning, but should become a hard error in the future
2024-11-04 22:56:47 +01:00
Zalathar
5bfa0b106e Simplify FFI calls for -Ztime-llvm-passes and -Zprint-codegen-stats 2024-11-04 20:31:16 +11:00
Jubilee
7155c65d68
Rollup merge of #132565 - bjorn3:less_target_name_dependence, r=workingjubilee
Reduce dependence on the target name

The target name can be anything with custom target specs. Matching on fields inside the target spec is much more robust than matching on the target name.

Also remove the unused is_builtin target spec field.
2024-11-03 20:08:14 -08:00
Zalathar
44a056a50b Move LLVMRustAttribute[Kind] out of LLVMWrapper.h 2024-11-04 12:27:23 +11:00
Jubilee Young
b895bf4fdc compiler: Directly use rustc_abi in codegen 2024-11-03 12:30:32 -08:00
bjorn3
9e6d2da83d Reduce dependence on the target name
The target name can be anything with custom target specs. Matching on
fields inside the target spec is much more robust than matching on the
target name.
2024-11-03 18:29:01 +00:00
bors
59ae5eba7e Auto merge of #132514 - Zalathar:print-target-cpus, r=jieyouxu
Port most of `--print=target-cpus` to Rust

The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.

This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
2024-11-03 11:09:38 +00:00
Noratrieb
a26450cf81 Rename target triple to target tuple in many places in the compiler
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
2024-11-02 21:29:59 +01:00
Zalathar
90f2075b66 Port most of LLVMRustPrintTargetCPUs to Rust 2024-11-02 23:39:29 +11:00
Zalathar
0fa86f9660 Use a dedicated safe wrapper for LLVMRustGetHostCPUName 2024-11-02 23:39:29 +11:00
Taiki Endo
d19517dcd0 Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly 2024-11-02 20:26:08 +09:00
Matthias Krüger
bb544f863f
Rollup merge of #131037 - madsmtm:move-llvm-target-versioning, r=petrochenkov
Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa`

Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc.

We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from https://github.com/rust-lang/rust/pull/130883 to do https://github.com/rust-lang/rust/issues/118204. See also https://github.com/rust-lang/rust/pull/129342#issuecomment-2335156119 for some discussion.

The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session.

Tested with the same commands as in https://github.com/rust-lang/rust/pull/130435.

r? ``````@petrochenkov``````
2024-11-02 08:33:10 +01:00
Guillaume Gomez
526c67f37b
Rollup merge of #131829 - Zalathar:goodbye-zprofile, r=chenyukang
Remove support for `-Zprofile` (gcov-style coverage instrumentation)

Tracking issue: #42524

MCP: https://github.com/rust-lang/compiler-team/issues/798

---

This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.

(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)

Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
  - #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
2024-11-02 03:08:49 +08:00
Mads Marquart
e1233153ac Move versioned LLVM target creation to rustc_codegen_ssa
The OS version depends on the deployment target environment variables,
the access of which we want to move to later in the compilation pipeline
that has access to more information, for example `env_depinfo`.
2024-11-01 17:07:18 +01:00