FCW Lint when using an ambiguously glob imported trait
Related to rust-lang/rust#147992.
Report a lint when using an ambiguously glob import trait, this is a FCW because this should not be allowed.
r? @petrochenkov
Stabilize `-Zremap-path-scope`
# Stabilization report of `--remap-path-scope`
## Summary
RFC 3127 trim-paths aims to improve the current status of sanitizing paths emitted by the compiler via the `--remap-path-prefix=FROM=TO` command line flag, by offering a profile setting named `trim-paths` in Cargo to sanitize absolute paths introduced during compilation that may be embedded in the compiled binary executable or library.
As part of that RFC the compiler was asked to add the `--remap-path-scope` command-line flag to control the scoping of how paths get remapped in the resulting binary.
Tracking:
- https://github.com/rust-lang/rust/issues/111540
### What is stabilized
The rustc `--remap-path-scope` flag is being stabilized by this PR. It defines which scopes of paths should be remapped by `--remap-path-prefix`.
This flag accepts a comma-separated list of values and may be specified multiple times, in which case the scopes are aggregated together.
The valid scopes are:
- `macro` - apply remappings to the expansion of `std::file!()` macro. This is where paths in embedded panic messages come from
- `diagnostics` - apply remappings to printed compiler diagnostics
- `debuginfo` - apply remappings to debug informations
- `coverage` - apply remappings to coverage informations
- `object` - apply remappings to all paths in compiled executables or libraries, but not elsewhere. Currently an alias for `macro,coverage,debuginfo`.
- `all` (default) - an alias for all of the above, also equivalent to supplying only `--remap-path-prefix` without `--remap-path-scope`.
#### Example
```sh
# With `object` scope only the build outputs will be remapped, the diagnostics won't be remapped.
rustc --remap-path-prefix=$(PWD)=/remapped --remap-path-scope=object main.rs
```
### What isn't stabilized
None of the Cargo facility is being stabilized in this stabilization PR, only the `--remap-path-scope` flag in `rustc` is being stabilized.
## Design
### RFC history
- [RFC3127 - trim-paths](https://rust-lang.github.io/rfcs/3127-trim-paths.html)
### Answers to unresolved questions
> What questions were left unresolved by the RFC? How have they been answered? Link to any relevant lang decisions.
There are no unresolved questions regarding `--remap-path-scope`.
(The tracking issue list a bunch of unresolved questions but they are for `--remap-path-prefix` or the bigger picture `trim-paths` in Cargo and are not related the functionality provided by `--remap-path-scope`.)
### Post-RFC changes
The RFC described more scopes, in particularly regarding split debuginfo. Those scopes where removed after analysis by `michaelwoerister` of all the possible combinations in https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274.
### Nightly extensions
There are no nightly extensions.
### Doors closed
We are committing to having to having a flag that control which paths are being remapped based on a "scope".
## Feedback
### Call for testing
> Has a "call for testing" been done? If so, what feedback was received?
No call for testing has been done per se but feedback has been received on both the rust-lang/rust and rust-lang/cargo tracking issue.
The feedback was mainly related to deficiencies in *our best-effort* `--remap-path-prefix` implementation, in particular regarding linkers added paths, which does not change anything for `--remap-path-scope`.
### Nightly use
> Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative.
Except for Cargo unstable `trim-paths` there doesn't appear any committed use [on GitHub](https://github.com/search?q=%22--remap-path-scope%22+NOT+path%3A%2F%5Esrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F+NOT+path%3A%2F%5Etext%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Ecollector%5C%2Fcompile-benchmarks%5C%2Fcargo-0%5C.87%5C.1%5C%2Fsrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F&type=code).
## Implementation
### Major parts
- b3f8586fb1/compiler/rustc_session/src/config.rs (L1373-L1384)
- b3f8586fb1/compiler/rustc_session/src/session.rs (L1526)
- b3f8586fb1/compiler/rustc_span/src/lib.rs (L352-L372)
### Coverage
- [`tests/run-make/split-debuginfo/rmake.rs`](9725c4baac/tests/run-make/split-debuginfo/rmake.rs (L7))
- [`tests/ui/errors/remap-path-prefix.rs`](9725c4baac/tests/ui/errors/remap-path-prefix.rs (L4))
- [`tests/ui/errors/remap-path-prefix-macro.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-macro.rs (L1-L4))
- [`tests/run-make/remap-path-prefix-dwarf/rmake.rs
`](9725c4baac/tests/run-make/remap-path-prefix-dwarf/rmake.rs)
- [`tests/run-make/remap-path-prefix/rmake.rs`](9725c4baac/tests/run-make/remap-path-prefix/rmake.rs)
- [`tests/ui/errors/remap-path-prefix-diagnostics.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-diagnostics.rs)
### Outstanding bugs
> What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not.
There are no outstanding bugs regarding `--remap-path-scope`.
### Outstanding FIXMEs
> What FIXMEs are still in the code for that feature and why is it OK to leave them there?
There are no FIXME regarding `--remap-path-scope` in it-self.
### Tool changes
> What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues.
- rustdoc (both JSON, HTML and doctest)
- `rustdoc` has support for `--remap-path-prefix`, it should probably also get support for `--remap-path-scope`, although rustdoc maybe want to adapt the scopes for it's use (replace `debuginfo` with `documentation` for example).
## History
> List issues and PRs that are important for understanding how we got here.
- https://github.com/rust-lang/rust/pull/115214
- https://github.com/rust-lang/rust/pull/122450
- https://github.com/rust-lang/rust/pull/139550
- https://github.com/rust-lang/rust/pull/140716
## Acknowledgments
> Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this *not* think it should be stabilized right now? We'd like to hear about that if so.
- @cbeuw
- @michaelwoerister
- @weihanglo
- @Urgau
@rustbot labels +T-compiler +needs-fcp +F-trim-paths
r? @davidtwco
Add scalar support for offload
This PR adds scalar support to the offload feature. The scalar management has two main parts:
On the host side, each scalar arg is casted to `ix` type, zero extended to `i64` and passed to the kernel like that.
On the device, the each scalar arg (`i64` at that point), is truncated to `ix` and then casted to the original type.
r? @ZuseZ4
compiler: upgrade to hashbrown 0.16.1
See also rust-lang/rust#135634, rust-lang/rust#149159, and rust-lang/hashbrown#662.
This includes an in-tree upgrade of `indexmap` as well, which uses the
new `HashTable` buckets API internally, hopefully impacting performance
for the better.
And finally, we can remove `#[rustc_unsafe_specialization_marker]` on `Copy`!
cc @joboet
r? @Amanieu
Remove `DiagMessage::Translated` in favour of `DiagMessage::Str`
This variant did not seem to be meaningfully different from `DiagMessage::Str`.
Am I missing something or was this just an oversight?
r? @davidtwco
THIR patterns: Use `ty::Value` in more places throughout `const_to_pat`
This PR changes `ConstToPat::valtree_to_pat` to take a `ty::Value` instead of separate type and valtree arguments, and propagates that change throughout other parts of the overall `const_to_pat` implementation.
The biggest under-the-hood change is that instead of combining valtrees from the constant with child types from the parent type, we now just rely on the types already embedded in children of the valtree.
I'm not *entirely* sure that this is correct, but it doesn't seem to cause any failures in the test suite, and from what I can tell the old way was a holdover from a time when the types weren't readily available from the value side.
---
My ulterior motive for this cleanup is that I'm hoping to eventually add some extra data to `thir::PatKind::Const`, which will be a little easier if creation of that `PatKind::Const` doesn't have to assemble a `ty::Value` from component parts.
HIR typeck cleanup: clarify and re-style `check_expr_unop`
Two small cleanups:
- The `oprnd_t` variable was previously used both for the type of unary operators' operands and for the type of the operator expression as a whole. I found this confusing, so I've changed it to only be used for the operand type. This also allowed for removing some negations from `if` conditions.
- I did a bit of re-styling in the second commit to remove some indentation levels, which also means fewer things have to be spread across multiple lines. This part is more to-taste; I'd be fine dropping it if it doesn't actually help.
Do not recover from `Trait()` if generic list is unterminated
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Fixrust-lang/rust#141436.
Support pointers in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting pointers `*const T` and `*mut T` through type reflection. It does so by adding the new `Pointer` struct + variant:
```rust
pub struct Pointer {
/// The type of the value being pointed to.
pub ty: TypeId,
/// Whether this pointer is mutable or not.
pub mutable: bool,
}
```
This can be gathered using `Type::of`, for example:
```rust
match const { Type::of::<*const u8>() }.kind {
TypeKind::Pointer(pointer) => {
assert_eq!(pointer.ty, TypeId::of::<u8>());
assert!(!pointer.mutable);
}
_ => unreachable!(),
}
```
Simplify some literal-value negations with `u128::wrapping_neg`
- Calling `overflowing_neg` and then discarding the overflow bit is the same as just calling `wrapping_neg`.
- Casting to `u128` to `i128`, negating, and then casting back produces the same result as just performing an unsigned `wrapping_neg`.
There should be no actual change to compiler behaviour.
rustc_errors: Add (heuristic) Syntax Highlighting for `rustc --explain`
This PR adds a feature that enables `rustc --explain <error>` to have syntax highlighted code blocks. Due to performance, size and complexity constraints, the highlighter is very heuristc, relying on conventions for capitalizations and such to infer what an identifier represents. The details for the implementation are specified below.
# Changes
1. Change `term::entrypoint` to `term::entrypoint_with_formatter`, which takes an optional third argument, which is a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
2. Change `MdStream::write_anstream_buf` to be a wrapper around a new function, `MdStream::write_anstream_buf_with_formatter`, which takes a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
3. Change [`compiler/rustc_driver_impl/src/lib.rs`](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-39877a2556ea309c89384956740d5892a59cef024aa9473cce16bbdd99287937) to call `MdStream::write_anstream_buf_with_formatter` instead of `MdStream::write_anstream_buf`.
4. Add a `compiler/rustc_driver_impl/src/highlighter.rs` file, which contains the actual syntax highlighter.
# Implementation Details
1. The highlighter starts from the `highlight` function defined in `compiler/rustc_driver_impl/src/highlighter.rs`. It creates a new instance of the `Highlighter` struct, and calls its `highlight_rustc_lexer` function to start highlighting.
2. The `highlight_rustc_lexer` function uses `rustc_lexer` to lex the code into `Token`s. `rustc_lexer` was chosen since it preserves the newlines after scanning.
3. Based on the kind of token (`TokenKind`), we color the corresponding lexeme.
## Highlighter Implementation
### Identifiers
1. All identifiers that match a (non-exhaustive and minimal) list of keywords are coloured magenta.
2. An identifier that begins with a capital letter is assumed as a type. There is no distinction between a `Trait` and a type, since that would involve name resolution, and the parts of `rustc` that perform name resolution on code do not preserve the original formatting. (An attempt to use `rustc_parse`'s lexer and `TokenStream` was made, which was then printed with the pretty printer, but failed to preserve the formatting and was generally more complex to work with)
3. An identifier that is immediately followed by a parenthesis is recognized as a function identifier, and coloured blue.
## Literals
5. A `String` literal (or its corresponding `Raw`, `C` and `Byte` versions) is colored green.
6. All other literals are colored bright red (orange-esque)
## Everything Else
Everything else is colored bright white and dimmed, to create a grayish colour.
---
# Demo
<img width="1864" height="2136" alt="image" src="https://github.com/user-attachments/assets/b17d3a71-e641-4457-be85-5e5b1cea2954" />
<caption> Command: <code>rustc --explain E0520</code> </caption>
---
This description was not generated by an LLM (:p)
cc: @bjorn3
Remove the diagnostic lints
Removes the `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints
These lints are allowed for a while already. Per https://github.com/rust-lang/compiler-team/issues/959, we no longer want to enforce struct diagnostics for all usecases, so this is no longer useful.
r? @Kivooeo
I recommend reviewing commit by commit (also feel free to wait with reviewing until the MCP is accepted)
@rustbot +S-blocked
Blocked by https://github.com/rust-lang/compiler-team/issues/959
Ignore `#[doc(hidden)]` items when computing trimmed paths for printing
The `trimmed_def_paths` query examines all items in the current crate, and all pub items in immediate-dependency crates (including the standard library), to see which item names are unique and can therefore be printed unambiguously as a bare name without a module path.
Currently that query has no special handling for `#[doc(hidden)]` items, which has two consequences:
- Hidden names can be considered unique, and will therefore be printed without a path, making it hard to find where that name is defined (since it normally isn't listed in documentation).
- Hidden names can conflict with visible names that would otherwise be considered unique, causing diagnostics to mysteriously become more verbose based on internal details of other crates.
This PR therefore makes the `trimmed_def_paths` query ignore external-crate items that are `#[doc(hidden)]`, along with their descendants.
As a result, hidden item names are never considered unique for trimming, and no longer interfere with visible item names being considered unique.
---
- Fixes https://github.com/rust-lang/rust/issues/148387.
This commit adds a heuristics-based syntax highlighter for the `rustc
--explain` command. It uses `rsutc_lexer`'s lexer to parse input in
tokens, and matches on them to determine their color.
compiler: Temporarily re-export `assert_matches!` to reduce stabilization churn
https://github.com/rust-lang/rust/pull/137487 proposes to stabilize `feature(assert_matches)`, while simultaneously moving the `assert_matches!` and `debug_assert_matches!` macros out of the `std::assert_matches` submodule and exporting them directly from the `std` crate root instead.
Unfortunately, that moving step would cause a lot of `cfg(bootstrap)` churn and noise in the compiler, because the compiler imports and uses those macros in dozens of places.
This PR therefore aims to reduce the overall compiler churn, by temporarily adjusting the compiler to always use `assert_matches!` via a re-export from `rustc_data_structures`. That way, the stabilization itself would only need to add `cfg(bootstrap)` to that single re-export (plus the associated `#![feature(assert_matches)]` attributes), greatly reducing the immediate impact on the compiler.
Once `assert_matches!` is stable in the stage0 bootstrap compiler, we can go back and delete the re-export, and adjust the rest of the compiler to import directly from `std` instead.
Generate openmp metadata
LLVM has an openmp-opt pass, which is part of the default O3 pipeline.
The pass bails if we don't have a global called openmp, so let's generate it if people enable our experimental offload feature. openmp is a superset of the offload feature, so they share optimizations.
In follow-up PRs I'll start verifying that LLVM optimizes Rust the way we want it.
r? compiler
New MIR Pass: SsaRangePropagation
As an alternative to https://github.com/rust-lang/rust/pull/150192.
Introduces a new pass that propagates the known ranges of SSA locals.
We can know the ranges of SSA locals at some locations for the following code:
```rust
fn foo(a: u32) {
let b = a < 9;
if b {
let c = b; // c is true since b is whitin the range [1, 2)
let d = a < 8; // d is true since b whitin the range [0, 9)
}
}
```
This PR only implements a trivial range: we know one value on switch, assert, and assume.
Port rustc allocator attributes to attribute parser
Tracking issue: rust-lang/rust#131229
Made a new file since i saw this pattern for `rustc_dump.rs`
Very simple attributes so felt like I can do them all in one PR
r? @JonathanBrouwer
