fb2f5df411
Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case 🤷♀️
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes #112110
|
||
|---|---|---|
| .github/workflows | ||
| ci | ||
| examples | ||
| josh-sync | ||
| src | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| CITATION.cff | ||
| CNAME | ||
| CODE_OF_CONDUCT.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| book.toml | ||
| mermaid-init.js | ||
| mermaid.min.js | ||
| rust-version | ||
| triagebot.toml | ||
README.md
This is a collaborative effort to build a guide that explains how rustc works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before.
You can read the latest version of the guide here.
You may also find the rustdocs for the compiler itself useful. Note that these are not intended as a guide; it's recommended that you search for the docs you're looking for instead of reading them top to bottom.
For documentation on developing the standard library, see
std-dev-guide.
Contributing to the guide
The guide is useful today, but it has a lot of work still to go.
If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the issue tracker. Just post a comment on the issue you would like to work on to make sure that we don't accidentally duplicate work. If you think something is missing, please open an issue about it!
In general, if you don't know how the compiler works, that is not a problem! In that case, what we will do is to schedule a bit of time for you to talk with someone who does know the code, or who wants to pair with you and figure it out. Then you can work on writing up what you learned.
In general, when writing about a particular part of the compiler's code, we recommend that you link to the relevant parts of the rustc rustdocs.
Build Instructions
To build a local static HTML site, install mdbook with:
> cargo install mdbook mdbook-linkcheck2 mdbook-toc mdbook-mermaid
and execute the following command in the root of the repository:
> mdbook build --open
The build files are found in the book/html directory.
Link Validations
We use mdbook-linkcheck2 to validate URLs included in our documentation. Link
checking is not run by default locally, though it is in CI. To enable it
locally, set the environment variable ENABLE_LINKCHECK=1 like in the
following example.
$ ENABLE_LINKCHECK=1 mdbook serve
Table of Contents
We use mdbook-toc to auto-generate TOCs for long sections. You can invoke the preprocessor by
including the <!-- toc --> marker at the place where you want the TOC.
Synchronizing josh subtree with rustc
This repository is linked to rust-lang/rust as a josh subtree. You can use the following commands to synchronize the subtree in both directions.
Pull changes from rust-lang/rust into this repository
- Checkout a new branch that will be used to create a PR into
rust-lang/rustc-dev-guide - Run the pull command
$ cargo run --manifest-path josh-sync/Cargo.toml rustc-pull - Push the branch to your fork and create a PR into
rustc-dev-guide
Push changes from this repository into rust-lang/rust
- Run the push command to create a branch named
<branch-name>in arustcfork under the<gh-username>account$ cargo run --manifest-path josh-sync/Cargo.toml rustc-push <branch-name> <gh-username> - Create a PR from
<branch-name>intorust-lang/rust