Rust 1.73.0 #51
Closed
Rust 1.73.0 #51
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the current documentation, it's not specified that when creating
a Command, the .exe extension can be omitted for Windows executables.
However, for other types of executable files like .bat or .cmd,
the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()`
succeeds on my machine while `Command::new("code").spawn().unwrap()`
panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in a comment[1], but it
makes sense to mention it at more visible place.
I've added this clarification to the documentation, which should
make it more accurate and helpful for Rust developers
working on the Windows platform.
[1] https://github.com/rust-lang/rust/blob/e7fda447e7d05b6ca431fc8fe8f489b1fda810bc/library/std/src/sys/windows/process.rs#L425
Implement rust-lang/compiler-team#578. When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
…=ChrisDenton
Update documentation for std::process::Command's new method
In the current documentation, it's not specified that when creating a Command, the .exe extension can be omitted for Windows executables. However, for other types of executable files like .bat or .cmd, the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()` succeeds on my machine while `Command::new("code").spawn().unwrap()` panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in [a comment](https://github.com/rust-lang/rust/blob/e7fda447e7d05b6ca431fc8fe8f489b1fda810bc/library/std/src/sys/windows/process.rs#L425), but it makes sense to mention it at a more visible place.
I've added this clarification to the documentation, which should make it more accurate and helpful for Rust developers working on the Windows platform.
Avoid tls access while iterating through mpsc thread entries Upstream fix: crossbeam-rs/crossbeam#802. Possibly fixes rust-lang/rust#113726.
remove the unstable `core::sync::atomic::ATOMIC_*_INIT` constants Tracking issue: #99069 It would be weird to ever stabilise these as they are already deprecated.
…on, r=thomcc std: remove an allocation in `Path::with_extension` `Path::with_extension` used to reallocate (and copy) paths twice per call, now it does it once, by checking the size of the previous and new extensions it's possible to call `PathBuf::with_capacity` and pass the exact capacity required. This also reduces the memory consumption of the path returned from `Path::with_extension` by using exact capacity instead of using amortized exponential growth.
Make {Rc,Arc}::allocator associated functions
Minor improvements to Windows TLS dtors This does a few things: * Moves keyless dtors into the same module as the `on_tls_callback` function because of dylib mess. We keep the `inline(never)` hints as a precaution (see also the issue they link to). * Introduces the `HAS_DTORS` atomic as an optimization hint. This allows removing (most) of the TLS dtor code if no dtors are ever run. Otherwise it's always included because of a `#[used]`. * Only run either keyed dtors or keyless dtors but not both. They should be mutually exclusive as keyed dtors are a fallback. I've also added an `assert` to make sure this is true.
Rollup of 5 pull requests
Successful merges:
- #113380 (style-guide: clean up "must"/"should"/"may")
- #113723 (Resurrect: rustc_llvm: Add a -Z `print-codegen-stats` option to expose LLVM statistics.)
- #113780 (Support `--print KIND=PATH` command line syntax)
- #113810 (Make {Rc,Arc}::allocator associated functions)
- #113907 (Minor improvements to Windows TLS dtors)
Failed merges:
- #113392 (style-guide: Some cleanups from the fmt-rfcs repo history)
r? `@ghost`
`@rustbot` modify labels: rollup
Add more comprehensive tests for is_sorted and friends See #53485 and #55045.
Stabilize chown functions (`unix_chown`) Closes #88989 FCP is complete here: rust-lang/rust#88989 (comment)
… r=cuviper Remove lifetime bound for A for `impl Extend<&'a T> for Vec<T, A>`. The lifetime of the references being copied from is unrelated to the allocator. Compare with [`impl<'a, T: 'a + Copy, A: Allocator> Extend<&'a T> for VecDeque<T, A>`](https://doc.rust-lang.org/alloc/collections/vec_deque/struct.VecDeque.html#impl-Extend%3C%26'a+T%3E-for-VecDeque%3CT,+A%3E) which does not have the `A: 'a` bound already. Since `Allocator` is unstable, the only possible `A` on stable is `Global`, and `Global: 'static`, so this change is not (should not be) observable on stable (or without `#![feature(allocator_api)]`). [This is observable on nightly](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8c4aa166c6116a90593d2934d30cfeb3).
Remove `#[cfg(all())]` workarounds from `c_char` Casts to type aliases are now ignored by Clippy rust-lang/rust-clippy#8596 Closes rust-lang/rust-clippy#8093
…, r=ChrisDenton Update the tracking issue for `const_cstr_from_ptr` Tracking issue #101719 was for `const_cstr_methods`, #113219 is a new issue specific for `const_cstr_from_ptr`. (I believe #101719 could also be closed) ```@rustbot``` label +T-libs-api +A-docs
Allow limited access to `OsString` bytes This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString` as suggested in feedback from `os_str_bytes` crate in #111544.
fix docs & example for `std::os::unix::prelude::FileExt::write_at` Changelog: * used `File::create` instead of `File::read` to get a writeable file * explicity mentioned the bug with `pwrite64` in docs Unfortunately, I don't think that there is really much we can do about this since the feature has already been stabilised. We could potentially add a clippy lint warning people on Linux that using `write_at` with the `O_APPEND` flag does not exhibit the behaviour that they would have assumed. fixes #113627
Fix size_hint for EncodeUtf16 More realistic upper and lower bounds, and handle the case where the iterator is located within a surrogate pair. Resolves #113897
These are common alternate names, usually a less-abbreviated form, for the operation; e.g. `arctan` instead of `atan`. Prompted by <https://users.rust-lang.org/t/64-bit-trigonometry/98599>
I think this was simply forgotten in #113464.
Synchronize with all calls to `unpark` in id-based thread parker [The documentation for `thread::park`](https://doc.rust-lang.org/nightly/std/thread/fn.park.html#memory-ordering) guarantees that "park synchronizes-with all prior unpark operations". In the id-based thread parking implementation, this is not implemented correctly, as the state variable is reset with a simple store, so there will not be a *synchronizes-with* edge if an `unpark` happens just before the reset. This PR corrects this, replacing the load-check-reset sequence with a single `compare_exchange`.
When I was learning Rust I looked for “a modulo function” and couldn’t find one, so thought I had to write my own; it wasn't at all obvious that a function with “rem” in the name was the function I wanted. Hopefully this will save the next learner from that. However, it does have the disadvantage that the top results in rustdoc for “mod” are now these aliases instead of the Rust keyword, which probably isn't ideal.
Add doc aliases for trigonometry and other f32,f64 methods. These are common alternate names, usually a less-abbreviated form, for the operation; e.g. `arctan` instead of `atan`. Prompted by <https://users.rust-lang.org/t/64-bit-trigonometry/98599>
Add `modulo` and `mod` as doc aliases for `rem_euclid`. When I was learning Rust I looked for “a modulo function” and couldn’t find one, so thought I had to write my own; it wasn't at all obvious that a function with “rem” in the name was the function I wanted. Hopefully this will save the next learner from that. However, it does have the disadvantage that the top results in rustdoc for “mod” are now these aliases instead of the Rust keyword, which probably isn't ideal.
Increase clarity about Hash - Eq consistency in HashMap and HashSet docs As discussed [here](https://users.rust-lang.org/t/what-hapens-if-hash-and-partialeq-dont-match-when-using-hashmap/98052/13) the description of logic errors in `HashMap` and `HashSet` does not explicitly apply to ```text k1 == k2 -> hash(k1) == hash(k2) ``` but this is likely what is intended. This PR is a small doc change to correct this. r? rust-lang/libs
Inline strlen_rt in CStr::from_ptr This enables LLVM to optimize this function as if it was strlen (LLVM knows what it does, and can avoid calling it in certain situations) without having to enable std-aware LTO. This is essentially doing what rust-lang/rust#90007 did, except updated for this function being `const`. Pretty sure it's safe to roll-up, considering last time I did make this change it didn't affect performance (`CStr::from_ptr` isn't really used all that often in Rust code that is checked by rust-perf).
Expose core::error::request_value in std I think this was simply forgotten in #113464. /cc ``@waynr`` r? ``@Amanieu``
Usage zero as language id for `FormatMessageW()` This switches the language selection from using system language (note that this might be different than application language, typically stored as thread ui language) to use `FormatMessageW` default search strategy, which is `neutral` first, then `thread ui lang`, then `user language`, then `system language`, then `English`. (See https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessagew) This allows the Rust program to take more control of `std::io::Error`'s message field, by setting up thread ui language themselves before hand (which many programs already do).
…meGomez rustdoc: Add lint `redundant_explicit_links` Closes #87799. - Lint warns by default - Reworks link parser to cache original link's display text r? `@jyn514`
Fix UB in `std::sys::os::getenv()` Fixes #114949. Reduced the loops to 1k iterations (100k was taking way too long), Miri no longer shows any UB. `@rustbot` label +A-process +C-bug +I-unsound +O-unix
…,JakobDegen custom_mir: change Call() terminator syntax to something more readable I find our current syntax very hard to read -- I cannot even remember the order of arguments, and having the "next block" *before* the actual function call is very counter-intuitive IMO. So I suggest we use `Call(ret_val = function(v), next_block)` instead. r? `@JakobDegen`
This reverts commit 9de1a472b68ed85f396b2e2cc79c3ef17584d6e1. (cherry picked from commit 823bacb6e3b04c0c9eecb53cc04d4ef96e45d20a)
(cherry picked from commit 42a708083a59ece9599723f69536ddb6e987e6e4)
(cherry picked from commit 9b00e5f06f51703c5294af602959d3f92c095aa7)
(cherry picked from commit 8ad23794077b4380da05fc5dabb573f38bdb2718)
|
Seems good. Not merging because this was just for CI, the branch is |
eeeebbbbrrrr
pushed a commit
to tcdi/plrust
that referenced
this pull request
Oct 18, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.