Rollup of 9 pull requests #90952
Closed
Rollup of 9 pull requests #90952
+1,284
−1,029
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
"echo" is not an application on Windows so `Command` tests could fail even if that's not what's being tested for.
This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = "wasm32"` to also account for `target_arch = "wasm64"` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled, enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size, but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.
These are all stable as-of-now in the WebAssembly specification so any engine which implements wasm64 will surely implement these features as well.
This commit works around a crash in LLVM when the `-generate-arange-section` argument is passed to LLVM. An LLVM bug is opened for this and the code in question is also set to continue passing this flag with LLVM 14, assuming that this is fixed by the time LLVM 14 comes out. Otherwise this should work around debuginfo crashes on LLVM 13.
* Add wasm64 variants for inline assembly along the same lines as wasm32 * Update a few directives in libtest to check for `target_family` instead of `target_arch` * Update some rustc codegen and typechecks specialized for wasm32 to also work for wasm64.
Brings in some fixes and better support for the wasm64 target.
This pulls in a fix for wasm64 to work correctly with this dlmalloc
Ensure that they compile with the now-a-feature-is-required logic.
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
This follows from discussion on https://bugs.llvm.org/show_bug.cgi?id=52442 where it looks like this section doesn't make sense for wasm targets.
The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before. Now they only reference the obligation itself (`String: Copy`) Address rust-lang#90869
This should significantly reduce the frequency of merge conflicts.
Windows: Resolve `process::Command` program without using the current directory Currently `std::process::Command` searches many directories for the executable to run, including the current directory. This has lead to a [CVE for `ripgrep`](https://cve.circl.lu/cve/CVE-2021-3013) but presumably other command line utilities could be similarly vulnerable if they run commands. This was [discussed on the internals forum](https://internals.rust-lang.org/t/std-command-resolve-to-avoid-security-issues-on-windows/14800). Also discussed was [which directories should be searched](https://internals.rust-lang.org/t/windows-where-should-command-new-look-for-executables/15015). EDIT: This PR originally removed all implicit paths. They've now been added back as laid out in the rest of this comment. ## Old Search Strategy The old search strategy is [documented here][1]. Additionally Rust adds searching the child's paths (see also rust-lang#37519). So the full list of paths that were searched was: 1. The directories that are listed in the child's `PATH` environment variable. 2. The directory from which the application loaded. 3. The current directory for the parent process. 4. The 32-bit Windows system directory. 5. The 16-bit Windows system directory. 6. The Windows directory. 7. The directories that are listed in the PATH environment variable. ## New Search Strategy The new strategy removes the current directory from the searched paths. 1. The directories that are listed in the child's PATH environment variable. 2. The directory from which the application loaded. 3. The 32-bit Windows system directory. 4. The Windows directory. 5. The directories that are listed in the parent's PATH environment variable. Note that it also removes the 16-bit system directory, mostly because there isn't a function to get it. I do not anticipate this being an issue in modern Windows. ## Impact Removing the current directory should fix CVE's like the one linked above. However, it's possible some Windows users of affected Rust CLI applications have come to expect the old behaviour. This change could also affect small Windows-only script-like programs that assumed the current directory would be used. The user would need to use `.\file.exe` instead of the bare application name. This PR could break tests, especially those that test the exact output of error messages (e.g. Cargo) as this does change the error messages is some cases. [1]: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa#parameters
…riplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = "wasm32"` to also account for `target_arch = "wasm64"` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled, enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size, but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc `@m-ou-se` `@jonas-schievink` `@Mark-Simulacrum`
…r=oli-obk Add `#[inline]`s to `SortedIndexMultiMap` They're small enough and good candidates to add `#[inline]` generally.
Print escaped string if char literal has multiple characters, but only one printable character Fixes rust-lang#90857 I'm not sure about the error message here, it could get rather long and *maybe* using the names of characters would be better? That wouldn't help the length any, though.
…und, r=estebank Fix span for non-satisfied trivial trait bounds The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before. Now they only reference the obligation itself (`String: Copy`) Address rust-lang#90869
Remove workaround for the forward progress handling in LLVM this workaround was only needed for LLVM < 12 and the minimum LLVM version was updated to 12 in rust-lang#90175
…htriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? `@joshtriplett` `@rustbot` label: +A-contributor-roadblock +S-waiting-on-review
update miri This is needed to fix https://github.com/rust-lang/miri-test-libstd r? `@ghost`
|
@bors r+ rollup=never p=9 |
|
📌 Commit e878e6d has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit e878e6d with merge 7031ebe23ce4a773f793ba0d79792c36e88b0d45... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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.
Successful merges:
process::Commandprogram without using the current directory #87704 (Windows: Resolveprocess::Commandprogram without using the current directory)#[inline]s toSortedIndexMultiMap#90787 (Add#[inline]s toSortedIndexMultiMap)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup