Rollup of 8 pull requests #83096
Closed
Rollup of 8 pull requests #83096
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
This commit fixes an issue pointed out in rust-lang#82758 where LTO changed the behavior of a program. It turns out that LTO was not at fault here, it simply uncovered an existing bug. The bindings to `__wasilibc_find_relpath` assumed that the relative portion of the path returned was always contained within thee input `buf` we passed in. This isn't actually the case, however, and sometimes the relative portion of the path may reference a sub-portion of the input string itself. The fix here is to use the relative path pointer coming out of `__wasilibc_find_relpath` as the source of truth. The `buf` used for local storage is discarded in this function and the relative path is copied out unconditionally. We might be able to get away with some `Cow`-like business or such to avoid the extra allocation, but for now this is probably the easiest patch to fix the original issue.
When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
Fixes issue rust-lang#82920 Even if an item does not change between compilation sessions, it may end up with a different `DefId`, since inserting/deleting an item affects the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash` in the incremental compilation system, which is stable in the face of changes to unrelated items. In particular, the query system will consider the inputs to a query to be unchanged if any `DefId`s in the inputs have their `DefPathHash`es unchanged. Queries are pure functions, so the query result should be unchanged if the query inputs are unchanged. Unfortunately, it's possible to inadvertantly make a query result incorrectly change across compilations, by relying on the specific value of a `DefId`. Specifically, if the query result is a slice that gets sorted by `DefId`, the precise order will depend on how the `DefId`s got assigned in a particular compilation session. If some definitions end up with different `DefId`s (but the same `DefPathHash`es) in a subsequent compilation session, we will end up re-computing a *different* value for the query, even though the query system expects the result to unchanged due to the unchanged inputs. It turns out that we have been sorting the predicates computed during `astconv` by their `DefId`. These predicates make their way into the `super_predicates_that_define_assoc_type`, which ends up getting used to compute the vtables of trait objects. This, re-ordering these predicates between compilation sessions can lead to undefined behavior at runtime - the query system will re-use code built with a *differently ordered* vtable, resulting in the wrong method being invoked at runtime. This PR avoids sorting by `DefId` in `astconv`, fixing the miscompilation. However, it's possible that other instances of this issue exist - they could also be easily introduced in the future. To fully fix this issue, we should 1. Turn on `-Z incremental-verify-ich` by default. This will cause the compiler to ICE whenver an 'unchanged' query result changes between compilation sessions, instead of causing a miscompilation. 2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it difficult to introduce ICEs in the first place.
Get with field index from pattern slice instead of directly indexing Closes rust-lang#82772 r? `@estebank` rust-lang#82789 (comment) > `@estebank` So the real cause is we only generate single pattern for Box here https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1130-L1132 But in the replacing function, it tries to index on the 1-length pattern slice with field 1, thus out of bounds. https://github.com/csmoe/rust/blob/615b03aeaa8ce9819de7828740ab3cd7def4fa76/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs#L1346
…,GuillaumeGomez Rename `rustdoc` to `rustdoc::all` When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints. Follow-up to rust-lang#80527. r? `@Manishearth`
std: Fix a bug on the wasm32-wasi target opening files This commit fixes an issue pointed out in rust-lang#82758 where LTO changed the behavior of a program. It turns out that LTO was not at fault here, it simply uncovered an existing bug. The bindings to `__wasilibc_find_relpath` assumed that the relative portion of the path returned was always contained within thee input `buf` we passed in. This isn't actually the case, however, and sometimes the relative portion of the path may reference a sub-portion of the input string itself. The fix here is to use the relative path pointer coming out of `__wasilibc_find_relpath` as the source of truth. The `buf` used for local storage is discarded in this function and the relative path is copied out unconditionally. We might be able to get away with some `Cow`-like business or such to avoid the extra allocation, but for now this is probably the easiest patch to fix the original issue.
…no-filter, r=Nemo157 Prevent JS error when there is no dependency or other crate documented (or --disable-per-crate-search has been used) When there is only one crate, the dropdown is removed, creating an error (that you can see pretty easily on docs.rs for example). r? ``@jyn514``
Update cargo 7 commits in 970bc67c3775781b9708c8a36893576b9459c64a..32da9eaa5de5be241cf8096ca6b749a157194f77 2021-03-07 18:09:40 +0000 to 2021-03-13 01:18:40 +0000 - Fix logic for determining prefer-dynamic for a dylib. (rust-lang/cargo#9252) - Fix issue with filtering exclusive target dependencies. (rust-lang/cargo#9255) - Update pkgid-spec docs. (rust-lang/cargo#9249) - Wordsmith the edition documentation a bit more (rust-lang/cargo#9233) - Package ID specification urls must contain a host (rust-lang/cargo#9188) - Add documentation for JSON message_path. (rust-lang/cargo#9247) - Fix filter_platform to run on targets other than x86. (rust-lang/cargo#9246)
Avoid sorting predicates by `DefId` Fixes issue rust-lang#82920 Even if an item does not change between compilation sessions, it may end up with a different `DefId`, since inserting/deleting an item affects the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash` in the incremental compilation system, which is stable in the face of changes to unrelated items. In particular, the query system will consider the inputs to a query to be unchanged if any `DefId`s in the inputs have their `DefPathHash`es unchanged. Queries are pure functions, so the query result should be unchanged if the query inputs are unchanged. Unfortunately, it's possible to inadvertantly make a query result incorrectly change across compilations, by relying on the specific value of a `DefId`. Specifically, if the query result is a slice that gets sorted by `DefId`, the precise order will depend on how the `DefId`s got assigned in a particular compilation session. If some definitions end up with different `DefId`s (but the same `DefPathHash`es) in a subsequent compilation session, we will end up re-computing a *different* value for the query, even though the query system expects the result to unchanged due to the unchanged inputs. It turns out that we have been sorting the predicates computed during `astconv` by their `DefId`. These predicates make their way into the `super_predicates_that_define_assoc_type`, which ends up getting used to compute the vtables of trait objects. This, re-ordering these predicates between compilation sessions can lead to undefined behavior at runtime - the query system will re-use code built with a *differently ordered* vtable, resulting in the wrong method being invoked at runtime. This PR avoids sorting by `DefId` in `astconv`, fixing the miscompilation. However, it's possible that other instances of this issue exist - they could also be easily introduced in the future. To fully fix this issue, we should 1. Turn on `-Z incremental-verify-ich` by default. This will cause the compiler to ICE whenver an 'unchanged' query result changes between compilation sessions, instead of causing a miscompilation. 2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it difficult to introduce ICEs in the first place.
Fix panic message of `assert_failed_inner` cc rust-lang#79100 (comment) r? `@m-ou-se`
…r=Nemo157 crates.js should use root_path and not static_root_path r? ``@Nemo157``
|
@bors r+ rollup=never p=5 |
|
📌 Commit 2ca9afc has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 2ca9afc with merge 247d0ff600e9f8749f5a2be24232259ca69ceb4b... |
|
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
|
Turned out #83074 was the cause, closing. |
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:
rustdoctorustdoc::all#82798 (Renamerustdoctorustdoc::all)DefId#83074 (Avoid sorting predicates byDefId)assert_failed_inner#83081 (Fix panic message ofassert_failed_inner)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup