Rollup of 7 pull requests
Successful merges:
- #98933 (Opaque types' generic params do not imply anything about their hidden type's lifetimes)
- #101041 (translations(rustc_session): migrates rustc_session to use SessionDiagnostic - Pt. 2)
- #101424 (Adjust and slightly generalize operator error suggestion)
- #101496 (Allow lower_lifetime_binder receive a closure)
- #101501 (Allow lint passes to be bound by `TyCtxt`)
- #101515 (Recover from typo where == is used in place of =)
- #101545 (Remove unnecessary `PartialOrd` and `Ord`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Allow lint passes to be bound by `TyCtxt`
This will allow storing things like `Ty<'tcx>` inside late lint passes. It's already possible to store various id types so they're already implicitly bound to a specific `TyCtxt`.
r? rust-lang/compiler
Adjust and slightly generalize operator error suggestion
(in no particular order)
* Stop passing around a whole extra `ProjectionPredicate`
* Add spaces around `=` in `Trait<..., Output = Ty>` suggestion
* Some code clean-ups, including
* add `lang_item_for_op` to turn a `Op` into a `DefId`
* avoid `SourceMap` because we don't really need to render an expr
* Remove `TypeParamVisitor` in favor of just checking `ty.has_param_types_or_consts` -- this acts a bit differently, but shouldn't cause erroneous suggestions (actually might generalize them a bit)
* We now suggest `Output = Ty` in the `where` clause suggestion when we fail to add `Struct<T>` and `T`.
I can split this out into more PRs if needed, but they're all just miscellaneous generalizations, changes, and nitpicks I saw when messing with this operator code.
const_generics: correctly deal with bound variables
removes the hack in `resolve` which was needed because we evaluated constants without caring about their bound variables.
Each commit should be fairly self-contained, even if they build on each other
r? `@jackh726`
Rollup of 6 pull requests
Successful merges:
- #101153 (Migrate another part of rustc_infer to session diagnostic)
- #101399 (Shrink span for bindings with subpatterns.)
- #101422 (Hermit: Add File::set_time stub)
- #101455 (Avoid UB in the Windows filesystem code in... bootstrap?)
- #101498 (rustc: Parameterize `ty::Visibility` over used ID)
- #101549 (Use HashStable_Generic in rustc_type_ir)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustc: Parameterize `ty::Visibility` over used ID
It allows using `LocalDefId` instead of `DefId` when possible, and also encode cheaper `Visibility<DefIndex>` into metadata.
Avoid UB in the Windows filesystem code in... bootstrap?
This basically a subset of the changes from https://github.com/rust-lang/rust/pull/101171. I didn't think to look in src/bootstrap for more windows filesystem API usage, which was apparently a mistake on my part. It's kinda goofy that stuff like this is in here, but what are you gonna do, computers are awful.
I also added `winbase` to the `winapi` dep -- I tested this in a tmp crate but needed to add this to your Cargo.toml -- you `use winapi::stuff::winbase` in this function, but are relying on something else turning on that feature.
Shrink span for bindings with subpatterns.
Bindings with nested patterns (`binding @ pat` syntax) currently point to the full pattern. This PR proposes to shrink the span to stop before the ````@`.``` This makes the diagnostics for move/mutability conflicts clearer, as they not point to the `binding` only, instead of the full pat.
r? ```@estebank```
This shrinks `hir::Ty` from 72 to 48 bytes.
`visit_lifetime` is added to the HIR stats collector because these types
are now stored in memory on their own, instead of being within other
types.
Fix `-Zgcc-ld=lld`
`-Zgcc-ld=lld` is currently broken. CI is currently ignoring its tests.
cc `@Mark-Simulacrum` on the `compiletest` change: I'm not sure which of `bootstrap`'s test step or `compiletest` is currently incorrect wrt windows' `--compile-lib-path`. Since `sysroot/bin` is passed on windows, that means that `compiletest` can't find `rust-lld` on windows and tests are currently ignored: it's looking for something that is in `sysroot/lib` instead.
They are currently ignored on unixes for a different reason: the lld wrapper has a different name than what is checked.
(I've changed `compiletest` in this PR, just because I could make a very targeted change there, whereas completely changing the intentional lib path that is passed seemed it'd have wider reaching implications on all tests.)
And in both unix/win cases, I've changed the detection to look for `rust-lld` rather than the wrappers in `bin/gcc-ld/`. It seems like the more stable of all these executable names.
r? `@petrochenkov`
I've tested the `lld-wrapper` change on linux and osx, but couldn't test on windows gnu targets (I only have MSVC targets, and these can't use `rust-lld` via `-Zgcc-ld=lld`, nor do they use the lld wrapper IIUC).
I'd expect it to work whether or not the wrapper is called with or without an executable suffix. But at least now CI should test it in these targets.
Fixes#101370.
rustdoc: remove unused CSS `.content .methods > div`
This selector has its roots in these commits:
* current version:
`.content .methods > div:not(.notable-traits):not(.method)` from 9077d540da
* intermediate version:
`.content .methods > div:not(.important-traits)` from d86621f69e
* original version:
`.content .methods > div { margin-left: 40px; }` from 0a46933c4d
Based on the call stack, where [`class='methods'`] calls `trait_item` and [`trait_item`] calls [`document`], this div selector was probably intended to target docblock and stability tags.
In the current version of the code, neither of these can possibly be nested directly below the `class='methods'` wrapper, because the [current version of the `trait_item` function] always wraps them in a `<details>` tag if they exist. The only div tag that can possibly be nested directly below it now is the one with class `method`, which is explicitly excluded.
[`class='methods'`]: 0a46933c4d/src/librustdoc/html/render.rs (L1811-L1842)
[`trait_item`]: 0a46933c4d/src/librustdoc/html/render.rs (L1807)
[`document`]: 0a46933c4d/src/librustdoc/html/render.rs (L1515-L1523)
[current version of the `trait_item` function]: e7c7aa7288/src/librustdoc/html/render/print_item.rs (L710)
rustdoc: remove unused CSS `#main-content > table td`
This rule was added in 4e2c59a970 to benefit the module items table. However, the module items table stopped using table tags when 6020c79dde switched us over to grid layout.
You can see when this one used to be triggered by visiting <https://doc.rust-lang.org/1.54.0/alloc/slice/index.html#structs-1> in a very narrow window, but it doesn't any more, because the module table is now rendered using `<div>` tags.
Remove unnecessary `EMIT_MIR_FOR_EACH_BITWIDTH`
This commit removes the annotation only for those tests where the 32 bit and 64 bit files were exactly identical. I didn't touch anything in the `mir-opt/const` directory, since having this annotation there seems more principled, even if it doesn't make a difference.
This also removes four additional files related to the `separate_const_switch.rs` test. The associated annotations were removed in #100827 , but I forgot to remove the files as well. (#97564 is the issue tracking an automated check here)
r? ```@wesleywiser```
Add -api-level to pm command
As of ~Aug 30th, `pm build` commands require an `api-level` flag. This flag should match the fuchsia api-level that's being targeted by the code. Since this is dependent on the version of the SDK that's being used, we may want to change this to something a bit more robust in the future.
This rule was added in 4e2c59a970
to benefit the module items table. However, the module items table stopped
using table tags when 6020c79dde
switched us over to grid layout.
You can see when this one used to be triggered by visiting
<https://doc.rust-lang.org/1.54.0/alloc/slice/index.html#structs-1> in a
very narrow window, but it doesn't any more, because the module table is
now rendered using `<div>` tags.
This selector has its roots in these commits:
* current version:
`.content .methods > div:not(.notable-traits):not(.method)` from
9077d540da
* intermediate version:
`.content .methods > div:not(.important-traits)` from
d86621f69e
* original version:
`.content .methods > div { margin-left: 40px; }` from
0a46933c4d
Based on the call stack, where [`class='methods'`] calls `trait_item` and
[`trait_item`] calls [`document`], this div selector was probably intended to
target docblock and stability tags.
In the current version of the code, neither of these can possibly be nested
directly below the `class='methods'` wrapper, because the [current version of
the `trait_item` function] always wraps them in a `<details>` tag if they
exist. The only div tag that can possibly be nested directly below it now is
the one with class `method`, which is explicitly excluded.
[`class='methods'`]: 0a46933c4d/src/librustdoc/html/render.rs (L1811-L1842)
[`trait_item`]: 0a46933c4d/src/librustdoc/html/render.rs (L1807)
[`document`]: 0a46933c4d/src/librustdoc/html/render.rs (L1515-L1523)
[current version of the `trait_item` function]: e7c7aa7288/src/librustdoc/html/render/print_item.rs (L710)
now that CI correctly detects rust-lld in run-make tests, we ignore this
test since it relies on `-Zgcc-ld=lld` which is not made to work on the
windows-msvc targets: it requires a gcc flavor.
Track PGO profiles in depinfo
This PR makes sure that PGO profiles (`-Cprofile-use` and `-Cprofile-sample-use`) are tracked in depinfo, so that when they change, the compilation session will be invalidated.
This approach was discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Tracking.20PGO.20profile.20files.20in.20cargo).
I tried it locally and it seems that the code is recompiled just with this change, and https://github.com/rust-lang/rust/pull/100413 is not even needed. But it's possible that not everything required is recompiled, so we will probably want to land both changes.
Another approach to implement this could be to store the PGO profiles in `sess.parse_sess.file_depinfo` when the session is being created, but then the paths would have to be converted to a string and then to a symbol, which seemed unnecessarily complicated.
CC `@michaelwoerister`
r? `@Eh2406`
