Skip to content

Rustc pull update #2349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 19 commits into from
Apr 21, 2025
Merged

Rustc pull update #2349

merged 19 commits into from
Apr 21, 2025

Conversation

github-actions[bot]
Copy link

Latest update from rustc.

onur-ozkan and others added 19 commits April 15, 2025 11:32
Signed-off-by: onur-ozkan <[email protected]>
support config extensions

_Copied from the `rustc-dev-guide` addition:_

>When working on different tasks, you might need to switch between different bootstrap >configurations.
>Sometimes you may want to keep an old configuration for future use. But saving raw config >values in
>random files and manually copying and pasting them can quickly become messy, especially if >you have a
>long history of different configurations.
>
>To simplify managing multiple configurations, you can create config extensions.
>
>For example, you can create a simple config file named `cross.toml`:
>
>```toml
>[build]
>build = "x86_64-unknown-linux-gnu"
>host = ["i686-unknown-linux-gnu"]
>target = ["i686-unknown-linux-gnu"]
>
>
>[llvm]
>download-ci-llvm = false
>
>[target.x86_64-unknown-linux-gnu]
>llvm-config = "/path/to/llvm-19/bin/llvm-config"
>```
>
>Then, include this in your `bootstrap.toml`:
>
>```toml
>include = ["cross.toml"]
>```
>
>You can also include extensions within extensions recursively.
>
>**Note:** In the `include` field, the overriding logic follows a right-to-left order. For example,
in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`. Also, parent extensions
always overrides the inner ones.

try-job: x86_64-mingw-2
Rewrite on_unimplemented format string parser.

This PR rewrites the format string parser for `rustc_on_unimplemented` and `diagnostic::on_unimplemented`. I plan on moving this code (and more) into the new attribute parsing system soon and wanted to PR it separately.

This PR introduces some minor differences though:
- `rustc_on_unimplemented` on trait *implementations* is no longer checked/used - this is actually never used (outside of some tests) so I plan on removing it in the future.
- for `rustc_on_unimplemented`, it introduces the `{This}` argument in favor of `{ThisTraitname}` (to be removed later). It'll be easier to parse.
- for `rustc_on_unimplemented`, `Self` can now consistently be used as a filter, rather than just `_Self`. It used to not match correctly on for example `Self = "[{integer}]"`
- Some error messages now have better spans.

Fixes rust-lang/rust#130627
… r=tgross35,traviscross

Make `#[naked]` an unsafe attribute

tracking issue: rust-lang/rust#138997

Per rust-lang/rust#134213 (comment), the `#[naked]` attribute is now an unsafe attribute (in any edition).

This can only be merged when the above PRs are merged, I'd just like to see if there are any CI surprises here, and maybe there is early review feedback too.

r? ``@traviscross``
Don't assemble non-env/bound candidates if projection is rigid

Putting this up for an initial review, it's still missing comments, clean-up, and possibly a tweak to deal with ambiguities in the `BestObligation` folder.

This PR fixes rust-lang/trait-system-refactor-initiative#173. Specifically, we're creating an unnecessary query cycle in normalization by assembling an *impl candidate* even if we know later on during `merge_candidates` that we'll be filtering out that impl candidate.

This PR adjusts the `merge_candidates` to assemble *only* env/bound candidates if we have `TraitGoalProvenVia::ParamEnv | TraitGoalProvenVia::AliasBound`.

I'll leave some thoughts/comments in the code.

r? lcnr
Don't canonicalize crate paths

When printing paths in diagnostic we should favour printing the paths that were passed in rather than resolving all symlinks.

This PR changes the form of the crate path but it should only really affect diagnostics as filesystem functions won't care which path is used. The uncanonicalized path was already used as a fallback for when canonicalization failed.

This is a partial alternative to #139823.
Move `pal::env` to `std::sys::env_consts`

Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms.

I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`.

I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`.

cc `@joboet` `@ChrisDenton`

Tracked in #117276.
Add citool command for generating a test dashboard

This PR implements an initial version of a test suite dashboard, which shows which tests were executed on CI and which tests were ignored. This was discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/512799036). The dashboard is still quite bare-bones, but I think that it could already be useful.

The next step is to create a job index, similarly to the post-merge report, and link from the individual tests to the job that executed them.

You can try it locally like this:
```bash
$ cargo run --manifest-path src/ci/citool/Cargo.toml --release \
    -- test-dashboard 38c560ae681d5c0d3fd615eaedc537a282fb1086 --output-dir dashboard
```
and then open `dashboard/index.html` in a web browser.

CC ````@wesleywiser````

r? ````@jieyouxu````
Clean UI tests 4 of n

Cleaned up some tests that have `issue` in the title. I kept the commits to be one per "`issue`" cleanup/rename to make it easier to check. I can rebase to one commit once the changes are approved.

Related Issues:
#73494
#133895

r? jieyouxu
Rollup of 8 pull requests

Successful merges:

 - #138934 (support config extensions)
 - #139091 (Rewrite on_unimplemented format string parser.)
 - #139753 (Make `#[naked]` an unsafe attribute)
 - #139762 (Don't assemble non-env/bound candidates if projection is rigid)
 - #139834 (Don't canonicalize crate paths)
 - #139868 (Move `pal::env` to `std::sys::env_consts`)
 - #139978 (Add citool command for generating a test dashboard)
 - #139995 (Clean UI tests 4 of n)

r? `@ghost`
`@rustbot` modify labels: rollup
simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors

It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first...

Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`.

I have extremely low confidence in the GCC part of this PR.

See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
transmutability: remove NFA intermediate representation

Prior to this commit, the transmutability analysis used an intermediate NFA representation of type layout. We then determinized this representation into a DFA, upon which we ran the core transmutability analysis. Unfortunately, determinizing NFAs is expensive. In this commit, we avoid NFAs entirely by observing that Rust `union`s are the only source of nondeterminism and that it is comparatively cheap to compute the DFA union of DFAs.

We also implement Graphviz DOT debug formatting of DFAs.

Fixes rust-lang/project-safe-transmute#23
Fixes rust-lang/project-safe-transmute#24

r? ``@compiler-errors``
rustc-dev-guide subtree update

r? ``@ghost``
Switch exploit mitigations to mdbook footnotes

This updates the exploit mitigations chapter in the rustc book to use the footnote feature of mdbook instead of manually implementing footnotes with HTML.
docs: fix typo change from inconstants to invariants
Rollup of 5 pull requests

Successful merges:

 - #137953 (simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors)
 - #139990 (transmutability: remove NFA intermediate representation)
 - #140044 (rustc-dev-guide subtree update)
 - #140051 (Switch exploit mitigations to mdbook footnotes)
 - #140054 (docs: fix typo change from inconstants to invariants)

r? `@ghost`
`@rustbot` modify labels: rollup
@rustbot rustbot closed this Apr 21, 2025
@rustbot rustbot reopened this Apr 21, 2025
@tshepang tshepang merged commit 3ea1fb3 into master Apr 21, 2025
1 check passed
@tshepang tshepang deleted the rustc-pull branch April 21, 2025 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants