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

chore: fix some comments #2028

Merged
merged 1 commit into from
Jul 30, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/licenses.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ from.
- The algorithm or code pattern seems like it was likely copied from somewhere else.
- When adding new dependencies, double check the dependency's license.

In all of these cases, we will want to check that source to make sure it it is licensed in a way
In all of these cases, we will want to check that source to make sure it is licensed in a way
that is compatible with Rust’s license.

Examples
Expand Down
2 changes: 1 addition & 1 deletion src/queries/incremental-compilation-in-detail.md
Original file line number Diff line number Diff line change
Expand Up @@ -529,7 +529,7 @@ session. The overhead of doing so is a few percent of total compilation time.

Data structures used as query results could be factored in a way that removes
edges from the dependency graph. Especially "span" information is very volatile,
so including it in query result will increase the chance that that result won't
so including it in query result will increase the chance that the result won't
be reusable. See <https://github.com/rust-lang/rust/issues/47389> for more
information.

Expand Down
2 changes: 1 addition & 1 deletion src/ty_module/instantiating_binders.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ Given these trait implementations `u32: Bar` should _not_ hold. `&'a u32` only i
- There is a where clause `for<'a> &'^0 T: Trait` on the impl, as we instantiated the early binder with `u32` we actually have to prove `for<'a> &'^0 u32: Trait`
- We find the `impl<T> Trait for T` impl, we would wind up instantiating the `EarlyBinder` with `&'^0 u32`
- There is a where clause `for<'a> T: Other<'^0>`, as we instantiated the early binder with `&'^0 u32` we actually have to prove `for<'a> &'^0 u32: Other<'^0>`
- We find the `impl<'a> Other<'a> for &'a u32` and this impl is enoguh to prove the the bound as the lifetime on the borrow and on the trait are both `'^0`
- We find the `impl<'a> Other<'a> for &'a u32` and this impl is enoguh to prove the bound as the lifetime on the borrow and on the trait are both `'^0`

This end result is incorrect as we had two separate binders introducing their own generic parameters, the trait bound should have ended up as something like `for<'a1, 'a2> &'^1 u32: Other<'^0>` which is _not_ satisfied by the `impl<'a> Other<'a> for &'a u32`.

Expand Down