Make `RustString` an extern type to avoid `improper_ctypes` warnings
Currently, any FFI function that uses `&RustString` needs to also add `#[ignore(improper_ctypes)]` to silence a warning.
The warning is not _completely_ bogus, because `RustString` contains `Vec<u8>` and therefore does not have a guaranteed layout. But we have no way of telling the lint that this doesn't matter, because the C++ code only uses that pointer opaquely and never relies on its underlying layout.
Ideally there would be some way to silence `improper_ctypes` at the type-definition site. But because there isn't, casting to and from a separate extern type is better than having to annotate every single use site.
On arm64, Cranelift used to produce object files that don't work with
lld. This has since been fixed. The GCC backend should always produce
object files that work with lld unless lld for whatever reason drops GCC
support. Most of the other more niche backends don't use cg_ssa's linker
code at all. If they do and don't work with lld, they can always disable
lld usage using a cli argument.
Without this commit using cg_clif is by default in a non-trivial amount
of cases a perf regression on Linux due to ld.bfd being a fair bit
slower than lld. It is possible to explicitly enable it without this
commit, but most users are unlikely to do this.
"whenever possible" means applying it if `download-rustc` isn't explicitly set and
the source is Git-managed.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead
This brings us one step closer towards removing support for `extern "rust-intrinsic"` blocks, in favor of `#[rustc_intrinsic]` functions.
Also move `#[rustc_intrinsic]` under the `intrinsics` feature gate, to match the `extern "rust-intrinsic"` style.
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.
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.
Initialize channel `Block`s directly on the heap
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes#102246
try-job: test-various
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.
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.
coverage: Simplify parts of coverage graph creation
This is a combination of three semi-related simplifications to how coverage graphs are created, grouped into one PR to avoid conflicts.
There are no observable changes to the output of any of the coverage tests.
Fix `librustdoc/scrape_examples.rs` formatting
Still working on the intra-doc link feature. This time I encountered this file and it bothered me a bit so fixing formatting. :3
r? ````@notriddle````
bootstrap: Print better message if lock pid isn't available
Not actually sure why, but sometimes the PID isn't available so we print
```
WARNING: build directory locked by process , waiting for lock
```
This makes the message a bit nicer in this case
Compile `test_num_f128` conditionally on `reliable_f128_math` config
With #132434 merged, our internal SGX CI started failing with:
```
05:27:34 = note: rust-lld: error: undefined symbol: fmodl
05:27:34 >>> referenced by arith.rs:617 (core/src/ops/arith.rs:617)
05:27:34 >>> /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/std-5d5f11eb008c9091.std.d8141acc61ab7ac8-cgu.10.rcgu.o:(std::num::test_num::h7dd9449f6c01fde8)
05:27:34 >>> did you mean: fmodf
05:27:34 >>> defined in: /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/libcompiler_builtins-0376f439a2ebf305.rlib(compiler_builtins-0376f439a2ebf305.compiler_builtins.c22db39d25d6f802-cgu.148.rcgu.o)
```
This originated from the `test_num_f128` test not having the required conditional compilation. This PR fixes that issue.
cc: ````@jethrogb,```` ````@workingjubilee````
core: move intrinsics.rs into intrinsics folder
This makes the rustbot notification we have set up for this folder in `triagebot.toml` actually work. Also IMO it makes more sense to have it all in one folder.
[StableMIR] API to retrieve definitions from crates
Add functions to retrieve function definitions and static items from all crates (local and external).
For external crates, we're still missing items from trait implementation and primitives.
r? ````@compiler-errors:```` Do you know what is the best way to retrieve the associated items for primitives and trait implementations for external crates? Thanks!
