Skip to content
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

Tracking issue for TypingMode transition #132279

Open
3 tasks
lcnr opened this issue Oct 28, 2024 · 0 comments
Open
3 tasks

Tracking issue for TypingMode transition #132279

lcnr opened this issue Oct 28, 2024 · 0 comments
Labels
A-type-system Area: Type system C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@lcnr
Copy link
Contributor

lcnr commented Oct 28, 2024

#131856 transitions the type system from separately tracking the Reveal in the ParamEnv, and intercrate and defining_opaque_types in the InferCtxt to tracking all of that state in a shared enum TypingMode as a field on the InferCtxt.

This is a necessary step towards correctly handling opaque types after type inference, but during analysis. This needs a separate typing mode where we reveal the opaque types defined by that body without accidentally trying to define them. It may also be used to properly support negative reasoning in coherence.

This issue is mostly used to get something to point to in FIXMEs.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 28, 2024
@lcnr lcnr changed the title tracking issue for TypingMode transition Tracking issue for TypingMode transition Oct 28, 2024
@Noratrieb Noratrieb added A-type-system Area: Type system C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-types Relevant to the types team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Oct 28, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 29, 2024
TypingMode: merge intercrate, reveal, and defining_opaque_types

This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s.

Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.

As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.

#### `TypingMode::from_param_env`

I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598

r? `@compiler-errors`
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Oct 30, 2024
TypingMode: merge intercrate, reveal, and defining_opaque_types

This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s.

Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.

As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.

#### `TypingMode::from_param_env`

I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598

r? `@compiler-errors`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 30, 2024
TypingMode: merge intercrate, reveal, and defining_opaque_types

This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s.

Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.

As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.

#### `TypingMode::from_param_env`

I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598

r? ``@compiler-errors``
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 30, 2024
Rollup merge of rust-lang#131856 - lcnr:typing-mode, r=compiler-errors

TypingMode: merge intercrate, reveal, and defining_opaque_types

This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s.

Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.

As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.

#### `TypingMode::from_param_env`

I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598

r? ``@compiler-errors``
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 20, 2024
…rors

continue `ParamEnv` to `TypingEnv` transition

cc rust-lang#132279

r? `@compiler-errors`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 20, 2024
finish `Reveal` removal

After rust-lang#133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.

cc rust-lang#132279

r? `@compiler-errors`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 20, 2024
finish `Reveal` removal

After rust-lang#133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.

cc rust-lang#132279

r? `@compiler-errors`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 23, 2024
…rors,BoxyUwU

finish `Reveal` removal

After rust-lang#133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.

cc rust-lang#132279

r? `@compiler-errors`
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Dec 2, 2024
…ompiler-errors

remove `Ty::is_copy_modulo_regions`

Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.

I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.

r? `@compiler-errors` cc rust-lang#132279
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 2, 2024
Rollup merge of rust-lang#133751 - lcnr:no-trait-solving-on-type, r=compiler-errors

remove `Ty::is_copy_modulo_regions`

Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.

I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.

r? `@compiler-errors` cc rust-lang#132279
bjorn3 pushed a commit to bjorn3/rust that referenced this issue Dec 6, 2024
…rors

continue `ParamEnv` to `TypingEnv` transition

cc rust-lang#132279

r? `@compiler-errors`
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 15, 2024
…ompiler-errors

remove `Ty::is_copy_modulo_regions`

Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.

I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.

r? `@compiler-errors` cc rust-lang#132279
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants