| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Bump bootstrap compiler to 1.61.0 beta
This PR bumps the bootstrap compiler to the 1.61.0 beta. The first commit changes the stage0 compiler, the second commit applies the "mechanical" changes and the third and fourth commits apply changes explained in the relevant comments.
r? `@Mark-Simulacrum`
|
|
Update libc to 0.2.121
With the updated libc, UNIX stack overflow handling in libstd can now
use the common `si_addr` accessor function, rather than attempting to
use a field from that name in `siginfo_t`. This simplifies the
collection of the fault address, particularly on platforms where that
data resides within a union in `siginfo_t`.
|
|
Don't cast thread name to an integer for prctl
`libc::prctl` and the `prctl` definitions in glibc, musl, and the kernel headers are C variadic functions. Therefore, all the arguments (except for the first) are untyped. It is only the Linux man page which says that `prctl` takes 4 `unsigned long` arguments. I have no idea why it says this.
In any case, the upshot is that we don't need to cast the pointer to an integer and confuse Miri.
But in light of this... what are we doing with those three `0`s? We're passing 3 `i32`s to `prctl`, which doesn't fill me with confidence. The man page says `unsigned long` and all the constants in the linux kernel are macros for expressions of the form `1UL << N`. I'm mostly commenting on this because looks a whole lot like some UB that was found in SQLite a few years ago: <https://youtu.be/LbzbHWdLAI0?t=1925> that was related to accidentally passing a 32-bit value from a literal `0` instead of a pointer-sized value. This happens to work on x86 due to the size of pointers and happens to work on x86_64 due to the calling convention. But also, there is no good reason for an implementation to be looking at those arguments. Some other calls to `prctl` require that other arguments be zeroed, but not `PR_SET_NAME`... so why are we even passing them?
I would prefer to end such questions by either passing 3 `libc::c_ulong`, or not passing those at all, but I'm not sure which is better.
|
|
Stabilize Stdin::lines.
Closes https://github.com/rust-lang/rust/issues/87096
Fcp completed here: https://github.com/rust-lang/rust/issues/87096#issuecomment-1028792980
|
|
|
|
|
|
|
|
Fix unsound `File` methods
This is a draft attempt to fix #81357. *EDIT*: this PR now tackles `read()`, `write()`, `read_at()`, `write_at()` and `read_buf`. Still needs more testing though.
cc `@jstarks,` can you confirm the the Windows team is ok with the Rust stdlib using `NtReadFile` and `NtWriteFile`?
~Also, I'm provisionally using `CancelIo` in a last ditch attempt to recover but I'm not sure that this is actually a good idea. Especially as getting into this state would be a programmer error so aborting the process is justified in any case.~ *EDIT*: removed, see comments.
|
|
Rollup of 8 pull requests
Successful merges:
- #88025 (ScmCredentials netbsd implementation.)
- #95473 (track individual proc-macro expansions in the self-profiler)
- #95547 (caution against ptr-to-int transmutes)
- #95585 (Explain why `&T` is cloned when `T` is not `Clone`)
- #95591 (Use revisions to track NLL test output (part 1))
- #95663 (diagnostics: give a special note for unsafe fn / Fn/FnOnce/FnMut)
- #95673 (:arrow_up: rust-analyzer)
- #95681 (resolve: Fix resolution of empty paths passed from rustdoc)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
ScmCredentials netbsd implementation.
|
|
Replace Linux Mutex and Condvar with futex based ones.
Tracking issue: https://github.com/rust-lang/rust/issues/93740
|
|
With the updated libc, UNIX stack overflow handling in libstd can now
use the common `si_addr` accessor function, rather than attempting to
use a field from that name in `siginfo_t`. This simplifies the
collection of the fault address, particularly on platforms where that
data resides within a union in `siginfo_t`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Windows: Synchronize asynchronous pipe reads and writes
On Windows, the pipes used for spawned processes are opened for asynchronous access but `read` and `write` are done using the standard methods that assume synchronous access. This means that the buffer (and variables on the stack) may be read/written to after the function returns.
This PR ensures reads/writes complete before returning. Note that this only applies to pipes we create and does not affect the standard file read/write methods.
Fixes #95411
|
|
Stabilize total_cmp
Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599
|
|
stabilize windows_process_extensions_raw_arg
Stabilizes the feature tracked at https://github.com/rust-lang/rust/issues/92939
|
|
|
|
|
|
|
|
|
|
|
|
libc::prctl and the prctl definitions in glibc, musl, and the kernel
headers are C variadic functions. Therefore, all the arguments (except
for the first) are untyped. It is only the Linux man page which says
that prctl takes 4 unsigned long arguments. I have no idea why it says
this.
In any case, the upshot is that we don't need to cast the pointer to an
integer and confuse Miri.
|
|
Refer to u8 by absolute path in expansion of thread_local
The standard library's `thread_local!` macro previously referred to `u8` just as `u8`, resolving to whatever `u8` existed in the type namespace at the call site. This PR replaces those with `$crate::primitive::u8` which always refers to `std::primitive::u8` regardless of what's in scope at the call site. Unambiguously naming primitives inside macro-generated code is the reason that std::primitive was introduced in the first place.
<details>
<summary>Here is the error message prior to this PR ⬇️</summary>
```console
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected struct `u8`, found integer
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_expected struct `u8`, found integer
| this expression has type `u8`
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected `u8`, found struct `u8`
|
= note: expected raw pointer `*mut u8` (`u8`)
found raw pointer `*mut u8` (struct `u8`)
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected `u8`, found struct `u8`
|
= note: expected fn pointer `unsafe extern "C" fn(*mut u8)`
found fn item `unsafe extern "C" fn(*mut u8) {destroy}`
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_expected struct `u8`, found integer
| expected due to this type
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0369]: binary operation `==` cannot be applied to type `u8`
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_u8
| {integer}
|
note: an implementation of `PartialEq<_>` might be missing for `u8`
--> src/main.rs:4:1
|
4 | struct u8;
| ^^^^^^^^^^ must implement `PartialEq<_>`
= note: this error originates in the macro `$crate::assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `u8` with `#[derive(PartialEq)]`
|
4 | #[derive(PartialEq)]
|
error[E0277]: `u8` doesn't implement `Debug`
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ `u8` cannot be formatted using `{:?}`
|
= help: the trait `Debug` is not implemented for `u8`
= note: add `#[derive(Debug)]` to `u8` or manually `impl Debug for u8`
= note: this error originates in the macro `$crate::assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
```
</details>
|
|
Remove need for associated_type_bounds in std.
|
|
|
|
|
|
Fix `thread_local!` macro to be compatible with `no_implicit_prelude`
Fixes issue #95533.
|
|
Handle rustc_const_stable attribute in library feature collector
The library feature collector in [compiler/rustc_passes/src/lib_features.rs](https://github.com/rust-lang/rust/blob/551b4fa395fa588d91cbecfb0cdfe1baa02670cf/compiler/rustc_passes/src/lib_features.rs) has only been looking at `#[stable(…)]`, `#[unstable(…)]`, and `#[rustc_const_unstable(…)]` attributes, while ignoring `#[rustc_const_stable(…)]`. The consequences of this were:
- When any const feature got stabilized (changing one or more `rustc_const_unstable` to `rustc_const_stable`), users who had previously enabled that unstable feature using `#![feature(…)]` would get told "unknown feature", rather than rustc's nicer "the feature … has been stable since … and no longer requires an attribute to enable".
This can be seen in the way that https://github.com/rust-lang/rust/pull/93957#issuecomment-1079794660 failed after rebase:
```console
error[E0635]: unknown feature `const_ptr_offset`
--> $DIR/offset_from_ub.rs:1:35
|
LL | #![feature(const_ptr_offset_from, const_ptr_offset)]
| ^^^^^^^^^^^^^^^^
```
- We weren't enforcing that a particular feature is either stable everywhere or unstable everywhere, and that a feature that has been stabilized has the same stabilization version everywhere, both of which we enforce for the other stability attributes.
This PR updates the library feature collector to handle `rustc_const_stable`, and fixes places in the standard library and test suite where `rustc_const_stable` was being used in a way that does not meet the rules for a stability attribute.
|
|
|
|
|
|
|
|
|
|
Fixes issue #95533
|
|
|
|
Clean up, categorize and sort unstable features in std.
|
|
|
|
|
|
Fix library/std compilation on openbsd.
Fix a minor typo from #95241 which prevented compilation on x86_64-unknown-openbsd.
|
|
|
|
Stabilize thread::is_finished
Closes #90470.
r? `@m-ou-se`
|
|
|
|
|
|
|
