The following methods, types, and names have become stable:
* Vec
* Vec::as_mut_slice
* Vec::as_slice
* Vec::capacity
* Vec::clear
* Vec::default
* Vec::grow
* Vec::insert
* Vec::len
* Vec::new
* Vec::pop
* Vec::push
* Vec::remove
* Vec::set_len
* Vec::shrink_to_fit
* Vec::truncate
* Vec::with_capacity
The following have become unstable:
* Vec::dedup // naming
* Vec::from_fn // naming and unboxed closures
* Vec::get_mut // will be removed for IndexMut
* Vec::grow_fn // unboxed closures and naming
* Vec::retain // unboxed closures
* Vec::swap_remove // uncertain naming
* Vec::from_elem // uncertain semantics
* vec::unzip // should be generic for all collections
The following have been deprecated
* Vec::append - call .extend()
* Vec::append_one - call .push()
* Vec::from_slice - call .to_vec()
* Vec::grow_set - call .grow() and then .push()
* Vec::into_vec - move the vector instead
* Vec::move_iter - renamed to iter_move()
* Vec::to_vec - call .clone()
The following methods remain experimental pending conventions
* vec::raw
* vec::raw::from_buf
* Vec:from_raw_parts
* Vec::push_all
This is a breaking change in terms of the signature of the `Vec::grow` function.
The argument used to be taken by reference, but it is now taken by value. Code
must update by removing a leading `&` sigil or by calling `.clone()` to create a
value.
[breaking-change]
Display an explicit message about items missing after sugared doc
comment attributes. References #2789.
* I tried looking through `parser.rs` for an appropriate location for `expected_item_err` and ended up putting it just above the first use. Is there a better location?
* Did I add enough test cases? Too many? Should I add more cases for the original error message?
If you didn't have a trailing comma at the end of the variants, you could use
any type you wanted, but if you used a trailing comma the macro would
erroneously require the bits be a u32.
Later compiler passes are not prepared to deal with deref of
`ty_bot` and will generate various ICEs, so disallow it outright for now.
Closes issue #17373
If you didn't have a trailing comma at the end of the variants, you could use
any type you wanted, but if you used a trailing comma the macro would
erroneously require the bits be a u32.
