| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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.
|
|
tag/niche terminology cleanup
The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).
After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).
This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419.
(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)
r? @eddyb
|
|
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)
|
|
remove visit_terminator_kind from MIR visitor
For some reason, we had both `visit_terminator` and `visit_terminator_kind`. In contrast, for `Statement` we just have `visit_statement`. So this cleans things up by removing `visit_terminator_kind` and porting its users to `visit_terminator`.
|
|
Make all uses of ty::Error delay a span bug
r? @eddyb
A second attempt at https://github.com/rust-lang/rust/pull/70245
resolves https://github.com/rust-lang/rust/issues/70866
|
|
|
|
|
|
As suggested in PR feedback:
https://github.com/rust-lang/rust/pull/73011#discussion_r435728923
This allows count_code_region() to be handled like a normal intrinsic so
the InstanceDef::InjectedCode variant is no longer needed.
|
|
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.
|
|
Fix #[thread_local] statics as asm! sym operands
The `asm!` RFC specifies that `#[thread_local]` statics may be used as `sym` operands for inline assembly.
This also fixes a regression in the handling of `#[thread_local]` during monomorphization which caused link-time errors with multiple codegen units, most likely introduced by #71192.
r? @oli-obk
|
|
Track span of function in method calls, and use this in #[track_caller]
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
|
|
Handle assembler warnings properly
Previously all inline asm diagnostics were treated as errors, but LLVM sometimes emits warnings and notes as well.
Fixes #73160
r? @petrochenkov
|
|
|
|
|
|
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
|
|
Fixes more of:
clippy::unused_unit
clippy::op_ref
clippy::useless_format
clippy::needless_return
clippy::useless_conversion
clippy::bind_instead_of_map
clippy::into_iter_on_ref
clippy::redundant_clone
clippy::nonminimal_bool
clippy::redundant_closure
clippy::option_as_ref_deref
clippy::len_zero
clippy::iter_cloned_collect
clippy::filter_next
|
|
|
|
|
|
|
|
|
|
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.
|
|
Rename all remaining compiler crates to use the `rustc_foo` pattern
libarena -> librustc_arena
libfmt_macros -> librustc_parse_format
libgraphviz -> librustc_graphviz
libserialize -> librustc_serialize
Closes https://github.com/rust-lang/rust/issues/71177 in particular.
|
|
|
|
|
|
rustc: Remove the `--passive-segments` LLD flag on wasm
This flag looks like it's been removed in LLVM 10, so this removes rustc
unconditionally passing the flag.
|
|
This flag looks like it's been removed in LLVM 10, so this removes rustc
unconditionally passing the flag.
|
|
Make TLS accesses explicit in MIR
r? @rust-lang/wg-mir-opt
cc @RalfJung @vakaras for miri thread locals
cc @bjorn3 for cranelift
fixes #70685
|
|
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
| ^^^^^^^^^^^^^^^^^^^
```
|
|
|
|
|
|
Properly handle InlineAsmOperand::SymFn when collecting monomorphized items
Fixes #72484
|
|
|
|
linker: Support `-static-pie` and `-static -shared`
This PR adds support for passing linker arguments for creating statically linked position-independent executables and "statically linked" shared libraries.
Therefore it incorporates the majority of https://github.com/rust-lang/rust/pull/70740 except for the linker rerun hack and actually flipping the "`static-pie` is supported" switch for musl targets.
|
|
|
|
|
|
Pass more `Copy` types by value.
There are a lot of locations where we pass `&T where T: Copy` by reference,
which should both be slightly less performant and less readable IMO.
This PR currently consists of three fairly self contained commits:
- passes `ty::Predicate` by value and stops depending on `AsRef<ty::Predicate>`.
- changes `<&List<_>>::into_iter` to iterate over the elements by value. This would break `List`s
of non copy types. But as the only list constructor requires `T` to be copy anyways, I think
the improved readability is worth this potential future restriction.
- passes `mir::PlaceElem` by value. Mir currently has quite a few copy types which are passed by reference, e.g. `Local`. As I don't have a lot of experience working with MIR, I mostly did this to get some feedback from people who use MIR more frequently
- tries to reuse `ty::Predicate` in case it did not change in some places, which should hopefully
fix the regression caused by #72055
r? @nikomatsakis for the first commit, which continues the work of #72055 and makes adding `PredicateKind::ForAll` slightly more pleasant. Feel free to reassign though
|
|
|
|
Fixes #72484
|
|
|
|
|
