I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit eef4363403)
I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit 092f0ca1bd)
This implementation was added recently in f12288ec26
("TryFrom<integer> for bool") but used an old feature gate and
stabilization version. Update to reflect when these were actually added.
(cherry picked from commit 02b516afd9)
Move `freeze_*` methods to `OpenOptionsExt2`
Move the unstable `freeze_last_access_time` and `freeze_last_write_time` from `OpenOptionsExt` to a new `OpenOptionsExt2` trait. This should fixrust-lang/rust#153486.
The unstable features of the `test` crate used to be default-enabled,
and manually disabled when building the beta and stable channels. Commit
dae8ea92a7 flipped that to default-disabled, only enabled for nightly
and dev channels.
However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build. Now the `test` build script makes that happen by
noticing the `MIRI_CALLED_FROM_SETUP` environment variable.
(cherry picked from commit 30d7ed4c47)
Fix mem::conjure_zst panic message to use any::type_name instead
Use `crate::any::type_name::<T>()` instead of `stringify!(T)` in the
runtime panic message of `conjure_zst` , so the actual type name (e.g.
`i32`) is shown rather than the literal string `[T]`.
Improved security section in rustdoc for `current_exe`
A few improvements to the security section of the docs about `current_exe`
0. The explanatory link <https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183> is ~~broken~~ not directly very helpful in understanding the risk.
1. It basically previously says to never trust the result, which is IMO too pessimistic to be helpful. It's worth understanding the behavior but if you have a use case to re-exec the current program, which is not uncommon, this is a reasonable way to do it.
2. The particular risk is about setuid/setgid processes that shouldn't fully trust the user that spawned them.
3. IMO the most important risk with this function is that the invoker can control argv and PATH, so I made this more explicit. (Many unixes, including Linux, don't rely on them in the implementation, but some do.)
4. The previous text about TOCTOU and races is IMO not really coherent: if an attacker can write to the location where you're going to re-exec, they can fundamentally control what program is executed. They don't need to race with your execution of current_exe, and there is no up-front check.
5. Briefly explain the pattern of CVE-2009-1894: on Linux, depending on system configuration, an attacker who can create hardlinks to the executable can potentially control `/proc/self/exe`. On modern Linux this should normally require permission to write to the executable.
I did some web research for "argv0 vulnerability" and similar terms and didn't find anything else we should be documenting here. (There are issues about argc=0 but those should be prevented by memory safety in Rust.)
I found what the link seemed to be pointing to in <https://vulners.com/cve/CVE-2009-1894>, which talks about confusing a setuid program by creating a hardlink to its exe. I think this is in very particular circumstances something people should still be concerned about: a setuid program on a machine with `fs.protected_hardlinks = 0`. I don't think this justifies warning people not to use the function at all.
cc @mgeisler
deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls
The `Eq::assert_receiver_is_total_eq` method is purely meant as an implementation detail by `#[derive(Eq)]` to add checks that all fields of the type the derive is applied to also implement `Eq`.
The method is already `#[doc(hidden)]` and has a comment saying `// This should never be implemented by hand.`.
Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255).
To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called).
This is similar to what was previously done with the `soft_unstable` lint (https://github.com/rust-lang/rust/issues/64266).
See also https://github.com/rust-lang/libs-team/issues/704.
`BTreeMap::merge` optimized
This is an optimized version of https://github.com/rust-lang/rust/pull/151981. See [ACP](https://github.com/rust-lang/libs-team/issues/739#issuecomment-3873487320) for more information on `BTreeMap::merge` does.
CC @programmerjake. Let me know what you think of how I'm using `CursorMut` and `IntoIter` here and whether the unsafe code here looks good. I decided to use `ptr::read()` and `ptr::write()` to grab the value from `CursorMut` as `V` than `&mut V`, use it within the `conflict` function, and overwrite the content of conflicting key afterward.
I know this needs some polishing, especially with refactoring some redundant looking code in a nicer way, some of which could probably just be public API methods for `CursorMut`. It does pass all the tests that I currently have for `BTreeMap::merge` (inspired from `BTreeMap::append`) though, so that's good.
ptr::replace: make calls on ZST null ptr not UB
See https://github.com/rust-lang/rust/issues/138351 for context.
We made `ptr::read` and `ptr::write` not UB on ZST null pointers. This does the same with `ptr::replace`. Since we're just adding a branch on a constant, this should come at no runtime cost.
Add try_shrink_to and try_shrink_to_fit to Vec
Adds the functions `try_shrink_to` and `try_shrink_to_fit` to Vec to allow shrinking
in environments without global OOM handling.
The implementation differs from the tracking issue as the fallible methods return
a `TryReserveError` instead of an `AllocError` as `AllocError` is unstable and does
not contain layout information.
Tracking:
- rust-lang/rust#152350
* Add try_shrink_to and try_shrink_to_fit to Vec
Both functions are required to support shrinking a vector in
environments without global OOM handling.
* Format the try_shrink functions
* Remove excess "```" from doc
* Remove `cfg(not(no_global_oom_handling))` from rawvecinner::shrink
* Fix import cmp even if no_global_oom_handling is defined
Test(lib/win/proc): Skip `raw_attributes` doctest under Win7
The current doctest for `ProcThreadAttributeListBuilder::raw_attribute` uses `CreatePseudoConsole`, which is only available on Windows 10 October 2018 Update and above. On older versions of Windows, the test fails due to trying to link against a function that is not present in the kernel32 DLL. This therefore ensures the test is still built, but not run under the Win7 target.
@rustbot label T-libs A-process A-doctests O-windows-7
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
Fixed ByteStr not padding within its Display trait when no specific alignment is mentioned
Fixesrust-lang/rust#152804. `Path`'s `Display` uses `ByteStr`'s `Display`, which is where the problem was occurring.
The issue was coming from `ByteStr` implementation of `fmt()` in this particular area:
```rust
let Some(align) = f.align() else {
return fmt_nopad(self, f);
};
let nchars: usize = self
.utf8_chunks()
.map(|chunk| {
chunk.valid().chars().count() + if chunk.invalid().is_empty() { 0 } else { 1 }
})
.sum();
let padding = f.width().unwrap_or(0).saturating_sub(nchars);
let fill = f.fill();
let (lpad, rpad) = match align {
fmt::Alignment::Left => (0, padding),
fmt::Alignment::Right => (padding, 0),
fmt::Alignment::Center => {
let half = padding / 2;
(half, half + padding % 2)
}
};
```
The docs for the align implies that `Alignment::Left`, `Alignment::Right`, `Alignment::Center` comes from `:<`, `:>`, and `:^` respectively with `align()` returning `None` if neither of those symbols are used in the formatted string. However, while padding is taken care of in the aligned cases, we could still have padding for things that don't use alignment like:
```rust
assert_eq!(format!("{:10}", Path::new("/foo/bar").display()), "/foo/bar ");
```
We shouldn't write to `f` and return from there when there's no alignment; we should also include any potential padding/filling bytes here.
r? @joboet
Simplify internals of `{Rc,Arc}::default`
This commit simplifies the internal implementation of `Default` for these two pointer types to have the same performance characteristics as before (a side effect of changes in rust-lang/rust#131460) while avoid use of internal private APIs of Rc/Arc. To preserve the same codegen as before some non-generic functions needed to be tagged as `#[inline]` as well, but otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the use of internal APIs and instead use public stable APIs where possible, even in the implementation itself.
Jake Goulding