-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rollup of 6 pull requests #135260
Rollup of 6 pull requests #135260
Conversation
…e in diagnostic Fix rust-lang#135209.
"Elements" are `RegionElement`s. The dense location mapping was removed from the element containers a while ago but didn't rename its use-sites. Most of the old naming only used the mapping, and are better named `location_map`.
Its original naming hides the fact that it's related to datalog polonius, and bound to be deleted in the near future. It also conflicts with the expected name for the actual NLL location map, and prefixing it with its use will make the differentiation possible.
This is another strangely named struct (and associated fields) that is hard to see was related to datalog polonius.
This reverts commit 2316749.
This reverts commit f5577a8.
…rrors Exhaustively handle expressions in patterns We currently have this invariant in HIR that a `PatKind::Lit` or a `PatKind::Range` only contains * `ExprKind::Lit` * `ExprKind::UnOp(Neg, ExprKind::Lit)` * `ExprKind::Path` * `ExprKind::ConstBlock` So I made `PatKind::Lit` and `PatKind::Range` stop containing `Expr`, and instead created a `PatLit` type whose `kind` enum only contains those variants. The only place code got more complicated was in clippy, as it couldn't share as much anymore with `Expr` handling It may be interesting on merging `ExprKind::{Path,Lit,ConstBlock}` in the future and using the same `PatLit` type (under a new name). Then it should also be easier to eliminate any and all `UnOp(Neg, Lit) | Lit` matching that we have across the compiler. Some day we should fold the negation into the literal itself and just store it on the numeric literals
…-ozkan triagebot: mark tidy changes with a more specific `A-tidy` label r? `@onur-ozkan`
…errors Ensure that we don't try to access fields on a non-struct pattern type Fix rust-lang#135209.
A couple simple borrowck cleanups This PR has a couple simple renamings: - it's been a long time since the mapping from `Location`s to `PointIndex`es was extracted from `RegionElements` into the `DenseLocationMap`, but only the types were renamed at the time. borrowck still refers to this map as `elements`. That's confusing, especially since sometimes we also use the mapping via `LivenessValues`, and makes more sense as `location_map` instead. - to clarify `LocationTable` is not as general as it sounds, and is only for datalog polonius. In this branch I didn't rename the handful of `location_table` fields and params to `polonius_table`, but can do that to differentiate it even more from `location_map`. I did try it locally and it looks worthwhile, so if you'd prefer I can also push it here. (Or we could even switch these datalog types and fields to even more explicit names) - to clarify the incomprehensible `AllFacts`, it is renamed to `PoloniusFacts`. These can be referred to as `facts` within the legacy polonius module, but as `polonius_facts` outside of it to make it clear that they're not about NLLs (nor are they about in-tree polonius but that'll be magically fixed when they're removed in the future) r? `@matthewjasper`
Fix release notes link Reported by `@ognevny` in https://github.com/rust-lang/rust/pull/134568/files#r1905347925.
…ark-Simulacrum Revert rust-lang#131365 This PR reverts rust-lang#131365, following the revert we did on the beta branches for both 1.84 and 1.85. While the PR passes CI successfully on master, as soon as we branch off beta it starts failing in the newly created beta branch. This caused the release team to revert it for both 1.84 and 1.85, and if nothing is done it would continue being reverted every cycle. `@heiseish` (PR author) feel free to submit the PR again in the future: this revert doesn't represent the release team rejecting your change, but just a (hopefully temporary!) revert to ensure future beta branches can be created without reverting it each time. When submitting the PR again, I recommend you test your changes by configuring `rust.channel` to both `nightly` and `beta` in your `config.toml`. You can see the latest failure [here](rust-lang#135163 (comment)).
@bors r+ rollup=never p=6 |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#134228 (Exhaustively handle expressions in patterns) - rust-lang#135194 (triagebot: mark tidy changes with a more specific `A-tidy` label) - rust-lang#135222 (Ensure that we don't try to access fields on a non-struct pattern type) - rust-lang#135250 (A couple simple borrowck cleanups) - rust-lang#135252 (Fix release notes link) - rust-lang#135253 (Revert rust-lang#131365) Failed merges: - rust-lang#135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: a580b5c379 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Successful merges:
A-tidy
label #135194 (triagebot: mark tidy changes with a more specificA-tidy
label)Failed merges:
lit_to_mir_constant
andlit_to_const
infallible #135195 (Makelit_to_mir_constant
andlit_to_const
infallible)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup