And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Per the title. I've linked to the reference at http://doc.rust-lang.org/reference.html#type-parameters-1, but I'm not sure that's such a good link - but there doesn't seem to be a great deal of explanation elsewhere in the reference either...
Internally, the arguments passed to the closure are represented by a
tuple, but the actual function takes them as individual arguments, so we
have to untuple the arguments before creating the debuginfo.
We're currently using the actual function type as the return type when
creating the debug info for a function, so we're actually creating
debug info for a function that takes the same parameters, and returns
the actual function type, which is completely wrong.
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Closes#17546.
Fixes#27014
r? @alexcrichton
I'm not 100% sure there's not a better way to do this, but it works.
Also, I wasn't sure how, where, or if to write a test for this.
Per the top level comment:
A low-level utility for more ergonomically allocating, reallocating, and deallocating a
a buffer of memory on the heap without having to worry about all the corner cases
involved. This type is excellent for building your own data structures like Vec and VecDeque.
In particular:
* Produces heap::EMPTY on zero-sized types
* Produces heap::EMPTY on zero-length allocations
* Catches all overflows in capacity computations (promotes them to "capacity overflow" panics)
* Guards against 32-bit systems allocating more than isize::MAX bytes
* Guards against overflowing your length
* Aborts on OOM
* Avoids freeing heap::EMPTY
* Contains a ptr::Unique and thus endows the user with all related benefits
This type does not in anyway inspect the memory that it manages. When dropped it *will*
free its memory, but it *won't* try to Drop its contents. It is up to the user of RawVec
to handle the actual things *stored* inside of a RawVec.
Note that a RawVec always forces its capacity to be usize::MAX for zero-sized types.
This enables you to use capacity growing logic catch the overflows in your length
that might occur with zero-sized types.
However this means that you need to be careful when roundtripping this type
with a `Box<[T]>`: `cap()` won't yield the len. However `with_capacity`,
`shrink_to_fit`, and `from_box` will actually set RawVec's private capacity
field. This allows zero-sized types to not be special-cased by consumers of
this type.
Edit:
fixes#18726 and fixes#23842
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
