| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
Rollup of 7 pull requests
Successful merges:
- #139042 (Do not remove trivial `SwitchInt` in analysis MIR)
- #139533 (add next_index to Enumerate)
- #139843 (Setup editor file associations for non-rs extensions)
- #140000 (skip llvm-config in autodiff check builds, when its unavailable)
- #140008 (Improve `clean_maybe_renamed_item` function code a bit)
- #140024 (Remove early exits from JumpThreading.)
- #140039 (Add option for stable backport poll)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=aDotInTheVoid
Add option for stable backport poll
When creating polls on Zulip about stable backport ("Do we approve the backport of `#12345`"?), stable backports should have the option of "approving, but only is a dot release is planned" (this is a hint to t-release about how the team think important - or not - is backporting some patch).
Discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stable-nominated.3A.20.23139328/near/510037866)[#t-rustdoc > stable-nominated: #139328 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stable-nominated.3A.20.23139328/near/510037866)
r? `@aDotInTheVoid` (feel free to adjust the wording!)
|
|
Remove early exits from JumpThreading.
This removes early exits from https://github.com/rust-lang/rust/pull/131203 as I asked during review.
The correctness of the backtracking is `mutated_statement` clearing all relevant conditions. If `process_statement` fails to insert a new condition, for instance by const-eval failure, `mutated_statement` still removes the obsolete conditions from the state.
r? `@compiler-errors`
|
|
r=nnethercote
Improve `clean_maybe_renamed_item` function code a bit
Follow-up of #139846.
This is what I tried to say in there: the `name` variable can be unwrapped in most cases so better do it directly once and for all if possible and move the cases where it's not possible above.
r? `@nnethercote`
|
|
skip llvm-config in autodiff check builds, when its unavailable
As you suggested, this indeed fixes `./x.py check` builds when autodiff is enabled.
r? ```@onur-ozkan```
closes #139936
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
r=Mark-Simulacrum
Setup editor file associations for non-rs extensions
.gitattributes lists `*.fixed`, `*.pp`, and `*.mir` as file extensions which should be treated as Rust source code. Do the same for VS Code and Zed. This only does syntax highlighting, which is appropriate, as MIR isn't really Rust code.
At the same time, consistently order `rust-analyzer.linkedProjects` between editors. For some reason, Eglot didn't include `library/Cargo.toml`.
I have tested this with VS Code and Zed. I have not implemented it for Emacs/Eglot or Helix.
|
|
add next_index to Enumerate
Proposal: https://github.com/rust-lang/libs-team/issues/435
Tracking Issue: #130711
This basically just reopens #130682 but squashed and with the new function and the feature gate renamed to `next_index.`
There are two questions I have already:
- Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be.
- Maybe I could actually also add a doctest?
- For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
|
|
Do not remove trivial `SwitchInt` in analysis MIR
This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory.
This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB.
Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like:
```rust
fn foo() {
let x;
let (0 | _) = x;
}
```
This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: https://github.com/rust-lang/rust/pull/139042#issuecomment-2767436367
As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.:
```rust
fn foo() {
let x;
let (0.. | _) = x;
}
```
|
|
skip-checks: true
|
|
Rollup of 8 pull requests
Successful merges:
- #137454 (not lint break with label and unsafe block)
- #139297 (Deduplicate & clean up Nix shell)
- #139535 (Implement `Default` for raw pointers)
- #139919 (Make rustdoc JSON Span column 1-based, just like line numbers)
- #139922 (fix incorrect type in cstr `to_string_lossy()` docs)
- #140007 (Disable has_thread_local on i686-win7-windows-msvc)
- #140016 (std: Use fstatat() on illumos)
- #140025 (Re-remove `AdtFlags::IS_ANONYMOUS`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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
|
|
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````
|
|
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.
|
|
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.
|
|
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 https://github.com/rust-lang/trait-system-refactor-initiative/issues/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
|
|
r=tgross35,traviscross
Make `#[naked]` an unsafe attribute
tracking issue: https://github.com/rust-lang/rust/issues/138997
Per https://github.com/rust-lang/rust/pull/134213#issuecomment-2755984503, 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``
|
|
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 https://github.com/rust-lang/rust/issues/130627
|
|
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
|
|
Re-remove `AdtFlags::IS_ANONYMOUS`
Removed in #138296.
I accidentally re-added it in #137043 while resolving merge conflicts. This PR re-removes it.
r? ``@compiler-errors`` (sorry)
|
|
std: Use fstatat() on illumos
|
|
Disable has_thread_local on i686-win7-windows-msvc
On Windows 7 32-bit, the alignment characteristic of the TLS Directory don't appear to be respected by the PE Loader, leading to crashes. As a result, let's disable has_thread_local to make sure TLS goes through the emulation layer.
Fixes #138903
|
|
fix incorrect type in cstr `to_string_lossy()` docs
Restoring what it said prior to commit 67065fe in which it was changed incorrectly with no supporting explanation.
Closes #139835.
|
|
Make rustdoc JSON Span column 1-based, just like line numbers
Fixes https://github.com/rust-lang/rust/issues/139906.
This PR does two things:
1. It makes column 1-indexed as well, just like lines.
2. It updates documentation about them to mention that they are 1-indexed.
I think it's better for coherency to have them both 1-indexed instead of the weird mix we used to have. Docs for `line` and `col` fields can be found [here](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Loc.html#structfield.line).
And finally: it adds a regression test to ensure they are indeed 1-indexed.
r? `@aDotInTheVoid`
|
|
Implement `Default` for raw pointers
ACP: https://github.com/rust-lang/libs-team/issues/571
This is instantly stable so we will need an FCP here.
Closes https://github.com/rust-lang/rfcs/issues/2464
|
|
Deduplicate & clean up Nix shell
1. Deduplicate the flake and shell files
2. Remove flake-utils
3. Remove `with` statements
They are considered bad practice nowadays because the slow down the evalulator and have weird shadowing rules.
4. Use `env`
:3
5. use `callPackage`
It's the recommended way for derivations like these.
6. Use `packages` in the shell
There is no reason to use `buildInputs` for a mkShell (except in funny cases that will not be seen here), so the `packages` attr is recommended now days.
r? WaffleLapkin
|
|
not lint break with label and unsafe block
fixes #137414
we can't label unsafe blocks, so that we can do not lint them
|
|
|
|
|
|
|
|
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
|
|
|
|
|
|
|
|
|
|
|
|
r=antoyo
Subtree update GCC backend
cc `@antoyo`
|
|
They were 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
subtree-update_cg_gcc_2025-04-18
|
|
|
|
|
|
|
|
Sync from rust 2025/04/17
|
