The old code is temporarily needed in order to keep the MSVC build
working. It should be possible to remove this code after the bootstrap
compiler is updated to contain the MSVC workaround from #27875.
The implementation of the remainder operation belongs to
librustc_trans, but it is also stubbed out in libcore in order to
expose it as a trait on primitive types. Instead of exposing some
implementation details (like the upcast to `f64` in MSVC), use a
minimal implementation just like that of the `Div` trait.
There wasn't any particular reason the functions needed to be there
anyway, so just get rid of them, and adjust libstd to compensate.
With this change, libcore depends on exactly two floating-point functions:
fmod and fmodf. They are implicitly referenced because they are used to
implement "%".
Dependencies of libcore on Linux x86-x64 with this patch:
```
0000000000000000 *UND* 0000000000000000 __powidf2
0000000000000000 *UND* 0000000000000000 __powisf2
0000000000000000 *UND* 0000000000000000 fmod
0000000000000000 *UND* 0000000000000000 fmodf
0000000000000000 *UND* 0000000000000000 memcmp
0000000000000000 *UND* 0000000000000000 memcpy
0000000000000000 *UND* 0000000000000000 memset
0000000000000000 *UND* 0000000000000000 rust_begin_unwind
0000000000000000 *UND* 0000000000000000 rust_eh_personality
```
There wasn't any particular reason the functions needed to be there
anyway, so just get rid of them, and adjust libstd to compensate.
With this change, libcore depends on exactly two floating-point functions:
fmod and fmodf. They are implicitly referenced because they are
used to implement "%".
It turns out that the 32-bit toolchain for MSVC has many of these functions as
`static inline` functions in header files so there's not actually a symbol for
Rust to call. All of the implementations just cast floats to their 64-bit
variants and then cast back to 32-bit at the end, so the standard library now
takes this strategy.
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
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.
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
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.
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`.
