Auto merge of #101620 - cjgillot:compute_lint_levels_by_def, r=oli-obk
Compute lint levels by definition
Lint levels are currently computed once for the whole crate. Any code that wants to emit a lint depends on this single `lint_levels(())` query. This query contains the `Span` for each attribute that participates in the lint level tree, so any code that wants to emit a lint basically depends on the spans in all files in the crate.
Contrary to hard errors, we do not clear the incremental session on lints, so this implicit world dependency pessimizes incremental reuse. (And is furthermore invisible for allowed lints.)
This PR completes https://github.com/rust-lang/rust/pull/99634 (thanks for the initial work `@fee1-dead)` and includes it in the dependency graph.
The design is based on 2 queries:
1. `lint_levels_on(HirId) -> FxHashMap<LintId, LevelAndSource>` which accesses the attributes at the given `HirId` and processes them into lint levels. The `TyCtxt` is responsible for probing the HIR tree to find the user-visible level.
2. `lint_expectations(())` which lists all the `#[expect]` attributes in the crate.
This PR also introduces the ability to reconstruct a `HirId` from a `DepNode` by encoding the local part of the `DefPathHash` and the `ItemLocalId` in the two `u64` of the fingerprint. This allows for the dep-graph to directly recompute `lint_levels_on` directly, without having to force the calling query.
Auto merge of #101313 - SparrowLii:mk_attr_id, r=cjgillot
make `mk_attr_id` part of `ParseSess`
Updates #48685
The current `mk_attr_id` uses the `AtomicU32` type, which is not very efficient and adds a lot of lock contention in a parallel environment.
This PR refers to the task list in #48685, uses `mk_attr_id` as a method of the `AttrIdGenerator` struct, and adds a new field `attr_id_generator` to `ParseSess`.
`AttrIdGenerator` uses the `WorkerLocal`, which has two advantages: 1. `Cell` is more efficient than `AtomicU32`, and does not increase any lock contention. 2. We put the index of the work thread in the first few bits of the generated `AttrId`, so that the `AttrId` generated in different threads can be easily guaranteed to be unique.
Auto merge of #101212 - eholk:dyn-star, r=compiler-errors
Initial implementation of dyn*
This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:
* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
* Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`
Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.
Joint work with `@nikomatsakis` and `@compiler-errors.`
Auto merge of #101805 - Dylan-DPC:rollup-mpdlbin, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #101433 (Emit a note that static bounds from HRTBs are a bug)
- #101684 (smol grammar changes to README.md)
- #101769 (rustdoc: remove redundant CSS `.out-of-band > span.since { position }`)
- #101772 (Also replace the placeholder for the stable_features lint)
- #101773 (rustdoc: remove outdated CSS `.content table` etc)
- #101779 (Update test output for drop tracking)
Rollup merge of #101779 - eholk:drop-tracking-test-output, r=jyn514
Update test output for drop tracking
#97334 has a lot of updates to test outputs that makes the PR larger than it needs to be. This PR pulls those changes out so we can keep the other one as simple as possible.
The `.content table` / `.content td` / `.content tr` family of selectors date back to 4fd061c426902b0904c65e64a3780b21f9ab3afb, when module indexes and other parts of rustdoc used `<table>` tags for layout and content presentation. The `.content td h1, .content td h2` has only been changed since then to tweak the font size in dd5ff428edbc7cd4fa600b81f27bbec28589704f.
It may also have affected a few other tables over the last decade, but they've been gradually replaced with grid layouts and flexbox to make layouts that work better on narrow viewports. For example, 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9.
These rules have no affect on the appearance of docblock tables
---------------------------------------------------------------
.content table {
border-spacing: 0 5px;
}
According to MDN, [border-spacing] only has an effect when `border-collapse` is `separate`. However, `border-collapse: collapse` is set globally for all tables, so this rule does nothing.
Tables with paragraphs in them are impossible without dropping down to raw HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin anyway, so this rule is a no-op.
Tables with headers in them are impossible without dropping down to raw HTML. This is considered unlikely, especially since it looks weird right now (`.docblock h2` has an underline that is redundant with the table cell's own border).
.content tr:first-child td { border-top: 0; }
This has no effect because of border collapsing.
This rule is removed, because tables look fine without it
---------------------------------------------------------
.content td:first-child { padding-right: 20px; }
By removing this rule, the first cell in each row has the same padding as all other cells in the row.
This rule is kept, and converted to directly target `.docblock`
---------------------------------------------------------------
.content td { vertical-align: top; }
Removing this rule would cause it to be aligned to the middle instead.
Rollup merge of #101769 - notriddle:notriddle/out-of-band-span-since, r=GuillaumeGomez
rustdoc: remove redundant CSS `.out-of-band > span.since { position }`
At the time this CSS was added, it was just `span.since`, because the version info could be rendered in two different ways:
1. `<div class='since'>` was used for associated items like methods. It was absolutely positioned, and the selector in rustdoc.css that targetted it was just `.since`.
2. `<span class='since'>` was introduced in a5a2f2b951ea982a666eaf52b1874d8f1b17290b for page-global version info, so that it could be laid out alongside the `[-]`/`[+]` button. This CSS rule was added to override the absolute position introduced in (1).
The selector was changed in 8fc6e420d16dc882f2047e6ec1b981cac5ef0d14 so that everything could use a `<span>` tag, but the dichotomy of the absolutely-positioned version info for associated items and the static positioned item version info remained.
The absolutely positioned `.since` was changed to one nested below a `<div class="rightside">` container in 5de1391b88007a1d4f7b1517657a86aae352af1e, so the version information is now always statically-positioned, and, as described in the commit message, "their DOM representation is consistent."
Auto merge of #99443 - jam1garner:mips-virt-feature, r=nagisa
Add support for MIPS VZ ISA extension
[Link to relevant LLVM line where virt extension is specified](https://github.com/llvm/llvm-project/blob/83fab8cee9d6b9fa911195c20325b4512a7a22ef/llvm/lib/Target/Mips/Mips.td#L172-L173)
This has been tested on mips-unknown-linux-musl with a target-cpu that is >= MIPS32 5 and `target-features=+virt`. The example was checked in a disassembler to ensure the correct assembly sequence was being generated using the virtualization instructions.
Needed additional work:
* MIPS is missing from [the Rust reference CPU feature lists](https://doc.rust-lang.org/reference/attributes/codegen.html#available-features)
Example docs for later:
```md
#### `mips` or `mips64`
This platform requires that `#[target_feature]` is only applied to [`unsafe`
functions][unsafe function]. This target's feature support is currently unstable
and must be enabled by `#![feature(mips_target_feature)]` ([Issue #44839])
If the above is good I can also submit a PR for that if there's interest in documenting it while it's still unstable. Otherwise that can be dropped, I just wrote it before realizing it was possibly not a good idea.
Auto merge of #101307 - jyn514:simplify-storage, r=cjgillot
Simplify caching and storage for queries
I highly recommend reviewing commit-by-commit; each individual commit is quite small but it can be hard to see looking at the overall diff that the behavior is the same. Each commit depends on the previous.
Auto merge of #101776 - weihanglo:update-cargo, r=ehuss
Update cargo
10 commits in 646e9a0b9ea8354cc409d05f10e8dc752c5de78e..082503982ea0fb7a8fd72210427d43a2e2128a63 2022-09-02 14:29:28 +0000 to 2022-09-13 17:49:38 +0000
- Take priority into account within the pending queue (rust-lang/cargo#11032)
- fix(add): Clarify which version the features are added for (rust-lang/cargo#11075)
- doc: clarify config-relative paths for `--config <path>` (rust-lang/cargo#11079)
- Do not add home bin path to PATH if it's already there (rust-lang/cargo#11023)
- Don't use `for` loop on an `Option` (rust-lang/cargo#11081)
- Remove dead code (rust-lang/cargo#11080)
- Change progress indicator for sparse registries (rust-lang/cargo#11068)
- chore(ci): Ensure intradoc links are valid (rust-lang/cargo#11055)
- Cache index files based on contents hash (rust-lang/cargo#11044)
- fix: specifies the max length for crate name (rust-lang/cargo#11051)
Rollup merge of #101770 - aDotInTheVoid:rdj-index-clone, r=GuillaumeGomez
Rustdoc-Json: Don't loose subitems of foreign traits.
Previously, we'd clone the index, and extend it with foreign traits. But when doing this, traits would render their subitems without them going into the index being used in the output leading to dangling ID's.
Rollup merge of #101266 - LuisCardosoOliveira:translation-rustcsession-pt3, r=davidtwco
translations(rustc_session): migrates rustc_session to use SessionDiagnostic - Final
# Description
This is the final part of the rustc_session https://github.com/rust-lang/rust/issues/100717#issuecomment-1220279883.
Please only review this [commit](https://github.com/rust-lang/rust/pull/101266/commits/a54534703774bfb9fc344f61d511760a7c43fe94). The other ones are from the PR https://github.com/rust-lang/rust/pull/101041# that is not yet merged.
Weihang Lo [Tue, 13 Sep 2022 20:20:13 +0000 (21:20 +0100)]
Update cargo
10 commits in 646e9a0b9ea8354cc409d05f10e8dc752c5de78e..082503982ea0fb7a8fd72210427d43a2e2128a63
2022-09-02 14:29:28 +0000 to 2022-09-13 17:49:38 +0000
- Take priority into account within the pending queue (rust-lang/cargo#11032)
- fix(add): Clarify which version the features are added for (rust-lang/cargo#11075)
- doc: clarify config-relative paths for `--config <path>` (rust-lang/cargo#11079)
- Do not add home bin path to PATH if it's already there (rust-lang/cargo#11023)
- Don't use `for` loop on an `Option` (rust-lang/cargo#11081)
- Remove dead code (rust-lang/cargo#11080)
- Change progress indicator for sparse registries (rust-lang/cargo#11068)
- chore(ci): Ensure intradoc links are valid (rust-lang/cargo#11055)
- Cache index files based on contents hash (rust-lang/cargo#11044)
- fix: specifies the max length for crate name (rust-lang/cargo#11051)
Michael Howell [Tue, 13 Sep 2022 19:25:32 +0000 (12:25 -0700)]
rustdoc: remove outdated CSS `.content table` etc
The `.content table` / `.content td` / `.content tr` family of selectors date
back to 4fd061c426902b0904c65e64a3780b21f9ab3afb, when module indexes and
other parts of rustdoc used `<table>` tags for layout and content
presentation. The `.content td h1, .content td h2` has only been changed
since then to tweak the font size in dd5ff428edbc7cd4fa600b81f27bbec28589704f.
It may also have affected a few other tables over the last decade, but
they've been gradually replaced with grid layouts and flexbox to make layouts
that work better on narrow viewports. For example, 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9.
These rules have no affect on the appearance of docblock tables
===============================================================
.content table {
border-spacing: 0 5px;
}
According to MDN, [border-spacing] only has an effect when `border-collapse`
is `separate`. However, `border-collapse: collapse` is set globally for all
tables, so this rule does nothing.
Tables with paragraphs in them are impossible without dropping down to raw
HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin
anyway, so this rule is a no-op.
Tables with headers in them are impossible without dropping down to raw HTML.
This is considered unlikely, especially since it looks weird right now
(`.docblock h2` has an underline that is redundant with the table cell's own
border).
.content tr:first-child td { border-top: 0; }
This has no effect because of border collapsing.
This rule is removed, because tables look fine without it
=========================================================
.content td:first-child { padding-right: 20px; }
By removing this rule, the first cell in each row has the same padding as all
other cells in the row.
This rule is kept, and converted to directly target `.docblock`
===============================================================
.content td { vertical-align: top; }
Removing this rule would cause it to be aligned to the middle instead.
Michael Howell [Tue, 13 Sep 2022 17:23:22 +0000 (10:23 -0700)]
rustdoc: remove redundant CSS `.out-of-band > span.since { position }`
At the time this CSS was added, it was just `span.since`, because the
version info could be rendered in two different ways:
1. `<div class='since'>` was used for associated items like methods. It
was absolutely positioned, and the selector in rustdoc.css that
targetted it was just `.since`.
2. `<span class='since'>` was introduced in a5a2f2b951ea982a666eaf52b1874d8f1b17290b for page-global version info,
so that it could be laid out alongside the `[-]`/`[+]` button. This CSS
rule was added to override the absolute position introduced in (1).
The selector was changed in 8fc6e420d16dc882f2047e6ec1b981cac5ef0d14 so
that everything could use a `<span>` tag, but the dichotomy of the
absolutely-positioned version info for associated items and the static
positioned item version info remained.
The absolutely positioned `.since` was changed to one nested below a
`<div class="rightside">` container in 5de1391b88007a1d4f7b1517657a86aae352af1e, so the version information is now
always statically-positioned, and, as described in the commit message,
"their DOM representation is consistent."
Auto merge of #101615 - compiler-errors:rpitit-perf, r=oli-obk
Make `compare_predicate_entailment` no longer a query
Make `compare_predicate_entailment` so it's no longer a query (again), and splits out the new logic (that equates the return types to infer RPITITs) into its own query. This means that this new query (now called `collect_trait_impl_trait_tys`) is no longer executed for non-RPITIT cases.
This should improve perf (https://github.com/rust-lang/rust/pull/101224#issuecomment-1241682203), though in practice we see that these some crates remain from the primary regressions list on the original report... They are all <= 0.43% regression and seemingly only on the incr-full scenario for all of them.
I am at a loss for what might be causing this regression other than what I fixed here, since we don't introduce much new non-RPITIT logic except for some `def_kind` query calls in some places, for example, like projection. Maybe that's it?
----
Originally this PR was opened to test enabling `cache_on_disk` (62164aaaa11) but that didn't turn out to be very useful (https://github.com/rust-lang/rust/pull/101615#issuecomment-1242403205), so that led me to just split the query (and rename the PR).
Auto merge of #101757 - Dylan-DPC:rollup-wkt6oe9, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #101602 (Streamline `AttrAnnotatedTokenStream`)
- #101690 (Avoid `Iterator::last`)
- #101700 (A `SubstitutionPart` is not considered a deletion if it replaces nothing with nothing)
- #101745 (Fix typo in concat_bytes documentation)
- #101748 (rustdoc: remove redundant CSS `#source-sidebar, #sidebar-toggle`)
Rollup merge of #101690 - kadiwa4:avoid_iterator_last, r=oli-obk
Avoid `Iterator::last`
Adapters like `Filter` and `Map` use the default implementation of `Iterator::last` which is not short-circuiting (and so does `core::str::Split`). The predicate function will be run for every single item of the underlying iterator. I hope that removing those calls to `last` results in slight performance improvements.
Auto merge of #96709 - jackh726:gats-stabilization, r=compiler-errors
Stabilize generic associated types
Closes #44265
r? `@nikomatsakis`
# âš¡ Status of the discussion âš¡
* [x] There have been several serious concerns raised, [summarized here](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660).
* [x] There has also been a [deep-dive comment](https://github.com/rust-lang/rust/pull/96709#issuecomment-1167220240) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue.
* [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md).
* [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html).
* [x] [FCP has been proposed](https://github.com/rust-lang/rust/pull/96709#issuecomment-1129311660) and we are awaiting final decisions and discussion amidst the relevant team members.
# Stabilization proposal
This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step.
There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it).
There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features.
This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases.
## What is stabilized
The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not.
```rust
trait ATraitWithGATs {
type Assoc<'a, T> where T: 'a;
}
trait ATraitWithoutGATs<'a, T> {
type Assoc where T: 'a;
}
```
When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation.
```rust
struct X;
struct Y;
impl ATraitWithGATs for X {
type Assoc<'a, T> = &'a T
where T: 'a;
}
impl ATraitWithGATs for Y {
type Assoc<'a, T>
where T: 'a
= &'a T;
}
```
To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds:
GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](https://github.com/rust-lang/rust/issues/87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type.
To take a relatively simple example:
```rust
trait Iterable {
type Item<'a>;
type Iterator<'a>: Iterator<Item = Self::Item<'a>>;
fn iter<'x>(&'x self) -> Self::Iterator<'x>;
//^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator`
// `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too
}
```
A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html).
## What isn't stabilized/implemented
### Universal type/const quantification
Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`.
let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>;
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed
```
### Higher-kinded types
You cannot write currently (and there are no current plans to implement this):
```rust
struct Struct<'a> {}
fn foo(s: for<'a> Struct<'a>) {}
```
## Tests
There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns.
- `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs
- `./collections-project-default.rs`: Interaction with associated type defaults
- `./collections.rs`: The `Collection` pattern
- `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters
- `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion
- `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same
- `./elided-in-expr-position.rs`: Disallow lifetime elision in return position
- `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path
- `./gat-in-trait-path.rs`: Base trait path case
- `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters
- `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path
- `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl
- `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked
- `./issue-76826.rs`: `Windows` pattern
- `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics
- `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough
- `./issue-87258_a.rs`: Unconstrained opaque type with TAITs
- `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds
- `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl
- `./issue-87429-specialization.rs`: Check that bounds hold under specialization
- `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function
- `./issue-90014.rs`: Lifetime bounds are checked with TAITs
- `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs
- `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified.
- `./issue-95305.rs`: Disallow lifetime elision in trait paths
- `./iterable.rs`: `Iterable` pattern
- `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error
- `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable)
- `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait
- `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait
- `./pointer_family.rs`: `PointerFamily` pattern
- `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds
- `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait
- `./shadowing.rs`: Don't allow lifetime shadowing in params
- `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern
- `./trait-objects.rs`: Disallow trait objects for traits with GATs
- `./variance_constraints.rs`: Require that GAT substs be invariant
## Remaining bugs and open issues
A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types
There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`.
Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.)
Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound.
- #85533
- #87803
In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.
- #87755
- #87758
Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other.
- #87831
- #90573
We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes.
- #88382
When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs.
- #88460
- #96230
We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.
- #88526
Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful.
- #90816
- #92096
- #95268
We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs.
- #91693
Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls.
- #91762
Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work.
- #92985
## Potential Future work
### Universal type/const quantification
No work has been done to implement this. There are also some questions around implied bounds.
### Object-safe GATs
The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation.
### GATified std lib types
It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`.
### Reduce the need for `for<'a>`
Seen [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-2611378730). One possible syntax:
```rust
trait Iterable {
type Iter<'a>: Iterator<Item = Self::Item<'a>>;
}
fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`!
```
### Better implied bounds on higher-ranked things
Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...`
There was some mentions of this all the back in the RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-264340514).
## Alternatives
### Make generics on associated type in bounds a binder
Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-229443863) and in a few places since.
Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-261639969).
### Stabilize lifetime GATs first
This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason.
## History
* On 2016-04-30, [RFC opened](https://github.com/rust-lang/rfcs/pull/1598)
* On 2017-09-02, RFC merged and [tracking issue opened](https://github.com/rust-lang/rust/issues/44265)
* On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](https://github.com/rust-lang/rust/pull/44766)
* On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](https://github.com/rust-lang/rust/pull/45904)
* On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706)
* On 2018-04-23, [Feature gate where clauses on associated types](https://github.com/rust-lang/rust/pull/49368)
* On 2018-05-10, [Extend tests for RFC1598 (GAT)](https://github.com/rust-lang/rust/pull/49423)
* On 2018-05-24, [Finish implementing GATs (Chalk)](https://github.com/rust-lang/chalk/pull/134)
* On 2019-12-21, [Make GATs less ICE-prone](https://github.com/rust-lang/rust/pull/67160)
* On 2020-02-13, [fix lifetime shadowing check in GATs](https://github.com/rust-lang/rust/pull/68938)
* On 2020-06-20, [Projection bound validation](https://github.com/rust-lang/rust/pull/72788)
* On 2020-10-06, [Separate projection bounds and predicates](https://github.com/rust-lang/rust/pull/73905)
* On 2021-02-05, [Generic associated types in trait paths](https://github.com/rust-lang/rust/pull/79554)
* On 2021-02-06, [Trait objects do not work with generic associated types](https://github.com/rust-lang/rust/issues/81823)
* On 2021-04-28, [Make traits with GATs not object safe](https://github.com/rust-lang/rust/pull/84622)
* On 2021-05-11, [Improve diagnostics for GATs](https://github.com/rust-lang/rust/pull/82272)
* On 2021-07-16, [Make GATs no longer an incomplete feature](https://github.com/rust-lang/rust/pull/84623)
* On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](https://github.com/rust-lang/rust/pull/86993)
* On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](https://github.com/rust-lang/rust/issues/87479)
* On 2021-08-25, [Normalize projections under binders](https://github.com/rust-lang/rust/pull/85499)
* On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html)
* On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](https://github.com/rust-lang/rust/pull/88336)
* On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](https://github.com/rust-lang/rust/issues/89122)
* On 2021-11-06, [Implementation of GATs outlives lint](https://github.com/rust-lang/rust/pull/89970)
* On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](https://github.com/rust-lang/rust/pull/92118)
* On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](https://github.com/rust-lang/rust/pull/92865)
* On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](https://github.com/rust-lang/rust/pull/92917)
* On 2022-02-15, [Rework GAT where clause check](https://github.com/rust-lang/rust/pull/93820)
* On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](https://github.com/rust-lang/rust/pull/93892)
* On 2022-03-03, [Support GATs in Rustdoc](https://github.com/rust-lang/rust/pull/94009)
* On 2022-03-06, [Change location of where clause on GATs](https://github.com/rust-lang/rust/pull/90076)
* On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html)
* On 2022-05-04, [Stabilization PR](https://github.com/rust-lang/rust/pull/96709)
Auto merge of #100640 - reitermarkus:socket-display-buffer, r=thomcc
Use `DisplayBuffer` for socket addresses.
Continuation of https://github.com/rust-lang/rust/pull/100625 for socket addresses.
Renames `net::addr` to `net::addr::socket`, `net::ip` to `net::addr::ip` and `net::ip::display_buffer::IpDisplayBuffer` to `net::addr::display_buffer::DisplayBuffer`.
Auto merge of #100101 - BelovDV:issue-99429, r=petrochenkov
change rlib format to distinguish native dependencies
Another one method to solve problem mentioned in #99429.
Changed .rlib format, it contains all bundled native libraries as archieves.
At link time rlib is unpacked and native dependencies linked separately.
New behavior hidden under separate_native_rlib_dependencies flag.
Auto merge of #99556 - davidtwco:collapse-debuginfo, r=wesleywiser
ssa: implement `#[collapse_debuginfo]`
cc #39153 rust-lang/compiler-team#386
Debuginfo line information for macro invocations are collapsed by default - line information are replaced by the line of the outermost expansion site. Using `-Zdebug-macros` disables this behaviour.
When the `collapse_debuginfo` feature is enabled, the default behaviour is reversed so that debuginfo is not collapsed by default. In addition, the `#[collapse_debuginfo]` attribute is available and can be applied to macro definitions which will then have their line information collapsed.
Eric Holk [Fri, 8 Apr 2022 01:06:53 +0000 (18:06 -0700)]
Introduce dyn_star feature flag
The primary purpose of this commit is to introduce the
dyn_star flag so we can begin experimenting with implementation.
In order to have something to do in the feature gate test, we also add
parser support for `dyn* Trait` objects. These are currently treated
just like `dyn Trait` objects, but this will change in the future.
Note that for now `dyn* Trait` is experimental syntax to enable
implementing some of the machinery needed for async fn in dyn traits
without fully supporting the feature.
projects / rust.git / log