This commit is another in the series of vector slice API stabilization. The focus here is the *mutable* slice API.
Largely, this API inherits the stability attributes [previously assigned](rust-lang#16332) to the analogous methods on immutable slides. It also adds comments to a few `unstable` attributes that were previously missing them.
In addition, the commit adds several `_mut` variants of APIs that were missing:
- `init_mut`
- `head_mut`
- `tail_mut`
- `splitn_mut`
- `rsplitn_mut`
Some of the unsafe APIs -- `unsafe_set`, `init_elem`, and `copy_memory` -- were deprecated in favor of working through `as_mut_ptr`, to simplify the API surface.
Due to deprecations, this is a:
[breaking-change]
The tuple serialization logic should be using the tuple-specific emit function. This fixes part of #17158. The JSON encoder already proxies to `emit_seq_elt` when `emit_tuple_arg` is called, so this should have an effect.
This commit is another in the series of vector slice API
stabilization. The focus here is the *mutable* slice API.
Largely, this API inherits the stability attributes [previously
assigned](https://github.com/rust-lang/rust/pull/16332) to the analogous
methods on immutable slides. It also adds comments to a few `unstable`
attributes that were previously missing them.
In addition, the commit adds several `_mut` variants of APIs that were
missing:
- `init_mut`
- `head_mut`
- `tail_mut`
- `splitn_mut`
- `rsplitn_mut`
Some of the unsafe APIs -- `unsafe_set`, `init_elem`, and `copy_memory`
-- were deprecated in favor of working through `as_mut_ptr`, to simplify
the API surface.
Due to deprecations, this is a:
[breaking-change]
Moves the vast majority of builtin bound checking out of type contents and into the trait system.
This is a preliminary step for a lot of follow-on work:
- opt-in builtin types, obviously
- generalized where clauses, because TypeContents has this notion that a type parameter has a single set of builtin kinds, but with where clauses it depends on context
- generalized coherence, because this adds support for recursive trait selection
Unfortunately I wasn't able to completely remove Type Contents from the front-end checking in this PR. It's still used by EUV to decide what gets moved and what doesn't.
r? @pcwalton
Intended to prevent each user to write his own partial_min/max, possibly differing in slight details. @sfackler encouraged to PR this on IRC.
(Let's hope this works... First PR.)
OrdIterator: the doc says that values must implement `PartialOrd`, while the implementation is only for `Ord` values. It looks like this initially got out of sync in 4e1c215. Removed the doc sentence entirely since it seems redundant.
MultiplicativeIterator: Fixed weird sentence.
This is a PR for #16114 and includes to following things:
* Rename `begin_unwind` lang item to `fail_fmt`
* Rename `core::failure::begin_unwind` to `fail_impl`
* Rename `fail_` lang item to `fail`
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree` is part of the complete rewrite in #17334.
The implemented API deviates from the API described in the RFC in two key places:
* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.
This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.
[breaking-change]
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
although this still needs to be done on the rest of the maps, they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree`'s is part of the complete rewrite in #17334.
The implemented API deviates from the API described in the RFC in two key places:
* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.
This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.
[breaking-change]
Add checks for null bytes in the value strings for the export_name and link_section attributes, reporting an error if any are found, before calling with_c_str on them.
Fixes#16478
# Rationale
When dealing with strings, many functions deal with either a `char` (unicode
codepoint) or a byte (utf-8 encoding related). There is often an inconsistent
way in which methods are referred to as to whether they contain "byte", "char",
or nothing in their name. There are also issues open to rename *all* methods to
reflect that they operate on utf8 encodings or bytes (e.g. utf8_len() or
byte_len()).
The current state of String seems to largely be what is desired, so this PR
proposes the following rationale for methods dealing with bytes or characters:
> When constructing a string, the input encoding *must* be mentioned (e.g.
> from_utf8). This makes it clear what exactly the input type is expected to be
> in terms of encoding.
>
> When a method operates on anything related to an *index* within the string
> such as length, capacity, position, etc, the method *implicitly* operates on
> bytes. It is an understood fact that String is a utf-8 encoded string, and
> burdening all methods with "bytes" would be redundant.
>
> When a method operates on the *contents* of a string, such as push() or pop(),
> then "char" is the default type. A String can loosely be thought of as being a
> collection of unicode codepoints, but not all collection-related operations
> make sense because some can be woefully inefficient.
# Method stabilization
The following methods have been marked #[stable]
* The String type itself
* String::new
* String::with_capacity
* String::from_utf16_lossy
* String::into_bytes
* String::as_bytes
* String::len
* String::clear
* String::as_slice
The following methods have been marked #[unstable]
* String::from_utf8 - The error type in the returned `Result` may change to
provide a nicer message when it's `unwrap()`'d
* String::from_utf8_lossy - The returned `MaybeOwned` type still needs
stabilization
* String::from_utf16 - The return type may change to become a `Result` which
includes more contextual information like where the error
occurred.
* String::from_chars - This is equivalent to iter().collect(), but currently not
as ergonomic.
* String::from_char - This method is the equivalent of Vec::from_elem, and has
been marked #[unstable] becuase it can be seen as a
duplicate of iterator-based functionality as well as
possibly being renamed.
* String::push_str - This *can* be emulated with .extend(foo.chars()), but is
less efficient because of decoding/encoding. Due to the
desire to minimize API surface this may be able to be
removed in the future for something possibly generic with
no loss in performance.
* String::grow - This is a duplicate of iterator-based functionality, which may
become more ergonomic in the future.
* String::capacity - This function was just added.
* String::push - This function was just added.
* String::pop - This function was just added.
* String::truncate - The failure conventions around String methods and byte
indices isn't totally clear at this time, so the failure
semantics and return value of this method are subject to
change.
* String::as_mut_vec - the naming of this method may change.
* string::raw::* - these functions are all waiting on [an RFC][2]
[2]: rust-lang/rfcs#240
The following method have been marked #[experimental]
* String::from_str - This function only exists as it's more efficient than
to_string(), but having a less ergonomic function for
performance reasons isn't the greatest reason to keep it
around. Like Vec::push_all, this has been marked
experimental for now.
The following methods have been #[deprecated]
* String::append - This method has been deprecated to remain consistent with the
deprecation of Vec::append. While convenient, it is one of
the only functional-style apis on String, and requires more
though as to whether it belongs as a first-class method or
now (and how it relates to other collections).
* String::from_byte - This is fairly rare functionality and can be emulated with
str::from_utf8 plus an assert plus a call to to_string().
Additionally, String::from_char could possibly be used.
* String::byte_capacity - Renamed to String::capacity due to the rationale
above.
* String::push_char - Renamed to String::push due to the rationale above.
* String::pop_char - Renamed to String::pop due to the rationale above.
* String::push_bytes - There are a number of `unsafe` functions on the `String`
type which allow bypassing utf-8 checks. These have all
been deprecated in favor of calling `.as_mut_vec()` and
then operating directly on the vector returned. These
methods were deprecated because naming them with relation
to other methods was difficult to rationalize and it's
arguably more composable to call .as_mut_vec().
* String::as_mut_bytes - See push_bytes
* String::push_byte - See push_bytes
* String::pop_byte - See push_bytes
* String::shift_byte - See push_bytes
# Reservation methods
This commit does not yet touch the methods for reserving bytes. The methods on
Vec have also not yet been modified. These methods are discussed in the upcoming
[Collections reform RFC][1]
[1]: https://github.com/aturon/rfcs/blob/collections-conventions/active/0000-collections-conventions.md#implicit-growth
Setting LC_ALL to C helps keep gdb's output consistent ('print' gives us expected output). This fixes#17423. I do not have access to a windows/mac machines to test this. I've only tested it on an x86_64 linux box.
This PR adds a new Vim compiler file specifically for use with Cargo. It passes all arguments through, so commands like `:make build`, `:make clean`, and `:make run` all work as expected.
It also adds a quickfix autocommand for fixing the paths before populating the error list. `cargo build` reports errors with file paths that are relative to Cargo.toml, so if you're further down in the project tree, then trying to open the error will result in a blank buffer because Vim treats that path as relative to the working directory instead. With this fix, the paths work properly no matter where you are in the project.
Right now, libuv will **always** be built for the host system (at least when building on OSX) because the information about the cross compiler is never actually passed to GYP. I don't know how anybody has been managing to build cross compilers with this.
Note that, at least on OSX, there is a bug in GYP that will send clang flags to non-clang compilers and it will still attempt to use Xcode's libtool, so this doesn't completely fix the problem of cross-compiling on an OSX host, but it's a start.
OrdIterator: the doc says that values must implement `PartialOrd`, while the implementation is only for `Ord` values. It looks like this initially got out of sync in 4e1c215. Removed the doc sentence entirely since it seems redundant.
MultiplicativeIterator: Fixed weird sentence.
When I fixed the previous issue with rational rounding, I had introduced a regression. There was also an overflow bug introduced for fixed-precision rationals. This patch corrects both bugs.
