| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #123951 (Reserve guarded string literals (RFC 3593))
- #130827 (Library: Rename "object safe" to "dyn compatible")
- #131383 (Add docs about slicing slices at the ends)
- #131403 (Fix needless_lifetimes in rustc_serialize)
- #131417 (Fix methods alignment on mobile)
- #131449 (Decouple WASIp2 sockets from WasiFd)
- #131462 (Mention allocation errors for `open_buffered`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix methods alignment on mobile
I realized that on mobile, the methods are not aligned the same depending if they have documentation or not:
| before | after |
|-|-|
|  |  |
r? `@notriddle`
|
|
Reserve guarded string literals (RFC 3593)
Implementation for RFC 3593, including:
- lexer / parser changes
- diagnostics
- migration lint
- tests
We reserve `#"`, `##"`, `###"`, `####`, and any other string of four or more repeated `#`. This avoids infinite lookahead in the lexer, though we still use infinite lookahead in the parser to provide better forward compatibility diagnostics.
This PR does not implement any special lexing of the string internals:
- strings preceded by one or more `#` are denied
- regardless of the number of trailing `#`
- string contents are lexed as if it was just a bare `"string"`
Tracking issue: #123735
RFC: rust-lang/rfcs#3593
|
|
|
|
|
|
|
|
add more crash tests
r? `@jieyouxu`
|
|
Ignore broken-pipe-no-ice on apple (specifically macOS) for now
This test fails for me locally (initially reported by Zalathar) because apparently on macOS it doesn't say "internal compiler error" but it does report the std I/O panic, and it doesn't exit with a code of 101 but instead terminates with a wait signal of SIGPIPE.
Ignore this test on apple for now, until we try to actually address the underlying issue.
See https://github.com/rust-lang/rust/pull/131155 and https://github.com/rust-lang/rust/issues/131436 for more context.
|
|
Dont ICE when encountering post-mono layout cycle error
It's possible to encounter post-mono layout cycle errors in `fn_abi_of_instance`. Don't ICE in those cases.
This was originally discovered in an async fn, but that's not the only way to encounter such an error (which the other test I added should demonstrate).
Error messsages suck, but this fix is purely about suppressing the ICE.
Fixes #131409
|
|
|
|
|
|
|
|
|
|
Prevent building cargo from invalidating build cache of other tools due to conditionally applied `-Zon-broken-pipe=kill` via tracked `RUSTFLAGS`
This PR fixes #130980 where building cargo invalidated the tool build caches of other tools (such as rustdoc) because `-Zon-broken-pipe=kill` was conditionally passed via `RUSTFLAGS` for other tools *except* for cargo. The differing `RUSTFLAGS` triggered tool build cache invalidation as `RUSTFLAGS` is a tracked env var -- any changes in `RUSTFLAGS` requires a rebuild.
`-Zon-broken-pipe=kill` is load-bearing for rustc and rustdoc to not ICE on broken pipes due to usages of raw std `println!` that panics without the flag being set, which manifests in ICEs.
I can't say I like the changes here, but it is what it is...
See detailed discussions and history of `-Zon-broken-pipe=kill` usage in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F/near/474593815.
## Approach
This PR fixes the tool build cache invalidation by informing the `rustc` binary shim when to apply `-Zon-broken-pipe=kill` (i.e. when the rustc binary shim is not used to build cargo). This information is not communicated by `RUSTFLAGS`, which is an env var tracked by cargo, and instead uses an untracked env var `UNTRACKED_BROKEN_PIPE_FLAG` so we won't trigger tool build cache invalidation. We preserve bootstrap's behavior of not setting that flag for cargo by conditionally omitting setting `UNTRACKED_BROKEN_PIPE_FLAG` when building cargo.
Notably, the `-Zon-broken-pipe=kill` instance in https://github.com/rust-lang/rust/blob/1e5719bdc40bb553089ce83525f07dfe0b2e71e9/src/bootstrap/src/core/build_steps/compile.rs#L1058 is not modified because that is used to build rustc only and not cargo itself.
Thanks to `@cuviper` for the idea!
## Testing
### Integration testing
This PR introduces a run-make test for rustc and rustdoc that checks that when they do not ICE/panic when they encounter a broken pipe of the stdout stream.
I checked this test will catch the broken pipe ICE regression for rustc on Linux (at least) by commenting out https://github.com/rust-lang/rust/blob/1e5719bdc40bb553089ce83525f07dfe0b2e71e9/src/bootstrap/src/core/build_steps/compile.rs#L1058, and the test failed because rustc ICE'd.
### Manual testing
I have manually tried:
1. `./x clean && `./x test build --stage 1` -> `rustc +stage1 --print=sysroot | false`: no ICE.
2. `./x clean` -> `./x test run-make` twice: no stage 1 cargo rebuilds.
3. `./x clean` -> `./x build rustdoc` -> `rustdoc +stage1 --version | false`: no panics.
4. `./x test src/tools/cargo`: tests pass, notably `build::close_output` and `cargo_command::closed_output_ok` do not fail which would fail if cargo was built with `-Zon-broken-pipe=kill`.
## Related discussions
Thanks to everyone who helped!
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Applying.20.60-Zon-broken-pipe.3Dkill.60.20flags.20in.20bootstrap.3F
- https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Modifying.20run-make.20tests.20unnecessarily.20rebuild.20stage.201.20.2E.2E.2E
- https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F
Fixes https://github.com/rust-lang/rust/issues/130980
Closes https://github.com/rust-lang/rust/issues/131059
---
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
|
|
|
|
|
|
[Coverage][MCDC] Adapt mcdc to llvm 19
Related issue: #126672
Also finish task 4 at #124144
[llvm #82448](https://github.com/llvm/llvm-project/pull/82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
|
|
Rollup of 7 pull requests
Successful merges:
- #130824 (Add missing module flags for `-Zfunction-return=thunk-extern`)
- #131170 (Fix `target_vendor` in non-IDF Xtensa ESP32 targets)
- #131355 (Add tests for some old fixed issues)
- #131369 (Update books)
- #131370 (rustdoc: improve `<wbr>`-insertion for SCREAMING_CAMEL_CASE)
- #131379 (Fix utf8-bom test)
- #131385 (Un-vacation myself)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix utf8-bom test
The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108
I had to move the run-pass line down, because compiletest doesn't seem to know about BOMs, so it does not parse the header if it is the first line.
|
|
Add tests for some old fixed issues
Closes #30867
Closes #30472
Closes #28994
Closes #26719 (and migrates the relevant test to the new run-make)
Closes #23600
cc `@jieyouxu` for the run-make-support changes
try-job: x86_64-msvc
|
|
Add missing module flags for `-Zfunction-return=thunk-extern`
This fixes a bug in the `-Zfunction-return=thunk-extern` flag. The flag needs to be passed onto LLVM to ensure that functions such as `asan.module_ctor` and `asan.module_dtor` that are created internally in LLVM have the mitigation applied to them.
This was originally discovered [in the Linux kernel](https://lore.kernel.org/all/CANiq72myZL4_poCMuNFevtpYYc0V0embjSuKb7y=C+m3vVA_8g@mail.gmail.com/).
Original flag PR: #116892
PR for similar issue: #129373
Tracking issue: #116853
cc ``@ojeda``
r? ``@wesleywiser``
|
|
|
|
Add precondition checks to ptr::offset, ptr::add, ptr::sub
All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail.
Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`.
A crater run (https://github.com/rust-lang/rust/pull/130251#issuecomment-2395824565) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
|
|
The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108
|
|
Remove valgrind test suite and support from compiletest, bootstrap and opt-dist
The `run-pass-valgrind` test suite is not exercised in CI, and as far as I'm aware nobody runs it (asked in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Are.20the.20valgrind.20tests.20even.20used.20by.20anyone.3F). What's remaining of valgrind support in compiletest isn't even properly hooked up with bootstrap.
The existing valgrind logic in compiletest is also straight up questionable, i.e.
https://github.com/rust-lang/rust/blob/1b3b8e7b0265162853c650ead09905bc3cdaeae9/src/tools/compiletest/src/runtest/valgrind.rs#L7-L12
It just runs valgrind tests as `rpass` if no valgrind path is provided to compiletest from bootstrap -- but bootstrap doesn't even pass a valgrind path to compiletest in the first place, so this always ran as `rpass` tests. So what is this even testing?
So if it's not testing anything, let's delete it.
Closes #44816 by deleting the test suite :3
<img src="https://github.com/user-attachments/assets/99525bf7-e85b-40ba-9281-e4e1e275c4e8" width=300 />
|
|
Don't allow the `#[pointee]` attribute where it doesn't belong
Error if the `#[pointee]` attribute is applied to anything but generic type parameters.
Closes #128485
Related to #123430
|
|
|
|
|
|
|
|
Co-authored-by: Oneirical <manchot@videotron.ca>
Co-authored-by: Chris Denton <chris@chrisdenton.dev>
|
|
|
|
|
|
|
|
|
|
|
|
liballoc: introduce String, Vec const-slicing
This change `const`-qualifies many methods on `Vec` and `String`, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice`.
## Motivation
This is to support simultaneous variance over ownership and constness. I have an enum type that may contain either `String` or `&str`, and I want to produce a `&str` from it in a possibly-`const` context.
```rust
enum StrOrString<'s> {
Str(&'s str),
String(String),
}
impl<'s> StrOrString<'s> {
const fn as_str(&self) -> &str {
match self {
// In a const-context, I really only expect to see this variant, but I can't switch the implementation
// in some mode like #[cfg(const)] -- there has to be a single body
Self::Str(s) => s,
// so this is a problem, since it's not `const`
Self::String(s) => s.as_str(),
}
}
}
```
Currently `String` and `Vec` don't support this, but can without functional changes. Similar logic applies for `len`, `capacity`, `is_empty`.
## Changes
The essential thing enabling this change is that `Unique::as_ptr` is `const`. This lets us convert `RawVec::ptr` -> `Vec::as_ptr` -> `Vec::as_slice` -> `String::as_str`.
I had to move the `Deref` implementations into `as_{str,slice}` because `Deref` isn't `#[const_trait]`, but I would expect this change to be invisible up to inlining. I moved the `DerefMut` implementations as well for uniformity.
|
|
Don't use Immediate::offset to transmute pointers to integers
This applies the relatively new `assert_matches_abi` check in the `offset` operation on immediates, which makes sure that if offsets are used to alter the layout (which is possible because the field layout is arbitrarily picked by the caller), this is not done in a way that breaks the invariant of the `Immediate` type.
This leads to ICEs in a GVN mir-opt test, so the second commit fixes GVN.
Fixes https://github.com/rust-lang/rust/issues/131064.
|
|
This change `const`-qualifies many methods on Vec and String, notably
`as_slice`, `as_str`, `len`. These changes are made behind the unstable
feature flag `const_vec_string_slice` with the following tracking issue:
https://github.com/rust-lang/rust/issues/129041
|
|
|
|
add `naked_asm!` macro for use in `#[naked]` functions
tracking issue: https://github.com/rust-lang/rust/issues/90957
Adds the `core::arch::naked_asm` macro, to be used in `#[naked]` functions, but providing better error messages and a place to explain the restrictions on assembly in naked functions.
This PR does not yet require that the `naked_asm!` macro is used inside of `#[naked]` functions:
- the `asm!` macro can still be used in `#[naked]` functions currently, with the same restrictions and error messages as before.
- the `naked_asm!` macro can be used outside of `#[naked]` functions. It has not yet been decided whether that should be allowed long-term.
In this PR, the parsing code of `naked_asm!` now enforces the restrictions on assembly in naked functions, with the exception of checking that the `noreturn` option is specified. It also has not currently been decided if `noreturn` should be implicit or not.
This PR looks large because it touches a bunch of tests. The code changes are mostly straightforward I think: we now have 3 flavors of assembly macro, and that information must be propagated through the parsing code and error messages.
cc `@Lokathor`
r? `@Amanieu`
|
|
- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch
|
|
Make deprecated_cfg_attr_crate_type_name a hard error
Turns the forward compatibility lint added by #83744 into a hard error, so now, while the `#![crate_name]` and `#![crate_type]` attributes are still allowed in raw form, they are now forbidden to be nested inside a `#![cfg_attr()]` attribute.
The following will now be an error:
```Rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```
This code will continue working and is not deprecated:
```Rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```
The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.
As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.
cc #91632 - tracking issue for the lint
|
|
|
|
also disallow the `noreturn` option, and infer `naked_asm!` as `!`
|
|
|
|
|
|
|
