Pass -pg to linker when using -Zinstrument-mcount
This selects a slightly different crt on gnu targets which enables the profiler within glibc.
This makes using gprof a little easier with Rust binaries. Otherwise, rustc must be passed `-Clink-args=-pg` to ensure the correct startup code is linked.
Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in https://github.com/rust-lang/rust/pull/153769#discussion_r2934399038 too.
This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI).
Also turn llvm_abiname into an enum to make it more natural to match on.
Cc @workingjubilee @madsmtm
target specs: stricter checks for LLVM ABI values, and correlate that with cfg(target_abi)
This tightens the checks for `llvm_abiname`, `llvm_floatabi` and `rustc_abi` in our target specs. Those are the fields that actually control the ccABI. With this commit, we now have an allowlist of value for these fields for all architectures (we previously only had that for some architectures). We also check that `cfg(target_abi)` suitably correlates with the actual ccABI. I based this check on our in-tree targets. For all ccABIs where we had a bunch of "random" values that don't directly correlate to the ccABI (like "uwp"), I also allowed `cfg(target_abi)` to remain empty, and whenever it is allowed to be empty I also allowed arbitrary other values for JSON targets. However, there's still a risk that JSON targets will fail this new check -- the idea is that we'll then get bugreports and can adjust the check as needed.
I had to adjust the target specs for non-ARM32 Apple targets as those were all setting `llvm_floatabi`, which to my knowledge makes no sense -- LLVM only actually does anything with that field on ARM32. I also adjusted the target specs for MIPS32 targets: one of them was setting llvm_abiname, and then it seems safer and more consistent to set that for all targets, so I set it to "o32" everywhere which seems to be the default.
Cc @workingjubilee
Clang and gcc use this option to control linking behavior too. Some
targets need to be linked against a special crt which enables
profiling at runtime.
This makes using gprof a little easier with Rust binaries. Otherwise,
rustc must be passed `-Clink-args=-pg` to ensure the correct startup
code is linked.
improve target feature diagnostic
And convert the test to use `minicore` so that it runs regardless of the target. This is the only test for many of these target feature diagnostics, so it's nice that it runs anywhere.
r? JonathanBrouwer
The test here is mostly for legal places for the attribute, is that still how that should be tested?
Remove `TyCtxt::node_lint` method and `rustc_middle::lint_level` function
Part of https://github.com/rust-lang/rust/issues/153099.
With this PR, we can finally get rid of `lint_level`. \o/
r? @JonathanBrouwer
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
Replace the `try_mark_green` hook with direct calls to `tcx.dep_graph`
All of the existing call sites are directly touching `tcx.dep_graph` anyway, so the extra layer of indirection provides no real benefit.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Cleanup unused diagnostic emission methods
Part of https://github.com/rust-lang/rust/issues/153099.
To remove `lint_level`, we need to remove all functions calling it. One of them is `TyCtxt::node_span_lint`, so removing it.
r? @JonathanBrouwer
- Hide common linker output behind `linker-info`
- Add tests
- Account for different capitalization on windows-gnu when removing
"warning" prefix
- Add some more comments
- Add macOS deployment-target test
- Ignore linker warnings from trying to statically link glibc
I don't know what's going on in `nofile-limit.rs` but I want no part
of it.
- Use a fake linker so tests are platform-independent
Make `size`/`align` always correct rather than conditionally on the
`safe` field. This makes it less error prone and easier to work with for
`MaybeDangling` / potential future pointer kinds like `Aligned<_>`.
This is already CodegenResults without CrateInfo. The driver can
calculate the CrateInfo and pass it by-ref to the backend. Using
CompiledModules makes it a bit easier to move some other things out of
the backend as will be necessary for moving LTO to the link phase.
Jacob Pratt