| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes #22467
[breaking-change]
|
|
This overlaps with #22276 (I left make check running overnight) but covers a number of additional cases and has a few rewrites where the clones are not even necessary.
This also implements `RandomAccessIterator` for `iter::Cloned`
cc @steveklabnik, you may want to glance at this before #22281 gets the bors treatment
|
|
This commit is an implementation of [RFC 592][r592] and [RFC 840][r840]. These
two RFCs tweak the behavior of `CString` and add a new `CStr` unsized slice type
to the module.
[r592]: https://github.com/rust-lang/rfcs/blob/master/text/0592-c-str-deref.md
[r840]: https://github.com/rust-lang/rfcs/blob/master/text/0840-no-panic-in-c-string.md
The new `CStr` type is only constructable via two methods:
1. By `deref`'ing from a `CString`
2. Unsafely via `CStr::from_ptr`
The purpose of `CStr` is to be an unsized type which is a thin pointer to a
`libc::c_char` (currently it is a fat pointer slice due to implementation
limitations). Strings from C can be safely represented with a `CStr` and an
appropriate lifetime as well. Consumers of `&CString` should now consume `&CStr`
instead to allow producers to pass in C-originating strings instead of just
Rust-allocated strings.
A new constructor was added to `CString`, `new`, which takes `T: IntoBytes`
instead of separate `from_slice` and `from_vec` methods (both have been
deprecated in favor of `new`). The `new` method returns a `Result` instead of
panicking. The error variant contains the relevant information about where the
error happened and bytes (if present). Conversions are provided to the
`io::Error` and `old_io::IoError` types via the `FromError` trait which
translate to `InvalidInput`.
This is a breaking change due to the modification of existing `#[unstable]` APIs
and new deprecation, and more detailed information can be found in the two RFCs.
Notable breakage includes:
* All construction of `CString` now needs to use `new` and handle the outgoing
`Result`.
* Usage of `CString` as a byte slice now explicitly needs a `.as_bytes()` call.
* The `as_slice*` methods have been removed in favor of just having the
`as_bytes*` methods.
Closes #22469
Closes #22470
[breaking-change]
|
|
they are used without a feature-gate. This is both kinder to existing
code and should make it easier to land this PR, since we don't
have to catch EVERY SINGLE SUFFIX.
|
|
This breaks all implementors of FromIterator, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument).
Users of FromIterator should be unaffected because Iterators are IntoIterator.
[breaking-change]
|
|
This breaks all implementors of Extend, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument).
Users of Extend should be unaffected because Iterators are IntoIterator.
[breaking-change]
|
|
This commit implements RFC 580 by renaming:
* DList -> LinkedList
* Bitv -> BitVec
* BitvSet -> BitSet
* RingBuf -> VecDeque
More details are in [the
RFC](https://github.com/rust-lang/rfcs/pull/580)
[breaking-change]
|
|
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes #22467
[breaking-change]
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/rustbook/main.rs
|
|
|
|
|
|
* Move the type parameter on the `AsciiExt` trait to an associated type named
`Owned`.
* Move `ascii::escape_default` to using an iterator.
This is a breaking change due to the removal of the type parameter on the
`AsciiExt` trait as well as the modifications to the `escape_default` function
to returning an iterator. Manual implementations of `AsciiExt` (or `AsciiExt`
bounds) should be adjusted to remove the type parameter and using the new
`escape_default` should be relatively straightforward.
[breaking-change]
|
|
This commit renames the features for the `std::old_io` and `std::old_path`
modules to `old_io` and `old_path` to help facilitate migration to the new APIs.
This is a breaking change as crates which mention the old feature names now need
to be renamed to use the new feature names.
[breaking-change]
|
|
This commit performs a stabilization pass over the `std::ascii` module taking
the following actions:
* the module name is now stable
* `AsciiExt` is now stable after moving its type parameter to an `Owned`
associated type
* `AsciiExt::is_ascii` is now stable
* `AsciiExt::to_ascii_uppercase` is now stable
* `AsciiExt::to_ascii_lowercase` is now stable
* `AsciiExt::eq_ignore_ascii_case` is now stable
* `AsciiExt::make_ascii_uppercase` is added to possibly replace
`OwnedAsciiExt::into_ascii_uppercase` (similarly for lowercase variants).
* `escape_default` now returns an iterator and is stable
* `EscapeDefault` is now stable
Trait implementations are now also marked stable.
Primarily it is still unstable to *implement* the `AsciiExt` trait due to it
containing some unstable methods.
[breaking-change]
|
|
Pass features along during expansion
Use the set of passed features to detect uses of feature-gated macros without the corresponding feature enabled.
Fix #22234.
----
Also, the framework this add (passing along a reference to the features in the expansion context) is a necessary precursor for landing a properly feature-gated desugaring-based overloaded-`box` and placement-`in` (#22181).
----
This is fixing a bug, but since there might be code out there that is unknowingly taking advantage of that bug, I feel obligated to mark this as a:
[breaking-change]
|
|
fixes #22203
r? @nikomatsakis
This breaks code that might be using attributes randomly, so it's technically a
[breaking-change]
|
|
|
|
|
|
|
|
mostly improved, to my eye.
Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change].
In practice, breakage is focused on functions of this form:
```rust
fn foo(..., object: Box<FnMut()>)
````
where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument
position so that they were bounded by a fresh lifetime:
```rust
fn foo<'a>(..., object: Box<FnMut()+'a>)
```
This meant that the object could contain borrowed data. The newer
scheme defaults to a lifetime bound of `'static`:
```rust
fn foo(..., object: Box<FnMut()+'static>)
```
This means that the object cannot contain borrowed data. In some cases, the best fix
is to stop using `Box`:
```rust
fn foo(..., object: &mut FnMut())
```
but another option is to write an explicit annotation for the `'a`
lifetime that used to be implicit. Both fixes are demonstrated in
this commit.
|
|
- We shouldn't be using `check_name` here at all
- `contains_name(ref_slice(foo), bar)` is redundant, `contains_name` just iterates over its first arg and calls `check_name`
- match would be better than a bunch of ifs
|
|
|
|
syntax::feature_gate
|
|
The other cases: `concat_idents!`, `log_syntax!`, and `trace_macros!`,
(these macros, with `asm!`, are handled (eagerly) in feature_gate.rs).
|
|
|
|
|
|
|
|
It's not clear what this means, because a macro in item position can expand to zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect, which seems quite unintended.
Fixes #18317.
Fixes #14660.
|
|
Fixes #17436.
|
|
Some function signatures have changed, so this is a [breaking-change].
In particular, radixes and numerical values of digits are represented by `u32` now.
Part of #22240
|
|
r=steveklabnik
Added all active features to the list in reference.md.
Added a second note about keeping the reference.md list up-to-date to the bottom of the list, since not everyone (including me) reads the big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in alphabetical order.
|
|
r=nikomatsakis
Re-tag `slicing_syntax` as `Accepted`.
Rollup merge (373cbab5b08d6630da58f28d2166c19afc327fa6) of PR #20723
accidentally reverted a portion of commit
8327bcc167661c26ca5c6b967309ff745d302329 which shifted
`slicing_syntax` from Active to Accepted.
|
|
|
|
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes #22137
|
|
It's not clear what this means, because a macro in item position can expand to
zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect,
which seems quite unintended.
Fixes #18317.
Fixes #14660.
|
|
Fixes #17436.
|
|
Added a second note about keeping the reference.md list up-to-date to
the bottom of the list, since not everyone (including me) reads the
big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in
alphabetical order.
|
|
Rollup merge (373cbab5b08d6630da58f28d2166c19afc327fa6) of PR #20723
accidentally reverted a portion of commit
8327bcc167661c26ca5c6b967309ff745d302329 which shifted
`slicing_syntax` from Active to Accepted.
|
|
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes #22137
|
|
|
|
|
|
Conflicts:
src/libsyntax/feature_gate.rs
|
|
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
|
|
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
|
|
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local::imp::Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes #8962
Closes #16360
Closes #20327
[breaking-change]
|
|
just say "experimental."
|
