part of #24407
I'm not sure whether I should be trying to explain the general rule in the E0210 explanation or just point people to the RFC. However, if we go with the latter option I think that the RFC will need to be revised slightly, since it is not quite as gentle as I would like.
Also, the link to RFC 1023 is not the correct one (it should be https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md), but the correct one is too long. I'm aware of @michaelsproul's PR https://github.com/rust-lang/rust/pull/26290 from awhile back, but it doesn't seem to be working. Has there not been a new snapshot yet?
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
This PR completes [RFC 213](https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md) by allowing default type parameters to influence inference. This is almost certainly a breaking change due to interactions between default type parameters and the old fallback algorithm used for integral and floating point literals.
The error messages still require polish but I wanted to get early review and feedback from others on the the changes, error messages, and test cases. I also imagine we will want to run anywhere from 1-3 versions of this on crater and evaluate the impact, and it would be best to get that ball rolling.
The only outstanding issue I'm aware of is that type alias defaults don't work. It seems this may require significant restructuring, since during inference type aliases have already been expanded. @nikomatsakis might be able to provide some clarity here.
r? @nikomatsakis
cc @eddyb @Gankro @aturon @brson
The algorithm was not correctly detecting conflicts after moving
defaults into TypeVariableValue. The updated algorithm
correctly detects and reports conflicts with information about
where the conflict occured and which items the defaults were
introduced by. The span's for said items are not being correctly
attached and still need to be patched.
This patch allows type parameter defaults to influence type inference. This is a possible breaking change since it effects the way type inference works and will have different behavior when mixing defaults and literal fallback.
The borrow checker doesn't allow constructing such a type at runtime
using safe code, but there isn't any reason to ban them in the type checker.
Included in this commit is an example of a neat static doubly-linked list.
Feature-gated under the static_recursion gate to be on the safe side, but
there are unlikely to be any reasons this shouldn't be turned on by
default.
This fixes a few soundness bugs in dropck, so to anyone who relied on them,
this is a
[breaking-change]
Fixes#24086.
Fixes#25389.
Fixes#25598.
Fixes#25750.
Fixes#26641.
Fixes#26657.
Fixes#27240.
Fixes#27241.
As title!
I should probably be bunching these up a bit more, but I'm not sure when my time is going to disappear on me. Once my schedule stabilises I'll try to start batching them into larger PRs.
Part of #24407.
r? @Manishearth
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment.
As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes#25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954.
(As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.)
r? @nrc
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
