| Age | Commit message (Collapse) | Author | Lines |
|---|
|
MinGW: enable dllexport/dllimport
Fixes (only when using LLD) https://github.com/rust-lang/rust/issues/50176
Fixes https://github.com/rust-lang/rust/issues/72319
This makes `windows-gnu` on pair with `windows-msvc` when it comes to symbol exporting.
For MinGW it means both good things like correctly working dllimport/dllexport, ability to link with LLD and bad things like https://github.com/rust-lang/rust/issues/27438.
Not sure but maybe this should land behind unstable compiler option (`-Z`) or environment variable?
|
|
This fixes various cases where LD could not guess dllexport correctly and greatly improves compatibility with LLD which is not going to support linker scripts anytime soon
|
|
rustc_target: Add a target spec option for disabling `--eh-frame-hdr`
Disable `--eh-frame-hdr` for targets that use an `ld`-like linker, but don't support that option.
Do it through a target spec option rather than through hard-coding in `linker.rs`.
The option is still enabled by default though.
cc https://github.com/rust-lang/rust/pull/73564
Fixes https://github.com/rust-lang/rust/pull/73564#issuecomment-657011004
Fixes https://github.com/rust-lang/rust/pull/74625
Fixes https://github.com/rust-embedded/msp430-rt/issues/12
|
|
Stabilize control-flow-guard codegen option
This is the stabilization PR discussed in #68793. It converts the `-Z control-flow-guard` debugging option into a codegen option (`-C control-flow-guard`), and changes the associated tests.
|
|
|
|
Generating the coverage map
@tmandry @wesleywiser
rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.
Example commands to generate a coverage report:
```shell
$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
```
r? @wesleywiser
Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
|
|
r=Mark-Simulacrum
Revert "Use an UTF-8 locale for the linker."
Reverts rust-lang/rust#74416
This is suspected to have caused significant compile time regressions: https://perf.rust-lang.org/compare.html?start=39d5a61f2e4e237123837f5162cc275c2fd7e625&end=d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02&stat=instructions:u
|
|
|
|
Use pathdiff crate
I wanted to tackle a simple issue, and stumbled upon #67108: this pr removes the function which was exported to the external crate as required in the todo/issue.
I've tested it with:
```
./x.py build --stage 1 --keep-stage 1 src/librustc_codegen_ssa
```
And it looks like it's compiling
|
|
|
|
|
|
rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.
Example:
$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
1| 1|pub fn will_be_called() {
2| 1| println!("called");
3| 1|}
4| |
5| 0|pub fn will_not_be_called() {
6| 0| println!("should not have been called");
7| 0|}
8| |
9| 1|fn main() {
10| 1| let less = 1;
11| 1| let more = 100;
12| 1|
13| 1| if less < more {
14| 1| will_be_called();
15| 1| } else {
16| 1| will_not_be_called();
17| 1| }
18| 1|}
|
|
|
|
Support const args in type dependent paths (Take 2)
once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154
-----
```rust
#![feature(const_generics)]
struct A;
impl A {
fn foo<const N: usize>(&self) -> usize { N }
}
struct B;
impl B {
fn foo<const N: usize>(&self) -> usize { 42 }
}
fn main() {
let a = A;
a.foo::<7>();
}
```
When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type.
This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` ->
`type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290)
To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by
calling `type_of(param_def_id)` instead.
We have to somehow remember the `DefId` of the param through all of typeck, which is done using the
struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to
be able to store the const parameter in case it exists.
Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`.
For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`.
r? @eddyb @varkor
|
|
|
|
This eliminates a bunch of `Symbol::intern()` and `Symbol::as_str()`
calls, which is good, because they require locking the interner.
Note that the unsafety in `from_cycle_error()` is identical to the
unsafety on other adjacent impls.
|
|
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
|
|
|
|
linker: illumos ld does not support --eh-frame-hdr
As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms. The illumos link editor does not
currently support this flag.
The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system. Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.
|
|
Avoid "whitelist"
Other terms are more inclusive and precise.
|
|
Only add CFGuard on `windows-msvc` targets
As @ollie27 pointed out in #73893, the `cfguard` module flag causes incorrect behavior on `windows-gnu` targets. This patch restricts rustc to only add this flag for `windows-msvc` targets (this may need to be changed if other linkers gain support for CFGuard).
|
|
Other terms are more inclusive and precise.
|
|
|
|
As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms. The illumos link editor does not
currently support this flag.
The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system. Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.
|
|
|
|
|
|
Self contained linking option
With objects moved to self-contained directory by https://github.com/rust-lang/rust/pull/72999 we can now add option to control whether to use self-contained on native linkage mode.
|
|
|
|
|
|
|
|
This commit modernizes how rustc checks for whether the `atomics`
feature is enabled for the wasm target. The `sess.target_features` set
is consulted instead of fiddling around with dealing with various
aspects of LLVM and that syntax.
|
|
|
|
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
|
|
first stage of implementing LLVM code coverage
This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST).
This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation.
This initial version only injects counters at the top of each function, and does not yet implement the required coverage map.
Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch.
Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
***[I put together some development notes here, under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
|
|
linker: MSVC supports linking static libraries as a whole archive
|
|
Create self-contained directory and move there some of external binaries/libs
One of the steps to reach design described in https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380
This PR moves things around and allows link code to handle the new directory structure.
|
|
Export `#[inline]` fns with extern indicators
In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However,
- #72944
- #72463
observe that when writing something like
```rust
#![crate_type = "cdylib"]
#[no_mangle]
#[inline]
pub extern "C" fn foo() {
// ...
}
```
we really _do_ want `foo` to be codegened. This change makes this the case.
Resolves #72944, resolves #72463 (and maybe some more)
|
|
This initial version only injects counters at the top of each function.
Rust Coverage will require injecting additional counters at each
conditional code branch.
|
|
|
|
|
|
|
|
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
|
|
|
|
|
|
|
|
|
|
linker: Add a linker rerun hack for gcc versions not supporting -static-pie
Which mirrors the existing `-no-pie` linker rerun hack, but the logic is a bit more elaborated in this case.
If the linker (gcc or clang) errors on `-static-pie` we rerun in with `-static` instead.
We must also replace CRT objects corresponding to `-static-pie` with ones corresponding to `-static` in this case.
(One sanity check for CRT objects in target specs is also added as a drive-by fix.)
To do in the future: refactor all linker rerun hacks into separate functions and share more code with `add_(pre,post)_link_objects`.
This PR accompanies https://github.com/rust-lang/rust/pull/71804 and unblocks https://github.com/rust-lang/rust/pull/70740.
|
|
|
|
This flag looks like it's been removed in LLVM 10, so this removes rustc
unconditionally passing the flag.
|
|
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Fixes #72664
Fixes #71639
r? @petrochenkov
### Old style
```rust
#![feature(llvm_asm)]
fn main() {
unsafe {
let _x: i32;
llvm_asm!(
"mov $0, $1
invalid_instruction $0, $1
mov $0, $1"
: "=&r" (_x)
: "r" (0)
:: "intel"
);
}
}
```
```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
invalid_instruction ecx, eax
^~~~~~~~~~~~~~~~~~~
--> src/main.rs:6:9
|
6 | / llvm_asm!(
7 | | "mov $0, $1
8 | | invalid_instruction $0, $1
9 | | mov $0, $1"
... |
12 | | :: "intel"
13 | | );
| |__________^
```
### New style
```rust
#![feature(asm)]
fn main() {
unsafe {
asm!(
"mov {0}, {1}
invalid_instruction {0}, {1}
mov {0}, {1}",
out(reg) _,
in(reg) 0i64,
);
}
}
```
```
error: invalid instruction mnemonic 'invalid_instruction'
--> test.rs:7:14
|
7 | invalid_instruction {0}, {1}
| ^
|
note: instantiated into assembly here
--> <inline asm>:3:14
|
3 | invalid_instruction rax, rcx
| ^^^^^^^^^^^^^^^^^^^
```
|
