diff --git a/rust-version b/rust-version index 1a74dff9d2..6f5d7cdd97 100644 --- a/rust-version +++ b/rust-version @@ -1 +1 @@ -da86f4d0726be475afbbffe40cb2f65741c51ad3 +22057b88b091743bc0fd8d592a9264f0a6951403 diff --git a/src/backend/debugging.md b/src/backend/debugging.md index eaa9e399a0..896fa20df2 100644 --- a/src/backend/debugging.md +++ b/src/backend/debugging.md @@ -209,7 +209,7 @@ tutorial above): - The `-Z print-llvm-passes` option will print out LLVM optimization passes being run - The `-Z time-llvm-passes` option measures the time of each LLVM pass - The `-Z verify-llvm-ir` option will verify the LLVM IR for correctness -- The `-Z no-parallel-backend` will disable parallel compilation of distinct compilation units +- The `--jobs-backend=1` will disable parallel compilation of distinct compilation units - The `-Z llvm-time-trace` option will output a Chrome profiler compatible JSON file which contains details and timings for LLVM passes. - The `-C llvm-args=-opt-bisect-limit=` option allows for bisecting LLVM optimizations. diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 49a965d49d..26b5668809 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -281,7 +281,7 @@ Here are some notable ones: | `rustc_dump_item_bounds` | Dumps the [`item_bounds`] of an item. | | `rustc_dump_layout` | [See this section](#debugging-type-layouts). | | `rustc_dump_object_lifetime_defaults` | Dumps the [object lifetime defaults] of an item. | -| `rustc_dump_predicates` | Dumps the [`predicates_of`] an item. | +| `rustc_dump_predicates` | Dumps the [`clauses_of`] an item. | | `rustc_dump_symbol_name` | Dumps the mangled & demangled [`symbol_name`] of an item. | | `rustc_dump_variances` | Dumps the [variances] of an item. | | `rustc_dump_vtable` | Dumps the vtable layout of an impl, or a type alias of a dyn type. | @@ -293,7 +293,7 @@ Right below you can find elaborate explainers on a selected few. [`def_path_str`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.def_path_str [`inferred_outlives_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.inferred_outlives_of [`item_bounds`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.item_bounds -[`predicates_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.predicates_of +[`clauses_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.clauses_of [`symbol_name`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.symbol_name [object lifetime defaults]: https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes [opaq]: ./opaque-types-impl-trait-inference.md diff --git a/src/effects.md b/src/effects.md index edbb1688e3..4096c85a59 100644 --- a/src/effects.md +++ b/src/effects.md @@ -9,22 +9,22 @@ Because `[const] Tr`, or rather `Maybe` bounds apply differently based on whichever contexts they are in, they have different behavior than normal bounds. Where normal trait bounds on a function such as -`T: Tr` are collected within the [`predicates_of`] query to be proven when a +`T: Tr` are collected within the [`clauses_of`] query to be proven when a function is called and to be assumed within the function, bounds such as `T: [const] Tr` will behave as a normal trait bound and add `T: Tr` to the result -from `predicates_of`, but also adds a `HostEffectPredicate` to the [`const_conditions`] query. +from `clauses_of`, but also adds a `HostEffectPredicate` to the [`const_conditions`] query. On the other hand, `T: const Tr` bounds do not change meaning across contexts, therefore they will result in `HostEffect(T: Tr, const)` being added to -`predicates_of`, and not `const_conditions`. +`clauses_of`, and not `const_conditions`. [`HostEffectPredicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/predicate/struct.HostEffectPredicate.html -[`predicates_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.predicates_of +[`clauses_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.clauses_of [`const_conditions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.const_conditions ## The `const_conditions` query -`predicates_of` represents a set of predicates that need to be proven to use an item. +`clauses_of` represents a set of clauses that need to be proven to use an item. For example, to use `foo` in the example below: ```rust diff --git a/src/return-position-impl-trait-in-trait.md b/src/return-position-impl-trait-in-trait.md index 85cece2acd..e82a0bdbf4 100644 --- a/src/return-position-impl-trait-in-trait.md +++ b/src/return-position-impl-trait-in-trait.md @@ -47,7 +47,7 @@ The main addition for RPITITs is that during lowering we track the relationship between the captured lifetimes and the corresponding duplicated lifetimes in an additional field, [`OpaqueTy::lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping). -We use this lifetime mapping later on in `predicates_of` to install +We use this lifetime mapping later on in `clauses_of` to install bounds that enforce equality between these duplicated lifetimes and their source lifetimes in order to properly typecheck these GATs, which will be discussed below. @@ -171,18 +171,18 @@ perhaps by a interested new contributor. ##### `opt_rpitit_info` Some queries rely on computing information that would result in cycles -if we were to feed them eagerly, like `explicit_predicates_of`. -Therefore we defer to the `predicates_of` provider to return the right +if we were to feed them eagerly, like `explicit_clauses_of`. +Therefore we defer to the `clauses_of` provider to return the right value for our RPITIT's GAT. We do this by detecting early on in the query if the associated type is synthetic by using [`opt_rpitit_info`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.opt_rpitit_info), which returns `Some` if the associated type is synthetic. -Then, during a query like `explicit_predicates_of`, we can detect if an +Then, during a query like `explicit_clauses_of`, we can detect if an associated type is synthetic like: ```rust -fn explicit_predicates_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ... { +fn explicit_clauses_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ... { if let Some(rpitit_info) = tcx.opt_rpitit_info(def_id) { // Do something special for RPITITs... return ...; @@ -192,7 +192,7 @@ fn explicit_predicates_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ... { } ``` -##### `explicit_predicates_of` +##### `explicit_clauses_of` RPITITs begin by copying the predicates of the method that defined it, both on the trait and impl side. @@ -378,7 +378,7 @@ error[E0308]: mismatched types We check well-formedness of RPITITs just like regular associated types. -Since we added lifetime bounds in `predicates_of` that link the +Since we added lifetime bounds in `clauses_of` that link the duplicated early-bound lifetimes to their original lifetimes, and we implemented `assumed_wf_types` which inherits the WF types of the method from which the RPITIT originates ([#113704]), we have no issues diff --git a/src/tests/x86_64-gnu-parallel-frontend.md b/src/tests/x86_64-gnu-parallel-frontend.md new file mode 100644 index 0000000000..e8c91044be --- /dev/null +++ b/src/tests/x86_64-gnu-parallel-frontend.md @@ -0,0 +1,12 @@ +# Parallel frontend testing on CI + +If you see any test failures in `tests/ui` from the CI job `x86_64-gnu-parallel-frontend`, please +add `//@ ignore-parallel-frontend triage` to the failing test, even if your PR is otherwise +entirely unrelated to parallel compiler or its testing. +In some time people from the parallel rustc working group will triage the failing test, make a +tracking issue for it, and try to debug the problem. + +For more context, see: + +* [MCP: Stabilization strategy for rustc parallel frontend](https://github.com/rust-lang/compiler-team/issues/1005) +* Tracking issue: diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index cdcb90d3e2..3a419dd119 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -4,7 +4,7 @@ We currently add implied region bounds to avoid explicit annotations. e.g. `fn foo<'a, T>(x: &'a T)` can freely assume that `T: 'a` holds without specifying it. There are two kinds of implied bounds: explicit and implicit. Explicit implied bounds -get added to the `fn predicates_of` of the relevant item while implicit ones are +get added to the `fn clauses_of` of the relevant item while implicit ones are handled... well... implicitly. ## explicit implied bounds @@ -18,7 +18,7 @@ This function computes the outlives bounds for each component of the field using separate implementation. For ADTs, trait objects, and associated types the initially required predicates are -computed in [`fn check_explicit_predicates`]. This simply uses `fn explicit_predicates_of` +computed in [`fn check_explicit_predicates`]. This simply uses `fn explicit_clauses_of` without elaborating them. Region predicates are added via [`fn insert_outlives_predicate`]. This function takes @@ -65,7 +65,7 @@ lexical region resolution [only uses the unnormalized types][notnorm]. ### proving implicit implied bounds -As the implicit implied bounds are not included in `fn predicates_of` we have to +As the implicit implied bounds are not included in `fn clauses_of` we have to separately make sure they actually hold. We generally handle this by checking that all used types are well formed by emitting `WellFormed` predicates. diff --git a/src/typing-parameter-envs.md b/src/typing-parameter-envs.md index db9f369d26..f5a19ea328 100644 --- a/src/typing-parameter-envs.md +++ b/src/typing-parameter-envs.md @@ -20,7 +20,7 @@ whereas different `ParamEnv`s can be used on a per-goal basis. The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. -Some clauses are not explicitly written but are instead implicitly added in the [`predicates_of`][predicates_of] query, +Some clauses are not explicitly written but are instead implicitly added in the [`clauses_of`][clauses_of] query, such as `ConstArgHasType` or (some) implied bounds. In most cases `ParamEnv`s are initially created via the [`param_env` query][query] which returns a `ParamEnv` derived from the provided item's where clauses. @@ -75,7 +75,7 @@ fn foo2(a: T) { } ``` -[predicates_of]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/collect/predicates_of/fn.predicates_of.html +[clauses_of]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/collect/clauses_of/fn.clauses_of.html [method_pred_entailment]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/check/compare_impl_item/fn.compare_method_predicate_entailment.html [query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.param_env [normalization]: normalization.md