Update error format for E0062
Fixes#35217 as part of #35233
There seems to be an issue with the old format ignoring the labels which results in the incorrect line being rendered in the old format. I spoke with @jonathandturner about this and it seems to be a bug. Pertinent information [here](https://gist.github.com/trixnz/ad11e68687529e164427df8f8eb63116).
r? @jonathandturner
E0060 e0061 format update
This fixes#35215 and fixes#35216 as part of #35233
A separate issue will be opened to track the bonus portion of the tickets as @jaredwy will be handling that part.
?r @jonathandturner
Updated E0071 to new format.
Bonus: the span underlines only the name of the thing that's not a struct rather than the whole expression.
Part of #35233.
Fixes#35220.
r? @jonathandturner
Update the-stack-and-the-heap.md
Was surprised to learn that heaps were used in this way, then realized upon reading [the linked paper](http://www.cs.cmu.edu/afs/cs/academic/class/15213-f98/doc/dsa.pdf) that it's a totally different type of heap—an important distinction.
Provide more explicit example of wildcard version in guessing game doc.
Beginners may try to adapt the tutorial to develop their own code.
When using different dependencies, they may use the wildcard for
versioning. Since they are new to the language, they will not know
that the wildcard asterisk is a string, not a token. Make the correct
format more explicit, to remove one potential source of frustration.
Add Derive not possible question to Copy
This adds a question and answer to the Q&A section of the Copy
docs. Specifically, it asks the question I asked while reading
the docs, and gives its answer.
cc @steveklabnik
[MIR] Deaggregate structs to enable further optimizations
Currently, we generate MIR like:
```
tmp0 = ...;
tmp1 = ...;
tmp3 = Foo { a: ..., b: ... };
```
This PR implements "deaggregation," i.e.:
```
tmp3.0 = ...
tmp3.1 = ...
```
Currently, the code only deaggregates structs, not enums. My understanding is that we do not have MIR to set the discriminant of an enum.
Properly enforce the "patterns aren't allowed in foreign functions" rule
Cases like `arg @ PATTERN` or `mut arg` were missing.
Apply the same rule to function pointer types.
Closes https://github.com/rust-lang/rust/issues/35203
[breaking-change], no breakage in sane code is expected though
r? @nikomatsakis
This is somewhat related to https://github.com/rust-lang/rfcs/pull/1685 (cc @matklad).
The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
