| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
|
|
|
|
|
|
|
|
+ lots of rebasing
|
|
In my opinion this looks nicer, but also it matches the whitespace generally
used for stability markers more closely.
|
|
|
|
The Debug impl was using quotes, which was inconsistent:
=> (.., 1.., 2..3, ..4)
("..", 1.., 2..3, ..4)
Fix to use just ..
|
|
|
|
Conflicts:
src/test/compile-fail/coherence-impls-copy.rs
|
|
Feature-gate unsigned unary negate.
Discussed in weekly meeting here: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-03-31.md#feature-gate--expr
and also in the internals thread here: http://internals.rust-lang.org/t/forbid-unsigned-integer/752
|
|
|
|
|
|
The primary purpose of this PR is to add blanket impls for the `Fn` traits of the following (simplified) form:
impl<F:Fn> Fn for &F
impl<F:FnMut> FnMut for &mut F
However, this wound up requiring two changes:
1. A slight hack so that `x()` where `x: &mut F` is translated to `FnMut::call_mut(&mut *x, ())` vs `FnMut::call_mut(&mut x, ())`. This is achieved by just autoderef'ing one time when calling something whose type is `&F` or `&mut F`.
2. Making the infinite recursion test in trait matching a bit more tailored. This involves adding a notion of "matching" types that looks to see if types are potentially unifiable (it's an approximation).
The PR also includes various small refactorings to the inference code that are aimed at moving the unification and other code into a library (I've got that particular change in a branch, these changes just lead the way there by removing unnecessary dependencies between the compiler and the more general unification code).
Note that per rust-lang/rfcs#1023, adding impls like these would be a breaking change in the future.
cc @japaric
cc @alexcrichton
cc @aturon
Fixes #23015.
|
|
|
|
`Fn` traits are considered fundamental, along with `Box` (though that is
mostly for show; the real type is `~T` in the compiler).
|
|
|
|
surprising casts. This version more obviously corresponds to the builtin
semantics.
|
|
|
|
Now that we check the stability of fields, the fields of this struct should also
be stable.
|
|
The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns.
Things enabled by this PR (but not included in this PR):
1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015).
2. A better version of `Thunk` I've been calling `FnBox`.
I did not include either of these in the PR because:
1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion.
2. `FnBox` deserves to be a PR of its own.
The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.)
Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it.
Fixes #18835.
r? @nrc
|
|
references. For collections whose keys are integers, we take both
references and by-value.
|
|
|
|
impls.
This requires:
1. modifying trait selection a bit so that when we synthesize impls for
fn pointers and closures;
2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce`
impl for a `Fn` closure and so forth.
|
|
Now that we check the stability of fields, the fields of this struct should also
be stable.
|
|
|
|
This brings comments in line with https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md#using-markdown
|
|
This stability attribute was left out by accident and the stability pass has
since picked up the ability to check for this. As a result, crates are currently
getting warnings for implementations of `Index`.
|
|
|
|
|
|
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]
|
|
closes #21630
|
|
|
|
|
|
Conflicts:
src/liballoc/lib.rs
src/libcore/ops.rs
|
|
|
|
r? @eddyb
|
|
paren sugar is legal.
|
|
|
|
|
|
|
|
Conflicts:
src/libcollections/slice.rs
src/libcore/nonzero.rs
src/libcore/ops.rs
|
|
involves tweaking things in
the compiler that assumed two input types to assume two ouputs; we also have to teach `project.rs`
to project `Output` from the unboxed closure and fn traits.
|
|
Helps issues like [these](http://www.reddit.com/r/rust/comments/2tpefm/unable_to_access_array_elements/)
r? @Gankro
rollup-worthy
|
|
|
|
|
|
Conflicts:
mk/tests.mk
src/liballoc/arc.rs
src/liballoc/boxed.rs
src/liballoc/rc.rs
src/libcollections/bit.rs
src/libcollections/btree/map.rs
src/libcollections/btree/set.rs
src/libcollections/dlist.rs
src/libcollections/ring_buf.rs
src/libcollections/slice.rs
src/libcollections/str.rs
src/libcollections/string.rs
src/libcollections/vec.rs
src/libcollections/vec_map.rs
src/libcore/any.rs
src/libcore/array.rs
src/libcore/borrow.rs
src/libcore/error.rs
src/libcore/fmt/mod.rs
src/libcore/iter.rs
src/libcore/marker.rs
src/libcore/ops.rs
src/libcore/result.rs
src/libcore/slice.rs
src/libcore/str/mod.rs
src/libregex/lib.rs
src/libregex/re.rs
src/librustc/lint/builtin.rs
src/libstd/collections/hash/map.rs
src/libstd/collections/hash/set.rs
src/libstd/sync/mpsc/mod.rs
src/libstd/sync/mutex.rs
src/libstd/sync/poison.rs
src/libstd/sync/rwlock.rs
src/libsyntax/feature_gate.rs
src/libsyntax/test.rs
|
|
|
|
* `core` - for the core crate
* `hash` - hashing
* `io` - io
* `path` - path
* `alloc` - alloc crate
* `rand` - rand crate
* `collections` - collections crate
* `std_misc` - other parts of std
* `test` - test crate
* `rustc_private` - everything else
|
|
|
