Implement default methods for `io::Empty` and `io::Sink`
Implements default methods of `io::Read`, `io::BufRead`, and `io::Write` for `io::Empty` and `io::Sink`. These implementations are equivalent to the defaults, except in doing less unnecessary work.
`Read::read_to_string` and `BufRead::read_line` both have a redundant call to `str::from_utf8` which can't be inlined from `core` and `Write::write_all_vectored` has slicing logic which can't be simplified (See on [Compiler Explorer](https://rust.godbolt.org/z/KK6xcrWr4)). The rest are optimized to the minimal with `-C opt-level=3`, but this PR gives that benefit to unoptimized builds.
This includes an implementation of `Write::write_fmt` which just ignores the `fmt::Arguments<'_>`. This could be problematic whenever a user formatting impl is impure, but the docs do not guarantee that the args will be expanded.
Tracked in https://github.com/rust-lang/rust/issues/136756.
r? `@m-ou-se`
Remove existing AFIDT implementation
This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented.
r? oli-obk
Fixes#136286Fixes#137706Fixes#137895
Tracking:
* #133119
Revert: Add *_value methods to proc_macro lib
This reverts https://github.com/rust-lang/rust/pull/136355. That PR caused unexpected breakage:
- the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others
- rustc_lexer can no longer be published to crates.io, which impacts RA
See https://github.com/rust-lang/rust/issues/138647 for context.
Cc `@GuillaumeGomez` `@Amanieu`
rustdoc-json: Add tests for `#[repr(...)]`
Works towards #137645 and #81359
Based on #138018, but with only the test changes. CC ```@obi1kenobi```
r? ```@GuillaumeGomez```
Rollup of 7 pull requests
Successful merges:
- #138384 (Move `hir::Item::ident` into `hir::ItemKind`.)
- #138508 (Clarify "owned data" in E0515.md)
- #138531 (Store test diffs in job summaries and improve analysis formatting)
- #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly)
- #138556 (Fix ICE: attempted to remap an already remapped filename)
- #138608 (rustc_target: Add target feature constraints for LoongArch)
- #138619 (Flatten `if`s in `rustc_codegen_ssa`)
r? `@ghost`
`@rustbot` modify labels: rollup
Mangle rustc_std_internal_symbols functions
This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`.
Helps mitigate https://github.com/rust-lang/rust/issues/104707
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: x86_64-apple-1
try-job: x86_64-mingw-1
try-job: i686-mingw-1
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: test-various
try-job: armhf-gnu
Fix ICE: attempted to remap an already remapped filename
This commit fixes an internal compiler error (ICE) that occurs when
rustdoc attempts to process macros with a remapped filename. The issue
arose during macro expansion when the `--remap-path-prefix` option was
used.
Instead of passing remapped filenames through, which would trigger the
"attempted to remap an already remapped filename" panic, we now
extract the original local path from remapped filenames before
processing them.
A test case has been added to verify this behavior.
Fixes#138520
change config.toml to bootstrap.toml
Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: https://github.com/rust-lang/rust/issues/126875.
I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?
rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs`
Closes#138378
Not sure if this should bump `FORMAT_VERSION` or not. CC `@Enselic` `@LukeMathWalker` `@obi1kenobi`
r? `@GuillaumeGomez,` best reviewed commit-by-commit
Emit function declarations for functions with `#[linkage="extern_weak"]`
Currently, when declaring an extern weak function in Rust, we use the following syntax:
```rust
unsafe extern "C" {
#[linkage = "extern_weak"]
static FOO: Option<unsafe extern "C" fn() -> ()>;
}
```
This allows runtime-checking the extern weak symbol through the Option.
When emitting LLVM-IR, the Rust compiler currently emits this static as an i8, and a pointer that is initialized with the value of the global i8 and represents the nullabilty e.g.
```
`@FOO` = extern_weak global i8
`@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO`
```
This approach does not work well with CFI, where we need to attach CFI metadata to a concrete function declaration, which was pointed out in https://github.com/rust-lang/rust/issues/115199.
This change switches to emitting a proper function declaration instead of a global i8. This allows CFI to work for extern_weak functions. Example:
```
`@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO`
...
declare !type !61 !type !62 !type !63 !type !64 extern_weak void `@FOO(double)` unnamed_addr #6
```
We keep initializing the Rust internal symbol with the function declaration, which preserves the correct behavior for runtime checking the Option.
r? `@rcvalle`
cc `@jakos-sec`
try-job: test-various
mir_build: Avoid some useless work when visiting "primary" bindings
While looking over `visit_primary_bindings`, I noticed that it does a bunch of extra work to build up a collection of “user-type projections”, even though 2/3 of its call sites don't even use them. Those callers can get the same result via `thir::Pat::walk_always`.
(And it turns out that doing so also avoids creating some redundant user-type entries in MIR for some binding constructs.)
I also noticed that even when the user-type projections *are* used, the process of building them ends up eagerly cloning some nested vectors at every recursion step, even in cases where they won't be used because the current subpattern has no bindings. To avoid this, the visit method now assembles a linked list on the stack containing the information that *would* be needed to create projections, and only creates the concrete projections as needed when a primary binding is encountered.
Some relevant prior PRs:
- #55274
- 0bfe184b1a in #55937
---
There should be no user-visible change in compiler output.
Stabilize `asm_goto` feature gate
Stabilize `asm_goto` feature (tracked by #119364). The issue will remain open and be updated to track `asm_goto_with_outputs`.
Reference PR: https://github.com/rust-lang/reference/pull/1693
# Stabilization Report
This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution.
The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See https://github.com/rust-lang/rust/issues/119364#issuecomment-2316037703 and https://github.com/rust-lang/rust/pull/131544.
It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`.
Example:
```rust
unsafe {
asm!(
"jmp {}",
label {
println!("Jumped from asm!");
}
);
}
```
Tests:
- tests/ui/asm/x86_64/goto.rs
- tests/ui/asm/x86_64/goto-block-safe.stderr
- tests/ui/asm/x86_64/bad-options.rs
- tests/codegen/asm/goto.rs
Improve upvar analysis for deref of child capture
Two fixes to the heuristic I implemented in #123660. As I noted in the code:
> Luckily, if this function is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.
This indeed fixes unnecessary borrowck errors.
r? oli-obk
---
The heuristic is only valid if we deref a `&T`, not a `&mut T` or `Box<T>`, so make sure to check the type. This fixes:
```rust
struct Foo { precise: i32 }
fn mut_ref_inside_mut(f: &mut Foo) {
let x: impl AsyncFn() = async move || {
let y = &f.precise;
};
}
```
Since the capture from `f` to `&f.precise` needs to be treated as a lending borrow from the parent coroutine-closure to the child coroutine.
---
The heuristic is also valid if *any* deref projection in the child capture's projections is a `&T`, but we were only looking at the last one. This ensures that this function is considered not to be lending:
```rust
struct Foo { precise: i32 }
fn ref_inside_mut(f: &mut &Foo) {
let x: impl Fn() -> _ = async move || {
let y = &f.precise;
};
}
```
(Specifically, checking that `impl Fn() -> _` is satisfied is exercising that the coroutine is not considered to be lending.)
Currently, when declaring an extern weak function in Rust, we use the
following syntax:
```rust
unsafe extern "C" {
#[linkage = "extern_weak"]
static FOO: Option<unsafe extern "C" fn() -> ()>;
}
```
This allows runtime-checking the extern weak symbol through the Option.
When emitting LLVM-IR, the Rust compiler currently emits this static
as an i8, and a pointer that is initialized with the value of the global
i8 and represents the nullabilty e.g.
```
@FOO = extern_weak global i8
@_rust_extern_with_linkage_FOO = internal global ptr @FOO
```
This approach does not work well with CFI, where we need to attach CFI
metadata to a concrete function declaration, which was pointed out in
https://github.com/rust-lang/rust/issues/115199.
This change switches to emitting a proper function declaration instead
of a global i8. This allows CFI to work for extern_weak functions.
We keep initializing the Rust internal symbol with the function
declaration, which preserves the correct behavior for runtime checking
the Option.
Co-authored-by: Jakob Koschel <jakobkoschel@google.com>
Misc print request handling cleanups + a centralized test for print request stability gating
I was working on implementing `--print=supported-crate-types`, then I noticed some things that were mildly annoying me, so I pulled out these changes. In this PR:
- First commit adds a centralized test `tests/ui/print/stability.rs` that is responsible for exercising stability gating of the print requests.
- AFAICT we didn't have any test that systematically checks this.
- I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs` (for `--print=check-cfg`) into this test too, since `--print=check-cfg` is only `-Z unstable-options`-gated like other unstable print requests, and is not additionally feature-gated. cc ``@Urgau`` in case you have any concerns.
- Second commit alphabetically sorts the `PrintKind` enum for consistency because the `PRINT_KINDS` list (using the enum) is *already* alphabetically sorted.
- Third commit pulls out two helpers:
1. A helper `check_print_request_stability` for checking stability of print requests and the diagnostics for using unstable print requests without `-Z unstable-options`, to avoid repeating the same logic over and over.
2. A helper `emit_unknown_print_request_help` for the unknown print request diagnostics to make print request collection control flow more obvious.
- Fourth commit renames `PrintKind::{TargetSpec,AllTargetSpecs}` to `PrintKind::{TargetSpecJson,AllTargetSpecsJson}` to better reflect their actual print names, `--print={target-spec-json,all-target-specs-json}`.
r? ``@nnethercote`` (or compiler/reroll)
This commit fixes an internal compiler error (ICE) that occurs when
rustdoc attempts to process macros with a remapped filename. The issue
arose during macro expansion when the `--remap-path-prefix` option was
used.
Instead of passing remapped filenames through, which would trigger the
"attempted to remap an already remapped filename" panic, we now
extract the original local path from remapped filenames before
processing them.
A test case has been added to verify this behavior.
Fixes#138520
Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
I can't find any dedicated tests that actually exercises the stability
gating (via `-Z unstable-options`) of print requests, so here's a
dedicated one.
I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs`
into this test, because AFAICT that print request is not feature gated,
but only `-Z unstable-options`-gated just like other unstable print
requests.
