This was a simple case of substitutions being applied inconsistently. I haven't investigated why type parameters are actually showing up in the closure type here, but trans needs to handle them correctly in any case.
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:
1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.
2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.
Fixes#17484
This commit deprecates the entire libtime library in favor of the
externally-provided libtime in the rust-lang organization. Users of the
`libtime` crate as-is today should add this to their Cargo manifests:
[dependencies.time]
git = "https://github.com/rust-lang/time"
To implement this transition, a new function `Duration::span` was added to the
`std::time::Duration` time. This function takes a closure and then returns the
duration of time it took that closure to execute. This interface will likely
improve with `FnOnce` unboxed closures as moving in and out will be a little
easier.
Due to the deprecation of the in-tree crate, this is a:
[breaking-change]
cc #18855, some of the conversions in the `src/test/bench` area may have been a
little nicer with that implemented
This commit deprecates the entire libtime library in favor of the
externally-provided libtime in the rust-lang organization. Users of the
`libtime` crate as-is today should add this to their Cargo manifests:
[dependencies.time]
git = "https://github.com/rust-lang/time"
To implement this transition, a new function `Duration::span` was added to the
`std::time::Duration` time. This function takes a closure and then returns the
duration of time it took that closure to execute. This interface will likely
improve with `FnOnce` unboxed closures as moving in and out will be a little
easier.
Due to the deprecation of the in-tree crate, this is a:
[breaking-change]
cc #18855, some of the conversions in the `src/test/bench` area may have been a
little nicer with that implemented
Substs were not applied when calling `untuple_arguments_if_necessary`.
Just apply them once at the start of the function, rebinding `fty`.
Also change the function to take them by reference since we don't
need to consume them at all. Closes#18883
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:
1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.
2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.
Fixes#17484
Based on Windows bundle feedback we got to date,
- We *do* want to prefer the bundled linker: The external one might be for the wrong architecture (e.g. 32 bit vs 64 bit). On the other hand, binutils don't add many new features these days, so using an older bundled linker is not likely to be a problem.
- We *do* want to prefer bundled libraries: The external ones might not have the symbols we expect (e.g. what's needed for DWARF exceptions vs SjLj). Since `-L rustlib/<triple>/lib` appears first on the linker command line, it's a good place to keep our platform libs that we want to be found first.
Closes#18325, closes#17726.
Various miscellaneous changes pushing towards HRTB support:
1. Update parser and adjust ast to support `for<'a,'b>` syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0).
2. Refactor TyTrait representation to include a TraitRef.
3. Purge `once_fns` feature gate and `once` keyword.
r? @pcwalton
This is a [breaking-change]:
- The `once_fns` feature is now officially deprecated. Rewrite using normal closures or unboxed closures.
- The new `for`-based syntax now issues warnings (but not yet errors):
- `fn<'a>(T) -> U` becomes `for<'a> fn(T) -> U`
- `<'a> |T| -> U` becomes `for<'a> |T| -> U`
`FnOnce` environments that fit within an `int` are passed to the closure by value. For some reason there was an assert that this would only happen if there were 1 or 0 free variables, but it can also happen if there are multiple variables that happen to fit.
Closes#18652
When establishing region links within a pattern, use the mem-cat
of the type the pattern matches against (that is, the result
of `iter.next()`) rather than that of the iterator type.
Closes#17068Closes#18767
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.
This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.
cc #18585
