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
I wanted to embed an `Rc<TraitRef>`, but I was foiled by the current
static rules, which prohibit non-Sync values from being stored in
static locations. This means that the constants for `ty_int` and so
forth cannot be initialized.
This resolves some issues that remained after adding support for monomorphizing unboxed closures in trans.
There were a few places where a set of substitutions for an unboxed closure type were dropped on the floor and later recalculated from scratch based on the def ID, but this failed spectacularly when the closure originated from a different param environment. The substitutions are now plumbed through end-to-end. Closes#18661
There was also a conflict in the meaning of the self param space within the body of the unboxed closure. Trans attempted to insert the unboxed closure type as the self type, but this could conflict with the self type from the param environment when an unboxed closure was used within a default method on a trait. Since the body of an unboxed closure cannot refer to its own self type or value, there's no need for it to actually use the self space. The downstream consumers of the substitutions in trans do not seem to need it either since they look up the type of the closure some other way, so I just stopped setting it. Closes#18685.
r? @pcwalton @nikomatsakis
Fixes#18567. `Struct{x:foo, .. with_expr}` did not walk `with_expr`, which allowed
using moved variables in some cases. The CFG for structs also built up with
`with_expr` happening before the fields, which is now reversed. (Fields are now
before the `with_expr` in the CFG)
As an optimization, once unboxed closures receive their environment by
value if it fits within the size of an `int`. An assert in this code
path assumed that this would only occur if the environment had no more
than a single free variable in it, but multiple smaller free variables
can easily be packed into the space of an `int`, particularly if any
of them are 0-sized. The assert can simply be removed.
Closes#18652
- When selecting an implicit trait impl for an unboxed closure, plumb
through and use the substitutions from impl selection instead of
using those from the current param environment in trans, which may
be incorrect.
- When generating a function declaration for an unboxed closure, plumb
through the substitutions from the param environment of the closure
as above. Also normalize the type to avoid generating duplicate
declarations due to regions being inconsistently replaced with
ReStatic elsewhere.
- Do not place the closure type in the self param space when
translating the unboxed closure callee, etc. It is not actually
used, and doing so conflicts with the self substitution from
default trait methods.
Closes#18661Closes#18685
Fixes#18567. Struct{x:foo, .. with_expr} did not walk with_expr, which allowed
using moved variables in some cases. The CFG for structs also built up with
with_expr happening before the fields, which is now reversed. (Fields are now
before the with_expr in the CFG)
variables in the intracrate case. This requires a deeper distinction
between inter- and intra-crate so as to keep coherence working.
I suspect the best fix is to generalize the recursion check that
exists today, but this requires a bit more refactoring to achieve.
(In other words, where today it says OK for an exact match, we'd want
to not detect exact matches but rather skolemize each trait-reference
fresh and return AMBIG -- but that requires us to make builtin bounds
work shallowly like everything else and move the cycle detection into
the fulfillment context.)
This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.
This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.
One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.
Fixes#4920.
Fixes#16821.
Fixes#15757.
cc @alexcrichton
cc @aturon
Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
This fixes some metadata/AST encoding problems that lead to ICEs. The way this is currently handled will need revisiting if abstract return types are added, as unboxed closure types from extern crates could show up without being inlined into the local crate.
Closes#16790 (I think this was fixed earlier by accident and just needed a test case)
Closes#18378Closes#18543
r? @pcwalton
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
This almost completely avoids GEPi's and pointer manipulation,
postponing it until the end with one big write of the whole vector. This
leads to a small speed-up in compilation, and makes it easier for LLVM
to work with the values, e.g. with `--opt-level=0`,
pub fn foo() -> f32x4 {
f32x4(0.,0.,0.,0.)
}
was previously compiled to
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
%sret_slot = alloca <4 x float>
%0 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 0
store float 0.000000e+00, float* %0
%1 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 1
store float 0.000000e+00, float* %1
%2 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 2
store float 0.000000e+00, float* %2
%3 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 3
store float 0.000000e+00, float* %3
%4 = load <4 x float>* %sret_slot
ret <4 x float> %4
}
but now becomes
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
ret <4 x float> zeroinitializer
}
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
