The wording of RFC #495 enables moves out of slices. Unfortuantely, non-zeroing
moves out of slices introduce a very annoying complication: as slices can
vary in their length, indexes from the start and end may or may not overlap
depending on the slice's exact length, which prevents assigning a particular
drop flag for each individual element.
For example, in the code
```Rust
fn foo<T>(a: Box<[Box<[T]>]>, c: bool) -> T {
match (a, c) {
(box [box [t, ..], ..], true) => t,
(box [.., box [.., t]], false) => t,
_ => panic!()
}
}
```
If the condition is false, we have to drop the first element
of `a`, unless `a` has size 1 in which case we drop all the elements
of it but the last.
If someone comes with a nice way of handling it, we can always re-allow
moves out of slices.
This is a [breaking-change], but it is behind the `slice_patterns` feature
gate and was not allowed until recently.
clear obligations-added flag with nested fulfillcx
This flag is a debugging measure designed to detect cases where we start
a snapshot, create type variables, register obligations involving those
type variables in the fulfillment cx, and then have to unroll the
snapshot, leaving "dangling type variables" behind. HOWEVER, in some
cases the flag is wrong. In particular, we sometimes create a
"mini-fulfilment-cx" in which we enroll obligations. As long as this
fulfillment cx is fully drained before we return, this is not a problem,
as there won't be any escaping obligations in the main cx. So we add a
fn to save/restore the flag.
Fixes#36053.
r? @arielb1
Assign node ids during macro expansion
After this PR,
- The `ExtCtxt` can access `resolve`'s `Resolver` through the trait object `ext::base::Resolver`.
- The `Resolver` trait object can load macros and replaces today's `MacroLoader` trait object.
- The macro expander uses the `Resolver` trait object to resolve macro invocations.
- The macro expander assigns node ids and builds the `Resolver`'s `macros_at_scope` map.
- This is groundwork for merging import resolution and expansion.
- Performance of expansion together with node id assignment improves by ~5%.
**EDIT:** Since Github is reordering the commits, here is `git log`:
- b54e1e3997: Differentiate between monotonic and non-monotonic expansion and only assign node ids during monotonic expansion.
- 78c0039878: Expand generated test harnesses and macro registries.
- f3c2dca353: Remove scope placeholders from the crate root.
- c86c8d41a2: Perform node id assignment and `macros_at_scope` construction during the `InvocationCollector` and `PlaceholderExpander` folds.
- 72a636975f: Move macro resolution into `librustc_resolve`.
- 20b43b2323: Rewrite the unit tests in `ext/expand.rs` as a `compile-fail` test.
- a9821e1658: Refactor `ExtCtxt` to use a `Resolver` instead of a `MacroLoader`.
- 60440b226d: Refactor `noop_fold_stmt_kind` out of `noop_fold_stmt`.
- 50f94f6c95: Avoid needless reexpansions.
r? @nrc
Improve shallow `Clone` deriving
`Copy` unions now support `#[derive(Clone)]`.
Less code is generated for `#[derive(Clone, Copy)]`.
+
Unions now support `#[derive(Eq)]`.
Less code is generated for `#[derive(Eq)]`.
---
Example of code reduction:
```
enum E {
A { a: u8, b: u16 },
B { c: [u8; 100] },
}
```
Before:
```
fn clone(&self) -> E {
match (&*self,) {
(&E::A { a: ref __self_0, b: ref __self_1 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
::std::clone::assert_receiver_is_clone(&(*__self_1));
*self
}
(&E::B { c: ref __self_0 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
*self
}
}
}
```
After:
```
fn clone(&self) -> E {
{
let _: ::std::clone::AssertParamIsClone<u8>;
let _: ::std::clone::AssertParamIsClone<u16>;
let _: ::std::clone::AssertParamIsClone<[u8; 100]>;
*self
}
}
```
All the matches are removed, bound assertions are more lightweight.
`let _: Checker<CheckMe>;`, unlike `checker(&check_me);`, doesn't have to be translated by rustc_trans and then inlined by LLVM, it doesn't even exist in MIR, this means faster compilation.
---
Union impls are generated like this:
```
union U {
a: u8,
b: u16,
c: [u8; 100],
}
```
```
fn clone(&self) -> U {
{
let _: ::std::clone::AssertParamIsCopy<Self>;
*self
}
}
```
Fixes https://github.com/rust-lang/rust/issues/36043
cc @durka
r? @alexcrichton
This flag is a debugging measure designed to detect cases where we start
a snapshot, create type variables, register obligations involving those
type variables in the fulfillment cx, and then have to unroll the
snapshot, leaving "dangling type variables" behind. HOWEVER, in some
cases the flag is wrong. In particular, we sometimes create a
"mini-fulfilment-cx" in which we enroll obligations. As long as this
fulfillment cx is fully drained before we return, this is not a problem,
as there won't be any escaping obligations in the main cx. So we add a
fn to save/restore the flag.
crate-ify compiler-rt into compiler-builtins
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics - this is a [breaking-change]. Users
of the `std` have to do nothing extra as the std crate depends
on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes#34400
---
r? @alexcrichton
Update E0297 to new error format
Fixes#35521.
Part of #35233.
I didn't attempt the bonus of narrowing the span to focus on the "for `<pattern>`" piece (it's my first time contributing), but I'm happy to do so given some hints.
r? @jonathandturner
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes#34400
The span labels for associated types and consts were hardcoded to `Foo`
rather than substituting the name of the trait.
This also normalizes the wording for associated methods', traits', and
consts' span labels.
Fixes#36428.
Add s390x support
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Update the wording for E0063. This will truncate the fields to 3.
Instead of listing every field it will now show missing `a`, `z`, `b`, and 1 other field
This is for #35218 as part of #35233
r? @jonathandturner
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Fix soundness bug described in #29859
This is an attempt at fixing the problems described in #29859 based on an IRC conversation between @nikomatsakis and I today. I'm waiting on a full build to come back, otherwise both tests trigger the correct error.
resolve: Suggest `use self` when import resolves
Improves errors messages by replacing "Maybe a missing `extern crate`" messages
with "Did you mean `self::...`" when the `self` import would succeed.
Fixes#34191.
Thank you for the help @jseyfried!
Fix "field is never used" warning to take unions into account
When compiling code containing a union with an unused field, rustc says
"struct field is never used".
Rather than saying "struct or union", or adding logic to determine the
type of the item, just change the message to "field is never used",
dropping the "struct".
Update tests accordingly.
Updated E0559 to new format
Refactored a method that printed one suggested field name,
into a method that returns an `Option` of a suggestion
(Updated test cases accordingly)
r? @jonathandturner
Closes#36197
Update Error format for E0516, E0517, E0518
- E0518 Update error format #36111
- E0517 Update error format #36109
- E0516 Update error format #36108
- Part of #35233
r? @jonathandturner
