| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Stabilize flags for doctest cross compilation
This makes the following changes in preparation for supporting doctest cross-compiling in cargo:
- Renames `--runtool` and `--runtool-arg` to `--test-runtool` and `--test-runtool-arg` to maintain consistency with other `--test-*` arguments.
- Stabilizes the `--test-runtool` and `--test-runtool-arg`. These are needed in order to support cargo's `target.runner` option which specifies a runner to execute a cross-compiled doctest (for example, qemu).
- Stabilizes the `--enable-per-target-ignores` flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature.
These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127
The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored.
Closes https://github.com/rust-lang/rust/issues/64245
try-job: x86_64-msvc-1
|
|
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #139261 (mitigate MSVC alignment issue on x86-32)
- #140075 (Mention average in midpoint documentations)
- #140184 (Update doc of cygwin target)
- #140186 (Rename `compute_x` methods)
- #140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`)
- #140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes)
- #140214 (Remove comment about handling non-global where bounds with corresponding projection)
- #140228 (Revert overzealous parse recovery for single colons in paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`
To preserve CFI directives in assembly tests, as `//@ add-core-stubs` already imply `-C panic=abort`.
This is a blocker for https://github.com/rust-lang/rust/pull/140037#issuecomment-2816665358.
cc ```@RalfJung```
r? ```@bjorn3```
|
|
Update doc of cygwin target
Some trivial updates.
|
|
mitigate MSVC alignment issue on x86-32
This implements mitigation for https://github.com/rust-lang/rust/issues/112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems.
Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can.
Also add an errata note to the platform support page warning users about this known problem.
try-job: `i686-msvc*`
|
|
`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns
When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests).
This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1].
This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.
This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes.
The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time.
Tracking issue for deref patterns: #87121
r? ``@oli-obk``
cc ``@Nadrieril``
[^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.
|
|
|
|
|
|
`Results` contains and `Analysis` and an `EntryStates`. The unfortunate
thing about this is that the analysis needs to be mutable everywhere
(`&mut Analysis`) which forces the `Results` to be mutable everywhere,
even though `EntryStates` is immutable everywhere.
To fix this, this commit renames `Results` as `AnalysisAndResults`,
renames `EntryStates` as `Results`, and separates the analysis and
results as much as possible. (`AnalysisAndResults` doesn't get much use,
it's mostly there to facilitate method chaining of
`iterate_to_fixpoint`.)
`Results` is immutable everywhere, which:
- is a bit clearer on how the data is used,
- avoids an unnecessary clone of entry states in
`locals_live_across_suspend_points`, and
- moves the results outside the `RefCell` in Formatter.
The commit also reformulates `ResultsHandle` as the generic `CowMut`,
which is simpler than `ResultsHandle` because it doesn't need the
`'tcx` lifetime and the trait bounds. It also which sits nicely
alongside the new use of `Cow` in `ResultsCursor`.
|
|
`-Cforce-unwind-tables=yes`
|
|
|
|
|
|
Update books
## rust-lang/nomicon
1 commits in 0c10c30cc54736c5c194ce98c50e2de84eeb6e79..c76a20f0d987145dcedf05c5c073ce8d91f2e82a
2025-04-15 20:54:57 UTC to 2025-04-15 20:54:57 UTC
- Say that dereferencing a pointer to a ZST is no longer undefined (rust-lang/nomicon#467)
## rust-lang/reference
7 commits in 3340922df189bddcbaad17dc3927d51a76bcd5ed..3bf3402aea982b876eb56c87da17b0685c6461d5
2025-04-18 13:44:45 UTC to 2025-04-17 17:27:01 UTC
- Use `cfg(false)` instead of `cfg(FALSE)` (rust-lang/reference#1763)
- Add `cfg(true)` and `cfg(false)` to conditional compilation (RFC 3695) (rust-lang/reference#1762)
- Refactor rendering with `RenderCtx` (rust-lang/reference#1796)
- attributes/codegen: update aarch64 features (rust-lang/reference#1791)
- Simplify GenericParams grammar (rust-lang/reference#1795)
- Add rule identifiers for the ABI chapter (rust-lang/reference#1793)
- Remove broken footnote links from grammar summary (rust-lang/reference#1794)
|
|
|
|
rustc-dev-guide subtree update
r? ``@ghost``
|
|
r=tgross35,Amanieu,traviscross
Stabilize `naked_functions`
tracking issue: https://github.com/rust-lang/rust/issues/90957
request for stabilization on tracking issue: https://github.com/rust-lang/rust/issues/90957#issuecomment-2539270352
reference PR: https://github.com/rust-lang/reference/pull/1689
# Request for Stabilization
Two years later, we're ready to try this again. Even though this issue is already marked as having passed FCP, given the amount of time that has passed and the changes in implementation strategy, we should follow the process again.
## Summary
The `naked_functions` feature has two main parts: the `#[naked]` function attribute, and the `naked_asm!` macro.
An example of a naked function:
```rust
const THREE: usize = 3;
#[naked]
pub extern "sysv64" fn add_n(number: usize) -> usize {
// SAFETY: the validity of the used registers
// is guaranteed according to the "sysv64" ABI
unsafe {
core::arch::naked_asm!(
"add rdi, {}",
"mov rax, rdi",
"ret",
const THREE,
)
}
}
```
When the `#[naked]` attribute is applied to a function, the compiler won't emit a [function prologue](https://en.wikipedia.org/wiki/Function_prologue_and_epilogue) or epilogue when generating code for this function. This attribute is analogous to [`__attribute__((naked))`](https://developer.arm.com/documentation/100067/0608/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function.
The body of a naked function must consist of a single `naked_asm!` invocation, a heavily restricted variant of the `asm!` macro: the only legal operands are `const` and `sym`, and the only legal options are `raw` and `att_syntax`. In lieu of specifying operands, the `naked_asm!` within a naked function relies on the function's calling convention to determine the validity of registers.
## Documentation
The Rust Reference: https://github.com/rust-lang/reference/pull/1689
(Previous PR: https://github.com/rust-lang/reference/pull/1153)
## Tests
* [tests/run-make/naked-symbol-visiblity](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) verifies that `pub`, `#[no_mangle]` and `#[linkage = "..."]` work correctly for naked functions
* [tests/codegen/naked-fn](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) has tests for function alignment, use of generics, and validates the exact assembly output on linux, macos, windows and thumb
* [tests/ui/asm/naked-*](https://github.com/rust-lang/rust/tree/master/tests/ui/asm) tests for incompatible attributes, generating errors around incorrect use of `naked_asm!`, etc
## Interaction with other (unstable) features
### [fn_align](https://github.com/rust-lang/rust/issues/82232)
Combining `#[naked]` with `#[repr(align(N))]` works well, and is tested e.g. here
- https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/aligned.rs
- https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/min-function-alignment.rs
It's tested extensively because we do need to explicitly support the `repr(align)` attribute (and make sure we e.g. don't mistake powers of two for number of bytes).
## History
This feature was originally proposed in [RFC 1201](https://github.com/rust-lang/rfcs/pull/1201), filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in [#32410](https://github.com/rust-lang/rust/pull/32410), landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by [RFC 2972](https://github.com/rust-lang/rfcs/pull/2972), filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the `naked` attribute; these lints became hard errors in [#93153](https://github.com/rust-lang/rust/pull/93153) on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the `naked` attribute.
More recently, the `naked_asm!` macro was added to replace the earlier use of a heavily restricted `asm!` invocation. The `naked_asm!` name is clearer in error messages, and provides a place for documenting the specific requirements of inline assembly in naked functions.
The implementation strategy was changed to emitting a global assembly block. In effect, an extern function
```rust
extern "C" fn foo() {
core::arch::naked_asm!("ret")
}
```
is emitted as something similar to
```rust
core::arch::global_asm!(
"foo:",
"ret"
);
extern "C" {
fn foo();
}
```
The codegen approach was chosen over the llvm naked function attribute because:
- the rust compiler can guarantee the behavior (no sneaky additional instructions, no inlining, etc.)
- behavior is the same on all backends (llvm, cranelift, gcc, etc)
Finally, there is now an allow list of compatible attributes on naked functions, so that e.g. `#[inline]` is rejected with an error. The `#[target_feature]` attribute on naked functions was later made separately unstable, because implementing it is complex and we did not want to block naked functions themselves on how target features work on them. See also https://github.com/rust-lang/rust/issues/138568.
relevant PRs for these recent changes
- https://github.com/rust-lang/rust/pull/127853
- https://github.com/rust-lang/rust/pull/128651
- https://github.com/rust-lang/rust/pull/128004
- https://github.com/rust-lang/rust/pull/138570
-
### Various historical notes
#### `noreturn`
[RFC 2972](https://github.com/rust-lang/rfcs/blob/master/text/2972-constrained-naked.md) mentions that naked functions
> must have a body which contains only a single asm!() statement which:
> iii. must contain the noreturn option.
Instead of `asm!`, the current implementation mandates that the body contain a single `naked_asm!` statement. The `naked_asm!` macro is a heavily restricted version of the `asm!` macro, making it easier to talk about and document the rules of assembly in naked functions and give dedicated error messages.
For `naked_asm!`, the behavior of the `asm!`'s `noreturn` option is implicit. The `noreturn` option means that it is UB for control flow to fall through the end of the assembly block. With `asm!`, this option is usually used for blocks that diverge (and thus have no return and can be typed as `!`). With `naked_asm!`, the intent is different: usually naked funtions do return, but they must do so from within the assembly block. The `noreturn` option was used so that the compiler would not itself also insert a `ret` instruction at the very end.
#### padding / `ud2`
A `naked_asm!` block that violates the safety assumption that control flow must not fall through the end of the assembly block is UB. Because no return instruction is emitted, whatever bytes follow the naked function will be executed, resulting in truly undefined behavior. There has been discussion whether rustc should emit an invalid instruction (e.g. `ud2` on x86) after the `naked_asm!` block to at least fail early in the case of an invalid `naked_asm!`. It was however decided that it is more useful to guarantee that `#[naked]` functions NEVER contain any instructions besides those in the `naked_asm!` block.
# unresolved questions
None
r? ``@Amanieu``
I've validated the tests on x86_64 and aarch64
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #137953 (simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors)
- #139990 (transmutability: remove NFA intermediate representation)
- #140044 (rustc-dev-guide subtree update)
- #140051 (Switch exploit mitigations to mdbook footnotes)
- #140054 (docs: fix typo change from inconstants to invariants)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
replace broken links armv7-rtems-eabihf.md
Hi team , i found broken link in `src/doc/rustc/src/platform-support/armv7-rtems-eabihf.md` and replace
thanks
|
|
Put them all on the same line with just their GitHub handles to make it
very easy to copy and paste (with ctrl-shift-v!!!) the names.
We have no use for email, so I removed all the emails, we don't care
about people's full names either.
Co-authored-by: Thalia Archibald <thalia@archibald.dev>
|
|
Switch exploit mitigations to mdbook footnotes
This updates the exploit mitigations chapter in the rustc book to use the footnote feature of mdbook instead of manually implementing footnotes with HTML.
|
|
rustc-dev-guide subtree update
r? ``@ghost``
|
|
|
|
|
|
This updates the exploit mitigations chapter in the rustc book to use
the footnote feature of mdbook instead of manually implementing
footnotes with HTML.
|
|
|
|
|
|
|
|
r=tgross35,traviscross
Make `#[naked]` an unsafe attribute
tracking issue: https://github.com/rust-lang/rust/issues/138997
Per https://github.com/rust-lang/rust/pull/134213#issuecomment-2755984503, the `#[naked]` attribute is now an unsafe attribute (in any edition).
This can only be merged when the above PRs are merged, I'd just like to see if there are any CI surprises here, and maybe there is early review feedback too.
r? ``@traviscross``
|
|
support config extensions
_Copied from the `rustc-dev-guide` addition:_
>When working on different tasks, you might need to switch between different bootstrap >configurations.
>Sometimes you may want to keep an old configuration for future use. But saving raw config >values in
>random files and manually copying and pasting them can quickly become messy, especially if >you have a
>long history of different configurations.
>
>To simplify managing multiple configurations, you can create config extensions.
>
>For example, you can create a simple config file named `cross.toml`:
>
>```toml
>[build]
>build = "x86_64-unknown-linux-gnu"
>host = ["i686-unknown-linux-gnu"]
>target = ["i686-unknown-linux-gnu"]
>
>
>[llvm]
>download-ci-llvm = false
>
>[target.x86_64-unknown-linux-gnu]
>llvm-config = "/path/to/llvm-19/bin/llvm-config"
>```
>
>Then, include this in your `bootstrap.toml`:
>
>```toml
>include = ["cross.toml"]
>```
>
>You can also include extensions within extensions recursively.
>
>**Note:** In the `include` field, the overriding logic follows a right-to-left order. For example,
in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`. Also, parent extensions
always overrides the inner ones.
try-job: x86_64-mingw-2
|
|
|
|
|
|
|
|
|
|
|
|
- Rust backcompat removes the need to specify the version here
- Using these commands can result in a needless toolchain getting
downloaded, like in the case where user only has Nightly installed
|
|
|
|
|
|
add newlines between prefix/suffix chapters in SUMMARY.md
to ensure correct extraction by mdbook-i18n-helpers.
|
|
deref patterns: implement implicit deref patterns
This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter.
Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring.
Tracking issue: #87121
r? ``@Nadrieril``
|
|
|
|
Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test`
### Summary
Add a semantically meaningful directive for ignoring test *auxiliary* files. This is for auxiliary files that *participate* in actual tests but should not be built by `compiletest` (i.e. these files are involved through `mod xxx;` or `include!()` or `#[path = "xxx"]`, etc.).
### Motivation
A specialized directive like `//@ ignore-auxiliary` makes it way easier to audit disabled tests via `//@ ignore-test`.
- These support files cannot use the canonical `auxiliary/` dir because they participate in module resolution or are included, or their relative paths can be important for test intention otherwise.
Follow-up to:
- #139705
- #139783
- #139740
See also discussions in:
- [#t-compiler > Directive name for non-test aux files?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Directive.20name.20for.20non-test.20aux.20files.3F/with/512773817)
- [#t-compiler > Handling disabled `//@ ignore-test` tests](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Handling.20disabled.20.60.2F.2F.40.20ignore-test.60.20tests/with/512005974)
- [#t-compiler/meetings > [steering] 2025-04-11 Dealing with disabled tests](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/511717981)
### Remarks on remaining unconditionally disabled tests under `tests/`
After this PR, against commit 79a272c6402, only **14** remaining test files are disabled through `//@ ignore-test`:
<details>
<summary>Remaining `//@ ignore-test` files under `tests/`</summary>
```
tests/debuginfo/drop-locations.rs
4://@ ignore-test (broken, see #128971)
tests/rustdoc/macro-document-private-duplicate.rs
1://@ ignore-test (fails spuriously, see issue #89228)
tests/rustdoc/inline_cross/assoc-const-equality.rs
3://@ ignore-test (FIXME: #125092)
tests/ui/match/issue-27021.rs
7://@ ignore-test (#54987)
tests/ui/match/issue-26996.rs
7://@ ignore-test (#54987)
tests/ui/issues/issue-49298.rs
9://@ ignore-test (#54987)
tests/ui/issues/issue-59756.rs
2://@ ignore-test (rustfix needs multiple suggestions)
tests/ui/precondition-checks/write.rs
5://@ ignore-test (unimplemented)
tests/ui/precondition-checks/read.rs
5://@ ignore-test (unimplemented)
tests/ui/precondition-checks/write_bytes.rs
5://@ ignore-test (unimplemented)
tests/ui/explicit-tail-calls/drop-order.rs
2://@ ignore-test: tail calls are not implemented in rustc_codegen_ssa yet, so this causes 🧊
tests/ui/panics/panic-short-backtrace-windows-x86_64.rs
3://@ ignore-test (#92000)
tests/ui/json/json-bom-plus-crlf-multifile-aux.rs
3://@ ignore-test Not a test. Used by other tests
tests/ui/traits/next-solver/object-soundness-requires-generalization.rs
2://@ ignore-test (see #114196)
```
</details>
Of these, most are either **unimplemented**, or **spurious**, or **known-broken**. The outstanding one is `tests/ui/json/json-bom-plus-crlf-multifile-aux.rs` which I did not want to touch in *this* PR -- that aux file has load-bearing BOM and carriage returns and byte offset matters. I think those test files that require special encoding / BOM probably are better off as `run-make` tests. See #139968 for that aux file.
### Review advice
- Best reviewed commit-by-commit.
- The directive name diverged from the most voted `//@ auxiliary` because I think that's easy to confuse with `//@ aux-{crate,dir}`.
r? compiler
|
|
This improves consistency with commonly expected CLI conventions,
avoiding a common stutter people make when running tests (trying what
they expect and then having to check the docs to then user whats
accepted).
An alternative could have been to take a value, like `--capture <value>` (e.g. `pytest` does this).
Overall, we're shifting focus for features to custom test harnesses (see #134283).
Most of `pytest`s modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
By deprecating `--nocapture`, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in #134283
I'm punting for now on the naming of `RUST_TEST_NOCAPTURE`.
I feel like T-testing-devex should do a wider look at environment
variables role in lib`test` before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner
providing its own config
- Deprecate in favor of `RUST_TEST_NO_CAPTURE`
- Deprecate in favor of `RUST_TEST_CAPTURE`
Other CLI flags were evaluated for casing consistency:
- `--logfile` has the same problem but was deprecated in #134283
Fixes #133073
|
|
Rollup of 8 pull requests
Successful merges:
- #138632 (Stabilize `cfg_boolean_literals`)
- #139416 (unstable book; document `macro_metavar_expr_concat`)
- #139782 (Consistent with treating Ctor Call as Struct in liveness analysis)
- #139885 (document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book)
- #139904 (Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests)
- #139932 (transmutability: Refactor tests for simplicity)
- #139944 (Move eager translation to a method on Diag)
- #139948 (git: ignore `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
