Rustup, fix rustdoc sysroot issue #3409
Closed
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
…kingjubilee Expand sys/os for UEFI - Implement current_exe() and getcwd()
Mention Register Size in `#[warn(asm_sub_register)]` Fixes #121593 Displays the register size information obtained from `suggest_modifier()` and `default_modifier()`.
fix typo of endianness fix typo endianess -> endianness
…ulacrum Fix compile of wasm64-unknown-unknown target This target is a Tier 3 target so it's not tested on CI, and it's broken since last used so this commit fixes a small unwind-related issue that cropped up in the meantime.
…ngjubilee
CFI: Support self_cell-like recursion
Current `transform_ty` attempts to avoid cycles when normalizing `#[repr(transparent)]` types to their interior, but runs afoul of this pattern used in `self_cell`:
```
struct X<T> {
x: u8,
p: PhantomData<T>,
}
#[repr(transparent)]
struct Y(X<Y>);
```
When attempting to normalize Y, it will still cycle indefinitely. By using a types-visited list, this will instead get expanded exactly one layer deep to X<Y>, and then stop, not attempting to normalize `Y` any further.
This PR was split off from #121962 as part of fixing the larger vtable compatibility issues.
r? ``````@workingjubilee``````
CFI: Strip auto traits off Virtual calls We already use `Instance` at declaration sites when available to glean additional information about possible abstractions of the type in use. This does the same when possible at callsites as well. The primary purpose of this change is to allow CFI to alter how it generates type information for indirect calls through `Virtual` instances. This is needed for the "separate machinery" version of my approach to the vtable issues (#122573), because we need to respond differently to a `Virtual` call to the same type as a non-virtual call, specifically [stripping auto traits off the receiver's `Self`](rust-lang/rust@54b15b0) because there isn't a separate vtable for `Foo` vs `Foo + Send`. This would also make a more general underlying mechanism that could be used by rcvalle's [proposed drop detection / encoding](rust-lang/rust@edcd1e2) if we end up using his approach, as we could condition out on the `def_id` in the CFI code rather than requiring the generating code to explicitly note whether it was calling drop.
Simplify an iterator search in borrowck diag Rather than `.into_iter().rev().find_position(...)`, this case can simply call `.iter().rposition(...)`.
Rollup of 7 pull requests Successful merges: - #120419 (Expand sys/os for UEFI) - #121940 (Mention Register Size in `#[warn(asm_sub_register)]`) - #122762 (fix typo of endianness) - #122797 (Fix compile of wasm64-unknown-unknown target) - #122875 (CFI: Support self_cell-like recursion) - #122879 (CFI: Strip auto traits off Virtual calls) - #122969 (Simplify an iterator search in borrowck diag) r? `@ghost` `@rustbot` modify labels: rollup
…ays, r=oli-obk Encode implied predicates for traits In #112629, we decided to make associated type bounds in the "supertrait" AST position *implied* even though they're not supertraits themselves. This means that the `super_predicates` and `implied_predicates` queries now differ for regular traits. The assumption that they didn't differ was hard-coded in #107614, so in cross-crate positions this means that we forget the implied predicates from associated type bounds. This isn't unsound, just kind of annoying. This should be backported since associated type bounds are slated to stabilize for 1.78 -- either that, or associated type bounds can be reverted on beta and re-shipped in 1.79 with this patch. Fixes #122859
add some ice tests 5xxxx to 9xxxx Fixes rust-lang/rust#98842 Fixes rust-lang/rust#90691 Fixes rust-lang/rust#88421 Fixes rust-lang/rust#88212 Fixes rust-lang/rust#83056 Fixes rust-lang/rust#80125 Fixes rust-lang/rust#64784 Fixes rust-lang/rust#52334
ci: Build gccjit from a git archive A full `git clone` of GCC includes quite a lot of history, and it's completely unnecessary for building it in CI. We can use a GitHub archive URL to get a simple tarball that is much faster to download. Also, the `gcc-build` directory can be removed after install to reduce the image size even further.
Replace `mir_built` query with a hook and use mir_const everywhere instead A small perf improvement due to less dep graph handling. Mostly just a cleanup to get rid of one of our many mir queries
Update upload-artifact to v4 This contains a breaking change around artifact merging no longer being done. This was not relied on, so it's fine.
…ts passed to the driver
|
@bors r+ |
bors
added a commit
that referenced
this pull request
Mar 25, 2024
Rustup, fix rustdoc sysroot issue This uses a different approach to resolve #3404: we entirely move the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported.
|
💔 Test failed - checks-actions |
|
Closing in favor of #3411 which is just the cargo-miri changes without the rustup. (That won't make it work, but it makes more sense to keep that around as a draft.) |
bors
added a commit
that referenced
this pull request
Apr 15, 2024
Handle Miri sysroot entirely outside the Miri driver (Extracted from #3409) This entirely moves the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported. The advantage of this is that the driver is reasonably clean and doesn't need magic environment variables like MIRI_SYSROOT, and we don't have to fight rustc_driver to use a different default sysroot. Everything is done in cargo-miri (and the other much simpler driver wrappers) where it can hopefully be debugged much better.
bors
added a commit
that referenced
this pull request
Apr 15, 2024
Handle Miri sysroot entirely outside the Miri driver (Extracted from #3409) This entirely moves the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported. The advantage of this is that the driver is reasonably clean and doesn't need magic environment variables like MIRI_SYSROOT, and we don't have to fight rustc_driver to use a different default sysroot. Everything is done in cargo-miri (and the other much simpler driver wrappers) where it can hopefully be debugged much better.
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
Apr 16, 2024
Handle Miri sysroot entirely outside the Miri driver (Extracted from rust-lang/miri#3409) This entirely moves the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported. The advantage of this is that the driver is reasonably clean and doesn't need magic environment variables like MIRI_SYSROOT, and we don't have to fight rustc_driver to use a different default sysroot. Everything is done in cargo-miri (and the other much simpler driver wrappers) where it can hopefully be debugged much better.
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.
This uses a different approach to resolve #3404: we entirely move the responsibility of setting miri-sysroot to whatever invokes the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite,
./miri run,./x.py run miri) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that./miri run file.rs --sysroot pathis not supported.