Rollup of 10 pull requests #146760
Closed
Rollup of 10 pull requests #146760
+49,618
−23,063
Conversation
This file contains hidden or 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
`NormalizesTo` is a private predicate that should not be used outside the solver. For normalization, rustc uses `AliasRelate`, so replace with that.
fix: Masquerade as nightly cargo when invoking flycheck with `-Zscript`
Make import sorting order follow 2024 edition style
…rmalize fix: Normalize all types when finishing inference
feat: Add an option to remove reborrows from adjustment inlay hints
…m-indent Fix indent for move_guard_to_arm_body
…colon Fix ExprStmt delete semicolon for toggle_macro_delimiter
…zokqwu Enable warning logs by default
Replace it with normal `SolverDefId::TypeAliasId`. The split caused a very funny bug where code was getting `TypeAliasId` where it expected `ForeignId`, because `TypeAliasId` had a `From` impl from `hir_def::TypeAliasId` and `ForeignId` had not, plus a careless `into()`. I could've fixed this specific bug but opted to remove the split instead; currently, it just provides more room for bugs, as we don't have typed IDs for the solver anyway, and even when we'll have (hopefully), that doesn't seem like a very useful distinction, for example in hir-def foreign types are just `TypeAliasId` with some flags. Constructing a test for this isn't trivial; the trivial test (creating a foreign type, even proving a trait bound for it) fails to fail before the change, probably because we don't use the new solver everywhere yet so we don't trigger this specific code path.
fix: Remove `SolverDefId::ForeignId`
… operations of other unsafe blocks
…lver perf: Cache trait solving across queries in the same revision
…ated-unsafe-scope fix: In highlight_related, when on an unsafe block, don't highlight unsafe operations of other unsafe blocks
…attach fix: Attach the db in one more place in highlighting
Namely, mir lowering, const eval and IDE things.
A DB is enough.
minor: Don't require a full `InferenceTable` for `CastTy`
…0) to auto traits' substitutions Chalk represents dyn types as a list of predicate, the self type should be there. The next solver represents them quite differently. The `Self` was forgotten for the auto trait case.
…s-improve fix: Add progress bars to more places in analysis-stats
It's historically been flaky and is no longer needed now that std_detect has been moved out of this repository.
Remove FreeBSD CI
use `llvm.roundeven` on arm
Bumps [tracing-subscriber](https://github.com/tokio-rs/tracing) from 0.3.19 to 0.3.20. - [Release notes](https://github.com/tokio-rs/tracing/releases) - [Commits](tokio-rs/tracing@tracing-subscriber-0.3.19...tracing-subscriber-0.3.20) --- updated-dependencies: - dependency-name: tracing-subscriber dependency-version: 0.3.20 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…acing-subscriber-0.3.20 Bump tracing-subscriber from 0.3.19 to 0.3.20
…-dyn-auto-trait fix: When mapping next-solver's `dyn` type, add `Self` (aka. bound var ^1.0) to auto traits' substitutions
…get-option fix: Avoid `--target` option being given twice to `rustc` when invoked through `cargo rustc` while fetching target data layout
…the solver To the extent possible. Previously they were confused. Sometimes generic params were treated as `Param` and sometimes as `Placeholder`. A completely redundant (in the new solver) mapping of salsa::Id to ints to intern some info where we could just store it uninterned (not in Chalk though, for some weird reason). Plus fix a cute bug in closure substitution that was caught by the assertions of Chalk but the next solver did not have such assertions. Do we need more assertions?
minor: Set `WithCachedTypeInfo::stable_hash` when in-tree
Automatically switch to lto-fat when flag RUSTFLAGS="- Zautodiff=Enable" is set …t" is automatically set. closes: [rust-lang#142796](rust-lang#142796)
…oss35 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.
…on-tidying, r=workingjubilee 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.
…BoxyUwU `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
Allow windows resource compiler to be overridden In rust-lang#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``
…-buffer, r=juntyr 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 bytecodealliance/wasmtime#11701 (comment) 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.
stdarch subtree update Subtree update of `stdarch` to [rust-lang/stdarch@9f12c1a](rust-lang/stdarch@9f12c1a). Created using https://github.com/rust-lang/josh-sync. r? ``@Kobzol``
Fix tidy spellchecking on Windows Tidy should now check for executable with the right extension for the platform when installing tools
miri subtree update Subtree update of `miri` to rust-lang/miri@5a14200. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@50bb3c5. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
rustbot
added
A-LLVM
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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:
rustc_next_trait_solver: canonical out ofEvalCtxt#146638 (rustc_next_trait_solver: canonical out ofEvalCtxt)remove_dir_all#146691 (std: Fix WASI implementation ofremove_dir_all)rust-analyzersubtree update #146749 (rust-analyzersubtree update)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup