| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and
`add_extension`, where joining WTF-8 surrogate halves is impossible.
Don't convert the `str` to `OsStr`, because `OsString::push` specializes
to skip the joining when given strings.
|
|
Communicate the safety invariants of these methods with `unsafe fn`
rather than privacy.
|
|
1. analogous to std::cell::Ref(Mut)::filter_map.
2. doesn't imply `Try` genericizability.
|
|
|
|
|
|
Don't allow flattened format_args in const.
Fixes https://github.com/rust-lang/rust/issues/139136
Fixes https://github.com/rust-lang/rust/issues/139621
We allow `format_args!("a")` in const, but don't allow any format_args with arguments in const, such as `format_args!("{}", arg)`.
However, we accidentally allow `format_args!("hello {}", "world")` in const, as it gets flattened to `format_args!("hello world")`.
This also applies to panic in const.
This wasn't supposed to happen. I added protection against this in the format args flattening code, ~~but I accidentally marked a function as const that shouldn't have been const~~ but this was removed in https://github.com/rust-lang/rust/pull/135139.
This is a breaking change. The crater found no breakage, however.
This breaks things like:
```rust
const _: () = if false { panic!("a {}", "a") };
```
and
```rust
const F: std::fmt::Arguments<'static> = format_args!("a {}", "a");
```
|
|
|
|
|
|
lolbinarycat:docs-wrapping_offset-provenance-139008, r=RalfJung
mention provenance in the pointer::wrapping_offset docs
fixes https://github.com/rust-lang/rust/issues/139008
|
|
Remove backticks from `ShouldPanic::YesWithMessage`'s `TrFailedMsg`
More legible imo
```rs
#[test]
#[should_panic = "love"]
fn foo() {
assert!(1 == 2);
}
```
Before:
```
note: panic did not contain expected string
panic message: `"assertion failed: 1 == 2"`,
expected substring: `"love"`
```
After:
```
note: panic did not contain expected string
panic message: "assertion failed: 1 == 2"
expected substring: "love"
```
Also removed the comma as `assert_eq!` / `assert_ne!` don't use one.
``@rustbot`` label +A-libtest
|
|
Streamline the `format` macro.
Removing the unnecessary local variable speeds up compilation a little.
r? `@cuviper`
|
|
Move implementations to `generic/` like the other functions. This also
allows us to combine the `fma` and `fma_wide` modules.
|
|
This will not build correctly, the move is done as a separate step from
the rest of refactoring so git's history is cleaner.
|
|
These appeared in a later nightly. In compiler-builtins we can apply the
suggestion, but in `libm` we need to ignore them since `fx::from_bits`
is not `const` at the MSRV.
`clippy::uninlined_format_args` also seems to have gotten stricter, so
fix those here.
|
|
fixes https://github.com/rust-lang/rust/issues/139008
|
|
`wrapped_add` is used, not `checked_add`
|
|
unwind: bump `unwinding` dependency to 0.2.6
Xous now fails to compile under nightly, due to the recent change where `#[naked]` must now be wrapped in `unsafe(...)`. The `unwinding` crate was updated to account for this.
With the following `bootstrap.toml`:
```
profile = "library"
change-id = 138934
[build]
build-stage = 2
target = ["riscv32imac-unknown-xous-elf"]
[rust]
std-features = ["panic-unwind"]
download-rustc = false
```
The build fails when trying unwinding v0.2.5:
```
$ ./x.py build
[...]
Compiling unwinding v0.2.5
error: unsafe attribute used without unsafe
--> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.5/src/unwinder/arch/riscv32.rs:176:3
|
176 | #[naked]
| ^^^^^ usage of unsafe attribute
|
help: wrap the attribute in `unsafe(...)`
|
176 | #[unsafe(naked)]
| +++++++ +
error: could not compile `unwinding` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:06:26
$
```
This patch updates `unwinding` to v0.2.6, which now wraps all issues of `naked` in `unsafe()`.
|
|
|
|
|
|
|
|
|
|
With a recent change to the compiler, all instances of `#[naked]` must
now be wrapped in `#[unsafe(naked)]`. The `unwinding` crate, which is
used on Xous for doing unwinding in constrained environments, needed to
be updated to handle this change.
Bump the `unwinding` dependency to 0.2.6, which performs this wrapping.
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
These are unstably available in `core` and should be in `std` too, but
are not currently reexported. Resolve this here.
|
|
Rename sub_ptr to offset_from_unsigned in docs
There are still a few mentions of `sub_ptr` in comments and doc comments, which were missed in https://github.com/rust-lang/rust/pull/137483.
|
|
Implement the internal feature `cfg_target_has_reliable_f16_f128`
Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.
These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
---
The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.
try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
|
|
Stabilize `slice_as_chunks` library feature
~~Draft as this needs #139163 to land first.~~
FCP: https://github.com/rust-lang/rust/issues/74985#issuecomment-2769963395
Methods being stabilized are:
```rust
impl [T] {
const fn as_chunks<const N: usize>(&self) -> (&[[T; N]], &[T]);
const fn as_rchunks<const N: usize>(&self) -> (&[T], &[[T; N]]);
const unsafe fn as_chunks_unchecked<const N: usize>(&self) -> &[[T; N]];
const fn as_chunks_mut<const N: usize>(&mut self) -> (&mut [[T; N]], &mut [T]);
const fn as_rchunks_mut<const N: usize>(&mut self) -> (&mut [T], &mut [[T; N]]);
const unsafe fn as_chunks_unchecked_mut<const N: usize>(&mut self) -> &mut [[T; N]];
}
```
~~(FCP's not done quite yet, but will in another day if I'm counting right.)~~ FCP Complete: https://github.com/rust-lang/rust/issues/74985#issuecomment-2797951535
|
|
|
|
Async drop codegen
Async drop implementation using templated coroutine for async drop glue generation.
Scopes changes to generate `async_drop_in_place()` awaits, when async droppable objects are out-of-scope in async context.
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md
New fields in Drop terminator (drop & async_fut). Processing in codegen/miri must validate that those fields are empty (in full version async Drop terminator will be expanded at StateTransform pass or reverted to sync version). Changes in terminator visiting to consider possible new successor (drop field).
ResumedAfterDrop messages for panic when coroutine is resumed after it is started to be async drop'ed.
Lang item for generated coroutine for async function async_drop_in_place. `async fn async_drop_in_place<T>()::{{closure0}}`.
Scopes processing for generate async drop preparations. Async drop is a hidden Yield, so potentially async drops require the same dropline preparation as for Yield terminators.
Processing in StateTransform: async drops are expanded into yield-point. Generation of async drop of coroutine itself added.
Shims for AsyncDropGlueCtorShim, AsyncDropGlue and FutureDropPoll.
```rust
#[lang = "async_drop"]
pub trait AsyncDrop {
#[allow(async_fn_in_trait)]
async fn drop(self: Pin<&mut Self>);
}
impl Drop for Foo {
fn drop(&mut self) {
println!("Foo::drop({})", self.my_resource_handle);
}
}
impl AsyncDrop for Foo {
async fn drop(self: Pin<&mut Self>) {
println!("Foo::async drop({})", self.my_resource_handle);
}
}
```
First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.
`async_drop_in_place` changed to be `async fn`. So both `async_drop_in_place` ctor and produced coroutine have their lang items (`AsyncDropInPlace`/`AsyncDropInPlacePoll`) and shim instances (`AsyncDropGlueCtorShim`/`AsyncDropGlue`).
```
pub async unsafe fn async_drop_in_place<T: ?Sized>(_to_drop: *mut T) {
}
```
AsyncDropGlue shim generation uses `elaborate_drops::elaborate_drop` to produce drop ladder (in the similar way as for sync drop glue) and then `coroutine::StateTransform` to convert function into coroutine poll.
AsyncDropGlue coroutine's layout can't be calculated for generic T, it requires known final dropee type to be generated (in StateTransform). So, `templated coroutine` was introduced here (`templated_coroutine_layout(...)` etc).
Such approach overrides the first implementation using mixing language-level futures in https://github.com/rust-lang/rust/pull/121801.
|
|
|
|
async_drop_in_place::{closure}, scoped async drop added.
|
|
Move the public `CommandEnvs` into the `process` module (and make it a wrapper type for an internal iterator type) and everything else into `sys::process` as per #117276.
|
|
r=jdonszelmann,traviscross
Implement a lint for implicit autoref of raw pointer dereference - take 2
*[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)*
This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305.
The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.
```rust
pub struct Test {
data: [u8],
}
pub fn test_len(t: *const Test) -> usize {
unsafe { (*t).data.len() } // this calls <[T]>::len(&self)
}
```
Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.
----
Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:
1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with `#[rustc_no_implicit_refs]`.
3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details.
There are several points that are not 100% clear to me when implementing the modifications:
- ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed
- Are "index" and "field" enough?
----
cc `@JakobDegen` `@WaffleLapkin`
r? `@RalfJung`
try-job: dist-various-1
try-job: dist-various-2
|
|
Create `Atomic<T>` type alias (rebase)
Rebase of #130543.
Additional changes:
- Switch from `allow` to `expect` for `private_bounds` on `AtomicPrimitive`
- Unhide `AtomicPrimitive::AtomicInner` from docs, because rustdoc shows the definition `pub type Atomic<T> = <T as AtomicPrimitive>::AtomicInner;` and generated links for it.
- `NonZero` did not have this issue, because they kept the new alias private before the direction was changed.
- Use `Atomic<_>` in more places, including inside `Once`'s `Futex`. This is possible thanks to https://github.com/rust-lang/rust-clippy/pull/14125
The rest will either get moved back to #130543 or #130543 will be closed in favor of this instead.
---
* ACP: https://github.com/rust-lang/libs-team/issues/443#event-14293381061
* Tracking issue: #130539
|
|
specify explicit safety guidance for from_utf8_unchecked
The PR addresses missing safety guidelines in two APIs by adding explicit text to the cross-linked reference.
|
|
docs: fix incorrect stability markers on `std::{todo, matches}`
This regression appeared in 916cfbcd3ed95a737b5a62103bbc4118ffe1eb2b. The change is behaving as expected (a non-glob re-export uses the stability marker on the `use` item, not the original one), but this part of the standard library didn't follow it.
Fixes https://github.com/rust-lang/rust/issues/140344
|
|
std(docs): clarify how std::fs::set_permisions works with symlinks
fixes https://github.com/rust-lang/rust/issues/75942
fixes https://github.com/rust-lang/rust/issues/124201
|
|
fix(test): Expose '--no-capture' in favor of `--nocapture`
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.
I expect we'll warn about `--nocapture` being deprecated in the future after a sufficient transition period has been allowed.
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
Regarding the implementation, I moved `--nocapture` out of `optgroups()`, into `parse_opts()`, out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.
Note: `compiletest` added `--no-capture` instead of `--nocapture` in #134809
T-testing-devex FCP: https://github.com/rust-lang/rust/issues/133073#issuecomment-2486921104
Fixes #133073
|
|
Add `Arc::is_unique`
Adds
```rs
impl<T> Arc<T> {
pub fn is_unique(this: &Self) -> bool;
}
```
Tracking issue: #138938
ACP: https://github.com/rust-lang/libs-team/issues/560
|
|
uefi: Update r-efi
- Bump up the version to 5.2.0
try-job: x86_64-gnu-distcheck
try-job: x86_64-gnu
try-job: test-various
|
|
Removing the unnecessary local variable speeds up compilation a little.
|
|
New compiler configuration has been introduced that is designed to
replace the build script configuration `reliable_f16`, `reliable_f128`,
`reliable_f16_math`, and `reliable_f128_math`. Do this replacement here,
which allows us to clean up `std`'s build script.
All tests are gated by `#[cfg(bootstrap)]` rather than doing a more
complicated `cfg(bootstrap)` / `cfg(not(bootstrap))` split since the
next beta split is within two weeks.
|
|
|
|
|
|
Update example to use CStr::to_string_lossy
|
|
fix docs for `Peekable::next_if{_eq}`
These seem like copy-paste errors
(except `saves the value of` 👉 `retains` which just sounds better to me)
|
|
Use char::is_whitespace directly in str::trim*
Use the method directly instead of wrapping it in a closure.
|
|
Update safety documentation for `CString::from_ptr` and `str::from_boxed_utf8_unchecked`
## PR Description
This PR addresses missing safety documentation for two APIs:
**1. alloc::ffi::CStr::from_raw**
- `Alias`: The pointer must not be aliased (accessed via other pointers) during the reconstructed CString's lifetime.
- `Owning`: Calling this function twice on the same pointer and creating two objects with overlapping lifetimes, introduces two alive owners of the same memory. This may result in a double-free.
- `Dangling`: The prior documentation required the pointer to originate from CString::into_raw, but this constraint is incomplete. A validly sourced pointer can also cause undefined behavior (UB) if it becomes dangling. A simple Poc for this situation:
```
use std::ffi::CString;
use std::os::raw::c_char;
fn create_dangling() -> *mut c_char {
let local_ptr: *mut c_char = {
let valid_data = CString::new("valid").unwrap();
valid_data.into_raw()
};
unsafe {
let _x = CString::from_raw(local_ptr);
}
local_ptr
}
fn main() {
let dangling = create_dangling();
unsafe {let _y = CString::from_raw(dangling);} // Cause UB!
}
```
**2. alloc::str::from_boxed_utf8_unchecked**
- `ValidStr`: Bytes must contain a valid UTF-8 sequence.
|
|
Stabilise `std::ffi::c_str`
This finished FCP in #112134 but never actually got a stabilisation PR. Since the FCP in #120048 recently passed to add the `os_str` module, it would be nice to also merge this too, to ensure that both get added in the next version.
Note: The added stability attributes which *somehow* were able to be omitted before (rustc bug?) were added based on the fact that they were added in 302551388b1942bb4216bb5a15d9d55cee3643a8, which ended up in 1.85.0.
Closes: https://github.com/rust-lang/rust/issues/112134
r? libs-api
|
|
|
