Effects/keyword generics MVP #113210
Merged
Effects/keyword generics MVP #113210
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
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
Noratrieb
reviewed
Jun 30, 2023
| @@ -723,6 +723,12 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[ | |||
| and it is only intended to be used in `alloc`." | |||
| ), | |||
|
|
|||
| rustc_attr!( | |||
| rustc_host, AttributeType::Normal, template!(Word), ErrorFollowing, | |||
There was a problem hiding this comment.
I find the name host really confusing here, as I've been told that HOST=true means not-const, which goes directly against my intuition of HOST=true` meaning const, because the code is executed on the host compiler.
oli-obk
requested changes
Jul 4, 2023
Comment on lines
420
to
427
| let constness = if let Some(attrs) = attrs { | ||
| attrs | ||
| .iter() | ||
| .find(|x| x.has_name(sym::const_trait)) | ||
| .map_or(Const::No, |x| Const::Yes(x.span)) | ||
| } else { | ||
| Const::No | ||
| }; |
There was a problem hiding this comment.
let constness = attrs
.iter()
.flatten()
.find(|x| x.has_name(sym::const_trait))
.map_or(Const::No, |x| Const::Yes(x.span))|
|
||
| // FIXME this should be made more efficient | ||
| let host_effect_param_index = identity_substs.iter().position(|x| { | ||
| matches!(x.unpack(), ty::GenericArgKind::Const(const_) if matches!(const_.kind(), ty::ConstKind::Param(param) if param.name == sym::host)) |
There was a problem hiding this comment.
This should probably stop looking at the parameter name at some point and check whether it has a rustc_host attribute
|
|
||
| trace!(?effect, ?identity_substs, ?callee_substs); | ||
|
|
||
| // FIXME this should be made more efficient |
There was a problem hiding this comment.
I think you could cache the index in a field in the ty::Generics by precomputing it once in the generics_of query. You should use the generics_of query instead of identity substs. Though that will require some index shenanigans to find the right index (need to add to the parent count).
oli-obk
requested changes
Jul 4, 2023
| @@ -133,6 +133,9 @@ pub struct Generics { | |||
|
|
|||
| pub has_self: bool, | |||
| pub has_late_bound_regions: Option<Span>, | |||
|
|
|||
| // The index of the constness effect when substituted. (i.e. might be index to parent substs) | |||
|
Will rename in a followup. @bors r=oli-obk |
bors
added
S-waiting-on-bors
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Jul 5, 2023
…li-obk Effects/keyword generics MVP This adds `feature(effects)`, which adds `const host: bool` to the generics of const functions, const traits and const impls. This will be used to replace the current logic around const traits. r? `@oli-obk`
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (e4cd161): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 653.976s -> 655.622s (0.25%) |
4 tasks
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 23, 2024
Represent trait constness as a distinct predicate cc `@rust-lang/project-const-traits` r? `@ghost` for now Also mirrored everything that is written below on this hackmd here: https://hackmd.io/`@compiler-errors/r12zoixg1l` # Tl;dr: * This PR removes the bulk of the old effect desugaring. * This PR reimplements most of the effect desugaring as a new predicate and set of a couple queries. I believe it majorly simplifies the implementation and allows us to move forward more easily on its implementation. I'm putting this up both as a request for comments and a vibe-check, but also as a legitimate implementation that I'd like to see land (though no rush of course on that last part). ## Background ### Early days Once upon a time, we represented trait constness in the param-env and in `TraitPredicate`. This was very difficult to implement correctly; it had bugs and was also incomplete; I don't think this was anyone's fault though, it was just the limit of experimental knowledge we had at that point. Dealing with `~const` within predicates themselves meant dealing with constness all throughout the trait solver. This was difficult to keep track of, and afaict was not handled well with all the corners of candidate assembly. Specifically, we had to (in various places) remap constness according to the param-env constness: https://github.com/rust-lang/rust/blob/574b64a97f52162f965bc201e47f0af8279ca65d/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1498 This was annoying and manual and also error prone. ### Beginning of the effects desugaring Later on, rust-lang#113210 reimplemented a new desugaring for const traits via a `<const HOST: bool>` predicate. This essentially "reified" the const checking and separated it from any of the remapping or separate tracking in param-envs. For example, if I was in a const-if-const environment, but I wanted to call a trait that was non-const, this reification would turn the constness mismatch into a simple *type* mismatch of the effect parameter. While this was a monumental step towards straightening out const trait checking in the trait system, it had its own issues, since that meant that the constness of a trait (or any item within it, like an associated type) was *early-bound*. This essentially meant that `<T as Trait>::Assoc` was *distinct* from `<T as ~const Trait>::Assoc`, which was bad. ### Associated-type bound based effects desugaring After this, rust-lang#120639 implemented a new effects desugaring. This used an associated type to more clearly represent the fact that the constness is not an input parameter of a trait, but a property that could be computed of a impl. The write-up linked in that PR explains it better than I could. However, I feel like it really reached the limits of what can comfortably be expressed in terms of associated type and trait calculus. Also, `<const HOST: bool>` remains a synthetic const parameter, which is observable in nested items like RPITs and closures, and comes with tons of its own hacks in the astconv and middle layer. For example, there are pieces of unintuitive code that are needed to represent semantics like elaboration, and eventually will be needed to make error reporting intuitive, and hopefully in the future assist us in implementing built-in traits (eventually we'll want something like `~const Fn` trait bounds!). elaboration hack: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_type_ir/src/elaborate.rs#L133-L195 trait bound remapping hack for diagnostics: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs#L2370-L2413 I want to be clear that I don't think this is a issue of implementation quality or anything like that; I think it's simply a very clear sign that we're using types and traits in a way that they're not fundamentally supposed to be used, especially given that constness deserves to be represented as a first-class concept. ### What now? This PR implements a new desugaring for const traits. Specifically, it introduces a `HostEffect` predicate to represent the obligation an impl is const, rather than using associated type bounds and the compat trait that exists for effects today. ### `HostEffect` predicate A `HostEffect` clause has two parts -- the `TraitRef` we're trying to prove, and a `HostPolarity::{Maybe, Const}`. `HostPolarity::Const` corresponds to `T: const Trait` bounds, which must *always* be proven as const, and which can be written in any context. These are lowered directly into the predicates of an item, since they're not "context-specific". On the other hand, `HostPolarity::Maybe` corresponds to `T: ~const Trait` bounds which must only exist in a conditionally-const context like a method in a `#[const_trait]`, or a `const fn` free function. We do not lower these immediately into the predicates of an item; instead, we collect them into a new query called the **`const_conditions`**. These are the set of trait refs that we need to prove have const implementations for an item to be const. Notably, they're represented as bare (poly) trait refs because they are meant to be paired back together with a `HostPolarity` when they're being registered in typeck (see next section). For example, given: ```rust const fn foo<T: ~const A + const B>() {} ``` `foo`'s const conditions would contain `T: A`, but not `T: B`. On the flip side, foo's predicates (`predicates_of`) query would contain `HostEffect(T: B, HostPolarity::Const)` but not `HostEffect(T: A, HostPolarity::Maybe)` since we don't need to prove that predicate in a non-const environment (and it's not even the right predicate to prove in an unconditionally const environment). ### Type checking const bodies When type checking bodies in HIR, when we encounter a call expression, we additionally register the callee item's const conditions with the `HostPolarity` from the body we're typechecking (`Const` for unconditionally const things like `const`/`static` items, and `Maybe` for conditionally const things like const fns; and we don't register `HostPolarity` predicates for non-const bodies). When type-checking a conditionally const body, we augment its param-env with `HostEffect(..., Maybe)` predicates. ### Checking that const impls are WF We extend the logic in `compare_method_predicate_entailment` to also check the const-conditions of the impl method, to make sure that we error for: ```rust #[const_trait] Bar {} #[const_trait] trait Foo { fn method<T: Bar>(); } impl Foo for () { fn method<T: ~const Bar>() {} // stronger assumption! } ``` We also extend the WF check for impls to register the const conditions of the trait that is being implemented. This is to make sure we error for: ```rust #[const_trait] trait Bar {} #[const_trait] trait Foo<T> where T: ~const Bar {} impl<T> const Foo<T> for () {} //~^ `T: ~const Bar` is missing! ``` ### Proving a `HostEffect` predicate We have several ways of proving a `HostEffect` predicate: 1. Matching a `HostEffect` predicate from the param-env 2. From an impl - we do impl selection very similar to confirming a trait goal, except we filter for only const impls, and we additionally register the impl's const conditions (i.e. the impl's `~const` where clauses). Later I expect that we will add more built-in implementations for things like `Fn`. ## What next? After this PR, I'd like to split out the work more so it can proceed in parallel and probably amongst others that are not me. * Register `HostEffect` goal for places in HIR typeck that correspond to call terminators, like autoderef. * Make traits in libstd const again. * Probably need to impl host effect preds in old solver. * Implement built-in `HostEffect` rules for traits like `Fn`. * Rip out const checking from MIR altogether. ## So what? This ends up being super convenient basically everywhere in the compiler. Due to the design of the new trait solver, we end up having an almost parallel structure to the existing trait and projection predicates for assembling `HostEffect` predicates; adding new candidates and especially new built-in implementations is now basically trivial, and it's quite straightforward to understand the confirmation logic for these predicates. Same with diagnostics reporting; since we have predicates which represent the obligation to prove an impl is const, we can simplify and make these diagnostics richer without having to write a ton of logic to intercept and rewrite the existing `Compat` trait errors. Finally, it gives us a much more straightforward path for supporting the const effect on the old trait solver. I'm personally quite passionate about getting const trait support into the hands of users without having to wait until the new solver lands[^1], so I think after this PR lands we can begin to gauge how difficult it would be to implement constness in the old trait solver too. This PR will not do this yet. [^1]: Though this is not a prerequisite or by any means the only justification for this PR.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 24, 2024
Represent trait constness as a distinct predicate cc `@rust-lang/project-const-traits` r? `@ghost` for now Also mirrored everything that is written below on this hackmd here: https://hackmd.io/`@compiler-errors/r12zoixg1l` # Tl;dr: * This PR removes the bulk of the old effect desugaring. * This PR reimplements most of the effect desugaring as a new predicate and set of a couple queries. I believe it majorly simplifies the implementation and allows us to move forward more easily on its implementation. I'm putting this up both as a request for comments and a vibe-check, but also as a legitimate implementation that I'd like to see land (though no rush of course on that last part). ## Background ### Early days Once upon a time, we represented trait constness in the param-env and in `TraitPredicate`. This was very difficult to implement correctly; it had bugs and was also incomplete; I don't think this was anyone's fault though, it was just the limit of experimental knowledge we had at that point. Dealing with `~const` within predicates themselves meant dealing with constness all throughout the trait solver. This was difficult to keep track of, and afaict was not handled well with all the corners of candidate assembly. Specifically, we had to (in various places) remap constness according to the param-env constness: https://github.com/rust-lang/rust/blob/574b64a97f52162f965bc201e47f0af8279ca65d/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1498 This was annoying and manual and also error prone. ### Beginning of the effects desugaring Later on, rust-lang#113210 reimplemented a new desugaring for const traits via a `<const HOST: bool>` predicate. This essentially "reified" the const checking and separated it from any of the remapping or separate tracking in param-envs. For example, if I was in a const-if-const environment, but I wanted to call a trait that was non-const, this reification would turn the constness mismatch into a simple *type* mismatch of the effect parameter. While this was a monumental step towards straightening out const trait checking in the trait system, it had its own issues, since that meant that the constness of a trait (or any item within it, like an associated type) was *early-bound*. This essentially meant that `<T as Trait>::Assoc` was *distinct* from `<T as ~const Trait>::Assoc`, which was bad. ### Associated-type bound based effects desugaring After this, rust-lang#120639 implemented a new effects desugaring. This used an associated type to more clearly represent the fact that the constness is not an input parameter of a trait, but a property that could be computed of a impl. The write-up linked in that PR explains it better than I could. However, I feel like it really reached the limits of what can comfortably be expressed in terms of associated type and trait calculus. Also, `<const HOST: bool>` remains a synthetic const parameter, which is observable in nested items like RPITs and closures, and comes with tons of its own hacks in the astconv and middle layer. For example, there are pieces of unintuitive code that are needed to represent semantics like elaboration, and eventually will be needed to make error reporting intuitive, and hopefully in the future assist us in implementing built-in traits (eventually we'll want something like `~const Fn` trait bounds!). elaboration hack: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_type_ir/src/elaborate.rs#L133-L195 trait bound remapping hack for diagnostics: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs#L2370-L2413 I want to be clear that I don't think this is a issue of implementation quality or anything like that; I think it's simply a very clear sign that we're using types and traits in a way that they're not fundamentally supposed to be used, especially given that constness deserves to be represented as a first-class concept. ### What now? This PR implements a new desugaring for const traits. Specifically, it introduces a `HostEffect` predicate to represent the obligation an impl is const, rather than using associated type bounds and the compat trait that exists for effects today. ### `HostEffect` predicate A `HostEffect` clause has two parts -- the `TraitRef` we're trying to prove, and a `HostPolarity::{Maybe, Const}`. `HostPolarity::Const` corresponds to `T: const Trait` bounds, which must *always* be proven as const, and which can be written in any context. These are lowered directly into the predicates of an item, since they're not "context-specific". On the other hand, `HostPolarity::Maybe` corresponds to `T: ~const Trait` bounds which must only exist in a conditionally-const context like a method in a `#[const_trait]`, or a `const fn` free function. We do not lower these immediately into the predicates of an item; instead, we collect them into a new query called the **`const_conditions`**. These are the set of trait refs that we need to prove have const implementations for an item to be const. Notably, they're represented as bare (poly) trait refs because they are meant to be paired back together with a `HostPolarity` when they're being registered in typeck (see next section). For example, given: ```rust const fn foo<T: ~const A + const B>() {} ``` `foo`'s const conditions would contain `T: A`, but not `T: B`. On the flip side, foo's predicates (`predicates_of`) query would contain `HostEffect(T: B, HostPolarity::Const)` but not `HostEffect(T: A, HostPolarity::Maybe)` since we don't need to prove that predicate in a non-const environment (and it's not even the right predicate to prove in an unconditionally const environment). ### Type checking const bodies When type checking bodies in HIR, when we encounter a call expression, we additionally register the callee item's const conditions with the `HostPolarity` from the body we're typechecking (`Const` for unconditionally const things like `const`/`static` items, and `Maybe` for conditionally const things like const fns; and we don't register `HostPolarity` predicates for non-const bodies). When type-checking a conditionally const body, we augment its param-env with `HostEffect(..., Maybe)` predicates. ### Checking that const impls are WF We extend the logic in `compare_method_predicate_entailment` to also check the const-conditions of the impl method, to make sure that we error for: ```rust #[const_trait] Bar {} #[const_trait] trait Foo { fn method<T: Bar>(); } impl Foo for () { fn method<T: ~const Bar>() {} // stronger assumption! } ``` We also extend the WF check for impls to register the const conditions of the trait that is being implemented. This is to make sure we error for: ```rust #[const_trait] trait Bar {} #[const_trait] trait Foo<T> where T: ~const Bar {} impl<T> const Foo<T> for () {} //~^ `T: ~const Bar` is missing! ``` ### Proving a `HostEffect` predicate We have several ways of proving a `HostEffect` predicate: 1. Matching a `HostEffect` predicate from the param-env 2. From an impl - we do impl selection very similar to confirming a trait goal, except we filter for only const impls, and we additionally register the impl's const conditions (i.e. the impl's `~const` where clauses). Later I expect that we will add more built-in implementations for things like `Fn`. ## What next? After this PR, I'd like to split out the work more so it can proceed in parallel and probably amongst others that are not me. * Register `HostEffect` goal for places in HIR typeck that correspond to call terminators, like autoderef. * Make traits in libstd const again. * Probably need to impl host effect preds in old solver. * Implement built-in `HostEffect` rules for traits like `Fn`. * Rip out const checking from MIR altogether. ## So what? This ends up being super convenient basically everywhere in the compiler. Due to the design of the new trait solver, we end up having an almost parallel structure to the existing trait and projection predicates for assembling `HostEffect` predicates; adding new candidates and especially new built-in implementations is now basically trivial, and it's quite straightforward to understand the confirmation logic for these predicates. Same with diagnostics reporting; since we have predicates which represent the obligation to prove an impl is const, we can simplify and make these diagnostics richer without having to write a ton of logic to intercept and rewrite the existing `Compat` trait errors. Finally, it gives us a much more straightforward path for supporting the const effect on the old trait solver. I'm personally quite passionate about getting const trait support into the hands of users without having to wait until the new solver lands[^1], so I think after this PR lands we can begin to gauge how difficult it would be to implement constness in the old trait solver too. This PR will not do this yet. [^1]: Though this is not a prerequisite or by any means the only justification for this PR.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 24, 2024
Represent trait constness as a distinct predicate cc `@rust-lang/project-const-traits` r? `@ghost` for now Also mirrored everything that is written below on this hackmd here: https://hackmd.io/`@compiler-errors/r12zoixg1l` # Tl;dr: * This PR removes the bulk of the old effect desugaring. * This PR reimplements most of the effect desugaring as a new predicate and set of a couple queries. I believe it majorly simplifies the implementation and allows us to move forward more easily on its implementation. I'm putting this up both as a request for comments and a vibe-check, but also as a legitimate implementation that I'd like to see land (though no rush of course on that last part). ## Background ### Early days Once upon a time, we represented trait constness in the param-env and in `TraitPredicate`. This was very difficult to implement correctly; it had bugs and was also incomplete; I don't think this was anyone's fault though, it was just the limit of experimental knowledge we had at that point. Dealing with `~const` within predicates themselves meant dealing with constness all throughout the trait solver. This was difficult to keep track of, and afaict was not handled well with all the corners of candidate assembly. Specifically, we had to (in various places) remap constness according to the param-env constness: https://github.com/rust-lang/rust/blob/574b64a97f52162f965bc201e47f0af8279ca65d/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1498 This was annoying and manual and also error prone. ### Beginning of the effects desugaring Later on, rust-lang#113210 reimplemented a new desugaring for const traits via a `<const HOST: bool>` predicate. This essentially "reified" the const checking and separated it from any of the remapping or separate tracking in param-envs. For example, if I was in a const-if-const environment, but I wanted to call a trait that was non-const, this reification would turn the constness mismatch into a simple *type* mismatch of the effect parameter. While this was a monumental step towards straightening out const trait checking in the trait system, it had its own issues, since that meant that the constness of a trait (or any item within it, like an associated type) was *early-bound*. This essentially meant that `<T as Trait>::Assoc` was *distinct* from `<T as ~const Trait>::Assoc`, which was bad. ### Associated-type bound based effects desugaring After this, rust-lang#120639 implemented a new effects desugaring. This used an associated type to more clearly represent the fact that the constness is not an input parameter of a trait, but a property that could be computed of a impl. The write-up linked in that PR explains it better than I could. However, I feel like it really reached the limits of what can comfortably be expressed in terms of associated type and trait calculus. Also, `<const HOST: bool>` remains a synthetic const parameter, which is observable in nested items like RPITs and closures, and comes with tons of its own hacks in the astconv and middle layer. For example, there are pieces of unintuitive code that are needed to represent semantics like elaboration, and eventually will be needed to make error reporting intuitive, and hopefully in the future assist us in implementing built-in traits (eventually we'll want something like `~const Fn` trait bounds!). elaboration hack: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_type_ir/src/elaborate.rs#L133-L195 trait bound remapping hack for diagnostics: https://github.com/rust-lang/rust/blob/8069f8d17a6c86a8fd881939fcce359a90c57ff2/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs#L2370-L2413 I want to be clear that I don't think this is a issue of implementation quality or anything like that; I think it's simply a very clear sign that we're using types and traits in a way that they're not fundamentally supposed to be used, especially given that constness deserves to be represented as a first-class concept. ### What now? This PR implements a new desugaring for const traits. Specifically, it introduces a `HostEffect` predicate to represent the obligation an impl is const, rather than using associated type bounds and the compat trait that exists for effects today. ### `HostEffect` predicate A `HostEffect` clause has two parts -- the `TraitRef` we're trying to prove, and a `HostPolarity::{Maybe, Const}`. `HostPolarity::Const` corresponds to `T: const Trait` bounds, which must *always* be proven as const, and which can be written in any context. These are lowered directly into the predicates of an item, since they're not "context-specific". On the other hand, `HostPolarity::Maybe` corresponds to `T: ~const Trait` bounds which must only exist in a conditionally-const context like a method in a `#[const_trait]`, or a `const fn` free function. We do not lower these immediately into the predicates of an item; instead, we collect them into a new query called the **`const_conditions`**. These are the set of trait refs that we need to prove have const implementations for an item to be const. Notably, they're represented as bare (poly) trait refs because they are meant to be paired back together with a `HostPolarity` when they're being registered in typeck (see next section). For example, given: ```rust const fn foo<T: ~const A + const B>() {} ``` `foo`'s const conditions would contain `T: A`, but not `T: B`. On the flip side, foo's predicates (`predicates_of`) query would contain `HostEffect(T: B, HostPolarity::Const)` but not `HostEffect(T: A, HostPolarity::Maybe)` since we don't need to prove that predicate in a non-const environment (and it's not even the right predicate to prove in an unconditionally const environment). ### Type checking const bodies When type checking bodies in HIR, when we encounter a call expression, we additionally register the callee item's const conditions with the `HostPolarity` from the body we're typechecking (`Const` for unconditionally const things like `const`/`static` items, and `Maybe` for conditionally const things like const fns; and we don't register `HostPolarity` predicates for non-const bodies). When type-checking a conditionally const body, we augment its param-env with `HostEffect(..., Maybe)` predicates. ### Checking that const impls are WF We extend the logic in `compare_method_predicate_entailment` to also check the const-conditions of the impl method, to make sure that we error for: ```rust #[const_trait] Bar {} #[const_trait] trait Foo { fn method<T: Bar>(); } impl Foo for () { fn method<T: ~const Bar>() {} // stronger assumption! } ``` We also extend the WF check for impls to register the const conditions of the trait that is being implemented. This is to make sure we error for: ```rust #[const_trait] trait Bar {} #[const_trait] trait Foo<T> where T: ~const Bar {} impl<T> const Foo<T> for () {} //~^ `T: ~const Bar` is missing! ``` ### Proving a `HostEffect` predicate We have several ways of proving a `HostEffect` predicate: 1. Matching a `HostEffect` predicate from the param-env 2. From an impl - we do impl selection very similar to confirming a trait goal, except we filter for only const impls, and we additionally register the impl's const conditions (i.e. the impl's `~const` where clauses). Later I expect that we will add more built-in implementations for things like `Fn`. ## What next? After this PR, I'd like to split out the work more so it can proceed in parallel and probably amongst others that are not me. * Register `HostEffect` goal for places in HIR typeck that correspond to call terminators, like autoderef. * Make traits in libstd const again. * Probably need to impl host effect preds in old solver. * Implement built-in `HostEffect` rules for traits like `Fn`. * Rip out const checking from MIR altogether. ## So what? This ends up being super convenient basically everywhere in the compiler. Due to the design of the new trait solver, we end up having an almost parallel structure to the existing trait and projection predicates for assembling `HostEffect` predicates; adding new candidates and especially new built-in implementations is now basically trivial, and it's quite straightforward to understand the confirmation logic for these predicates. Same with diagnostics reporting; since we have predicates which represent the obligation to prove an impl is const, we can simplify and make these diagnostics richer without having to write a ton of logic to intercept and rewrite the existing `Compat` trait errors. Finally, it gives us a much more straightforward path for supporting the const effect on the old trait solver. I'm personally quite passionate about getting const trait support into the hands of users without having to wait until the new solver lands[^1], so I think after this PR lands we can begin to gauge how difficult it would be to implement constness in the old trait solver too. This PR will not do this yet. [^1]: Though this is not a prerequisite or by any means the only justification for this PR.
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.
This adds
feature(effects), which addsconst host: boolto the generics of const functions, const traits and const impls. This will be used to replace the current logic around const traits.r? @oli-obk