[experiment] See if we can fix the path error by using a separate crate #948
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
Update the `compiler-builtins` subtree Update the Josh subtree to rust-lang@5c3d8f2753b8. r? ``@ghost``
Rollup of 7 pull requests Successful merges: - rust-lang/rust#141709 (jsondocck: Refactor directive handling) - rust-lang/rust#141974 (`tests/ui`: A New Order [4/N]) - rust-lang/rust#141989 (rustdoc-json-type: Depend on `serde` and `serde_derive` seperately) - rust-lang/rust#142015 (Report the actual item that evaluation failed for) - rust-lang/rust#142026 (bootstrap: Fix file permissions when dereferencing symlinks) - rust-lang/rust#142032 (Fix parsing of frontmatters with inner hyphens) - rust-lang/rust#142036 (Update the `compiler-builtins` subtree) r? `@ghost` `@rustbot` modify labels: rollup
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixes rust-lang/rust#121429
Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead. `compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future.
Don't walk into `Certainty::Yes` goals Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Simplify and optimize `VecCache`'s `SlotIndex::from_index` Simplify and optimize `SlotIndex::from_index` Break out bucket 0 (containing `idx < 4096`) as an early return, which simplifies the remainder of the function, and allows optimizing the `checked_ilog2` since it can no longer return `None`. This reduces the runtime of `vec_cache::tests::slot_index_exhaustive` (which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s to ~13.3s. Separately, simplify the test case as well. (The old and new code passes with the old and new test case.) --- Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
There are a few places that violate this lint, which showed up in
rust-lang/rust CI (the relevent module is gated behind
`kernel_user_helpers` which is only set for `armv4t`, `armv5te`, and
`arm-linux-androideabi`; none of these are tested in compiler-builtins
CI). Add new `unsafe { /* ... */ }` blocks where needed to address this.
Some blocks should get a more thorough review of their preconditions, so
their safety comments are left as `FIXME`s.
On the ILP32 `x86_64-unknown-linux-gnux32` target, `usize` is 32 bits so there is a sub-register alignment warning. Specify the 64-bit `r` registers, which matches the current default as well as the size of the other operands in the routines.
The `build.rs` entrypoint returns early for some targets, so emscripten and OpenBSD were not getting check-cfg set. Emit these earlier to avoid the `unexpected_cfgs` lint.
Use the in-tree `compiler-builtins` for the sysroot Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead. `compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future. Zulip discussion: [#t-compiler > Using in-tree compiler-builtins](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20in-tree.20compiler-builtins/with/522445336) Once this merges, the following PRs will need to make it to a release for the relevant crates: - rust-lang/getopts#119 (can merge at any time) - rust-lang/hashbrown#625 (can merge at any time) - rust-lang/stdarch#1825 - rust-lang/rustc-demangle#80 - rust-lang/cfg-if#84 - unicode-rs/unicode-width#77 The above should cover all tier 1 targets with no `std` features enabled. The remaining cover the rest: - alexcrichton/dlmalloc-rs#50 (wasm, xous, sgx) - gimli-rs/gimli#769 - r-efi/r-efi#89 (efi) - r-efi/r-efi-alloc#9 (efi) - fortanix/rust-sgx#770 (sgx) - hermit-os/hermit-rs#718 (hermit) - bytecodealliance/wasi-rs#108 (wasi) - gimli-rs/addr2line#345 - oyvindln/adler2#2 - BurntSushi/memchr#180 - Frommi/miniz_oxide#173 - gimli-rs/object#777 try-job: x86_64-gnu try-job: test-various
Always consider `const _` items as live for dead code analysis
This PR alters dead code analysis to always consider `const _: () = { ... };` to be live.
This doesn't address the `_name` pattern from rust-lang/rust#142075.
Fixes rust-lang/rust#142104
stabilize nonnull_provenance Fixes rust-lang/rust#135243 FCP passed in rust-lang/rust#135243
Rollup of 5 pull requests Successful merges: - rust-lang/rust#140767 (Stabilize `sha512`, `sm3` and `sm4` for x86) - rust-lang/rust#141001 (Make NonZero<char> possible) - rust-lang/rust#141993 (Use the in-tree `compiler-builtins` for the sysroot) - rust-lang/rust#142208 (Always consider `const _` items as live for dead code analysis) - rust-lang/rust#142238 (stabilize nonnull_provenance) r? `@ghost` `@rustbot` modify labels: rollup
To prepare for merging from rust-lang/rust, set the version file to:
d13a431a6c Auto merge of #142253 - tgross35:rollup-img49op, r=tgross35
…ub.com/rust-lang/rust Pull recent changes from rust-lang/rust via Josh. Upstream ref: d13a431a6cc69cd65efe7c3eb7808251d6fd7a46 Filtered ref: 46b8cd8
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.