-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Rustup #12921
Merged
Merged
Rustup #12921
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
Almost all callers want this anyway, and now we can use it to also return fed bodies
Make `body_owned_by` return the `Body` instead of just the `BodyId` fixes #125677 Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly. This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too. I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
Make `body_owned_by` return the `Body` instead of just the `BodyId` fixes #125677 Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly. This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too. I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
Rollup of 7 pull requests Successful merges: - #125342 (Document platform-specifics for `Read` and `Write` of `File`) - #125711 (Make `body_owned_by` return the `Body` instead of just the `BodyId`) - #125739 (drop_in_place: weaken the claim of equivalence with drop(ptr.read())) - #125745 (Bump the stage0 compiler to beta.7 (2024-05-26)) - #125746 (Fix copy-paste error in `Duration::from_weeks` panic message.) - #125753 (compiletest: Unify `cmd2procres` with `run_command_to_procres`) - #125754 (coverage: Rename MC/DC `conditions_num` to `num_conditions`) r? `@ghost` `@rustbot` modify labels: rollup
Clippy subtree update r? `@Manishearth`
…t, r=compiler-errors Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology. Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense. --- Old terminology (HIR, rustdoc): ``` `TypeBinding`: (associated) type binding ├── `Constraint`: associated type bound └── `Equality`: (associated) equality constraint (?) ├── `Ty`: (associated) type binding └── `Const`: associated const equality (constraint) ``` Old terminology (AST, abbrev.): ``` `AssocConstraint` ├── `Bound` └── `Equality` ├── `Ty` └── `Const` ``` New terminology (AST, HIR, rustdoc): ``` `AssocItemConstraint`: associated item constraint ├── `Bound`: associated type bound └── `Equality`: associated item equality constraint OR associated item binding (for short) ├── `Ty`: associated type equality constraint OR associated type binding (for short) └── `Const`: associated const equality constraint OR associated const binding (for short) ``` r? compiler-errors
Uplift `{Closure,Coroutine,CoroutineClosure}Args` and friends to `rustc_type_ir` Part of converting the new solver's `structural_traits.rs` to be interner-agnostic. I decided against aliasing `ClosureArgs<TyCtxt<'tcx>>` to `ClosureArgs<'tcx>` because it seemed so rare. I could do so if desired, though. r? lcnr
Currently we have an awkward mix of fallible and infallible functions: ``` new_parser_from_source_str maybe_new_parser_from_source_str new_parser_from_file (maybe_new_parser_from_file) // missing (new_parser_from_source_file) // missing maybe_new_parser_from_source_file source_str_to_stream maybe_source_file_to_stream ``` We could add the two missing functions, but instead this commit removes of all the infallible ones and renames the fallible ones leaving us with these which are all fallible: ``` new_parser_from_source_str new_parser_from_file new_parser_from_source_file source_str_to_stream source_file_to_stream ``` This requires making `unwrap_or_emit_fatal` public so callers of formerly infallible functions can still work. This does make some of the call sites slightly more verbose, but I think it's worth it for the simpler API. Also, there are two `catch_unwind` calls and one `catch_fatal_errors` call in this diff that become removable thanks this change. (I will do that in a follow-up PR.)
Unsafe extern blocks This implements RFC 3484. Tracking issue #123743 and RFC rust-lang/rfcs#3484 This is better reviewed commit by commit.
Revert "use `tcx.used_crates(())` more" before it reaches beta There are more open issues caused by #124976 than will be fixed by #125493 alone. The beta cut is soon, so let's revert it and buy some time to analyze and fix these issues in our own time. fixes rust-lang/rust#125474 fixes rust-lang/rust#125484 fixes rust-lang/rust#125646 fixes rust-lang/rust#125707 fixes #126066 fixes #125934 fixes rust-lang/rust#126021 r? `@petrochenkov` `@bors` p=1
Revert "Disallow ambiguous attributes on expressions" on nightly As discussed in [today's t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-06/near/443079505), this reverts PR #124099 to fix P-critical beta regressions #125199. r? ``@wesleywiser`` Opening as draft so that ``@wesleywiser`` and ``@apiraino,`` you can tell me whether you wanted: 1. a `beta-accepted` revert of #124099 on nightly (this PR)? That will need to be backported to beta (even though #126093 may be the last of those) 2. a revert of #124099 on beta? 3. all of the above? I also opened #126102, another draft PR to revert #124099 on beta, should you choose options 2 or 3.
This reverts commit ddc5f9b.
Revert: create const block bodies in typeck via query feeding as per the discussion in rust-lang/rust#125806 (comment) It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile. reverts the const-block-specific parts of rust-lang/rust#124650 `@bors` rollup=never had a small perf impact previously fixes rust-lang/rust#125846 r? `@compiler-errors`
…anieu Stabilize `error_in_core` Closes: rust-lang/rust#103765. `@rustbot` label: +T-libs-api r? libs-api
ScalarInt: size mismatches are a bug, do not delay the panic Cc [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Why.20are.20ScalarInt.20to.20iN.2FuN.20methods.20fallible.3F) r? ``@oli-obk``
rustbot
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties
label
Jun 13, 2024
@bors r+ |
@bors p=1 |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
This was referenced Jun 13, 2024
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.
r? @ghost
changelog: none