add `[const] PartialEq` bound to `PartialOrd`
This change is included for discussion purposes.
The PartialOrd bound on PartialEq is not strictly necessary. It is, rather, logical: anything which is orderable should by definition have equality. Is the same true for constness? Should every type which is const orderable also have const equality?
std: Fix WASI implementation of `remove_dir_all`
This commit is a change to the WASI-specific implementation of the `std::fs::remove_dir_all` function. Specifically it changes how directory entries are read of a directory-being-deleted to specifically buffer them all into a `Vec` before actually proceeding to delete anything. This is necessary to fix an interaction with how the WASIp1 `fd_readdir` API works to have everything work out in the face of mutations while reading a directory.
The basic problem is that `fd_readdir`, the WASIp1 API for reading directories, is not a stateful read of a directory but instead a "seekable" read of a directory. Its `cookie` argument enables seeking anywhere within the directory at any time to read further entries. Native host implementations do not have this ability, however, which means that this seeking property must be achieved by re-reading the directory. The problem with this is that WASIp1 has under-specified semantics around what should happen if a directory is mutated between two calls to `fd_readdir`. In essence there's not really any possible implementation in hosts except to read the entire directory and support seeking through the already-read list. This implementation is not possible in the WASIp1-to-WASIp2 adapter that is primarily used to create components for the `wasm32-wasip2` target where it has constrained memory requirements and can't buffer up arbitrarily sized directories. There's some more detailed discussion at https://github.com/bytecodealliance/wasmtime/issues/11701#issuecomment-3299957213 as well.
The WASIp1 API definitions are effectively "dead" now at the standards level meaning that `fd_readdir` won't be changing nor will a replacement be coming. For the `wasm32-wasip2` target this will get fixed once filesystem APIs are updated to use WASIp2 directly instead of WASIp1, making this buffering unnecessary. In essence while this is a hack it's sort of the least invasive thing that works everywhere for now. I don't think this is viable to fix in hosts so guests compiled to wasm are going to have to work around it by not relying on any guarantees about what happens to a directory if it's mutated between reads.
Allow windows resource compiler to be overridden
In rust-lang/rust#146018, it is now required to provide a resource compiler on windows when compiling rust. This allows toolchain builders to explicitly provide a path to an alternative, such as llvm-rc, instead of the one that's provided by the Windows SDK.
cc ```@lambdageek```
`rustc_next_trait_solver`: canonical out of `EvalCtxt`
we need to canonicalize outside of the trait solver as well, so it's just a lot nicer if canonicalization is more easily accessible
if you review it commit by commit the move is properly shown
rustc_codegen_llvm: Feature Conversion Tidying
The author thinks we can improve `to_llvm_features`, a function to convert a Rust target feature name into an LLVM feature (or nothing, to ignore features unsupported by LLVM) for better maintainability.
1. We can simplify some clauses and some expressions.
2. There are some readability issues.
This PR attempts to resolve some of them by tidying many cases.
std: simplify host lookup
The logic for splitting up a string into a hostname and port is currently duplicated across (nearly) all of the networking implementations in `sys`. Since it does not actually rely on any system internals, this PR moves it to the `ToSocketAddr` implementation for `&str`, making it easier to discover and maintain.
On the other hand, the `ToSocketAddr` implementation (or rather the `resolve_socket_addr` function) contained logic to overwrite the port on the socket addresses returned by `LookupHost`, even though `LookupHost` is already aware of the port and sets the port already on Xous. This PR thus removes this logic by moving the responsibility of setting the port to the system-specific `LookupHost` implementation.
As a consequence of these changes, there remains only one way of creating `LookupHost`, hence I've removed the `TryFrom` implementations in favour of a `lookup_host` function, mirroring other, public iterator-based features.
And finally, I've simplified the parsing logic responsible for recognising IP addresses passed to `<(&str, u16)>::to_socket_addrs()` by using the `FromStr` impl of `IpAddr` rather than duplicating the parsing for both IP versions.
GVN: stop hashing opaque values
GVN generates values that are not meant to be unified with any other. For instance `Opaque` (aka we don't know anything), non-deterministic constants and borrows.
The current algorithm generates a unique index, so the generated `Value` will be different from all the existing. This is wasteful, as we should not hash that `Value` at all.
This PR proposes to do this. This involves partially reimplementing a `FxIndexSet`, but yields a small but consistent perf improvement (https://github.com/rust-lang/rust/pull/145737#issuecomment-3276951054).
Specialize `Iterator::eq{_by}` for `TrustedLen` iterators
I'm sure I got some stuff wrong here, but opening this to get feedback and make sure it's a viable idea at all.
### Motivation
I had a piece of code that open-coded `Iterator::eq`, something like:
```rust
if current.len() != other.len()
|| current.iter().zip(other.iter()).any(|(a, b)| a != b) { ... }
```
... where both `current` and `other` are slices of the same type.
Changing the code to use `current.iter().eq(other)` made it a lot slower, since it wasn't checking the length of the two slices beforehand anymore, which in this instance made a big difference in perf. So I thought I'd see if I can improve `Iterator::eq`.
### Questions
1. I can't specialize for `ExactSizeIterator`, I think it's a limitation of `min_specialization` but not sure exactly why. Is specializing for `TrustedLen` good enough?
2. Should I make a codegen test for this? If so, then how? (I manually checked the assembly to make sure it works as expected)
3. Where should I put `SpecIterCompare`?
4. Can I get a perf run for this, please? I think the compiler uses this in a few places, so it might have an affect.
It is now required to provide a resource compiler on windows when
compiling rust. This allows toolchain builders to explicitly provide a
path to an alternative, such as llvm-rc, instead of the one that's
provided by the Windows SDK.
Clean up universe evaluation during type test evaluation
The logic was, as the removed comments suggest, hackish and meant to implement previous logic that was factored out. The new logic does exactly what the comments say, and is much less surprising.
I'm afraid we may want
r? `@lcnr`
for this one too.
I am sorry, but at least it should be easier to review.
Add regression test for issue #91831
The requested test for rust-lang/rust#91831. I'm unsure about the filename, the file structure in `tests/ui/lifetimes/lifetime-errors/` isn't entirely clear to me. Any suggestions?
Closesrust-lang/rust#91831
c-variadic: allow c-variadic inherent and trait methods
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing the work of https://github.com/rust-lang/rust/pull/146342, allow inherent and trait methods to be c-variadic. However, a trait that contains a c-variadic method is no longer dyn-compatible.
There is, presumably, some way to make c-variadic methods dyn-compatible. However currently, we don't have confidence that it'll work reliably: when methods from a `dyn` object are cast to a function pointer, a `ReifyShim` is created. If that shim is c-variadic, it would need to forward the C variable argument list.
That does appear to work, because the `va_list` is not represented in MIR at all in this case, so the registers from the call site are untouched by the shim and can be read by the actual implementation. That just does not seem like a solid implementation.
Also, intuitively, why would c-variadic function, primarily needed for FFI, need to be used with `dyn` objects at all? We can revisit this limitation if a need arises.
r? `@workingjubilee`
`.unwrap_or(vec![])` is as readable as `.unwrap_or_default()`.
Also, this ensures by adding tests that expressions such as
`.unwrap_or(DEFAULT_LITERAL)` (`0`, `""`, etc.) are not replaced by
`.unwrap_or_default()` either.
Related to the discussion in the [Zulip
discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/FCP.20concealed_obvious_default)
about PR rust-lang/rust-clippy#15037.
changelog: [`unwrap_or_default`]: do not replace `.unwrap_or(vec![])` by
`.unwrap_or_default()`
The logic was, as the removed comments suggest, hackish
and meant to implement previous logic that was factored out.
The new logic does exactly what the comments say, and is much
less surprising.
Matthias Krüger