encode `;` stmt without expr as `StmtKind::Empty`
Instead of encoding `;` statements without a an expression as a tuple in AST, encode it as `ast::StmtKind::Empty`.
r? @petrochenkov
Improve linking of crates with circular dependencies
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:
* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.
This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.
The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.
Verified using test case from #69368.
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closesrust-lang/wg-allocators#17
Adjust Miri value visitor, and doc-comment layout components
I realized that I still didn't have quite the right intuition for how our `LayoutDetails` work, so I had to adjust the Miri value visitor to the things I understood better now. I also added some doc-comments to `LayoutDetails` as a hopefully canonical place to note such things.
The main visitor change is that we *first* look at all the fields (according to `FieldPlacement`), and *then* check the variants and handle `Multiple` appropriately. I did not quite realize how orthogonal "fields" and "variants" are.
I also moved the check for the scalar ABI to *after* checking all the fields; this leads to better (more type-driven) error messages.
And it looks like we can finally remove that magic hack for `ty::Generator`. :D
r? @oli-obk for the Miri/visitor changes and @eddyb for the layout docs
The Miri PR is at: https://github.com/rust-lang/miri/pull/1178
* Add a new method `has_infer_types_or_consts` that's used instead most
of the time, since there's generally no reason to only consider types.
* Remove use of `has_closure_types`, because closures are no longer
implicitly linked to the `InferCtxt`.
When the obligation that couldn't be fulfilled is specific to a nested
obligation, maintain both the nested and parent obligations around for
more accurate and detailed error reporting.
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
parser: `token` -> `normalized_token`, `nonnormalized_token` -> `token`
So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default.
Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically.
This PR uses `normalized_token` for those cases.
Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.)
Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`.
As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though).
The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally).
I want to make it a separate PR for that and run it though perf.
`normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap).
r? @Centril
instantiate_value_path: on `SelfCtor`, avoid unconstrained tyvars
Fixes https://github.com/rust-lang/rust/issues/69306.
On `Self(...)` (that is, a `Res::SelfCtor`), do not use `self.impl_self_ty(...)`. The problem with that method is that it creates unconstrained inference variables for type parameters in the `impl` (e.g. `impl<T> S0<T>`). These variables then eventually get substituted for something else when they come in contact with the expected type (e.g. `S0<u8>`) or merely the arguments passed to the tuple constructor (e.g. the `0` in `Self(0)`).
Instead of using `self.impl_self_ty(...)`, we instead merely use `let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id));` to get the rewritten `res`.
r? @eddyb
Account for bounds and asociated items when denying `_`
Fix#68801, #69204. Follow up to #67597 and #68071.
Output for the original ICE report:
```
Checking vinoteca v5.0.0 (/Users/ekuber/workspace/vinoteca)
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/producers.rs:43:70
|
43 | pub fn top<Table: diesel::Table + diesel::query_dsl::InternalJoinDsl<_, diesel::query_source::joins::Inner, _>>(table: Table, limit: usize, connection: DbConn) -> RestResult<Vec<TopWineType>> {
| ^ not allowed in type signatures ^ not allowed in type signatures
error: aborting due to previous error
```
