The example code for higher-ranked trait bounds on closures had an
unnecessary `mut` which was confusing, and the text referred to an
mutable reference which does not exist in the code (and isn't needed).
Removed the `mut`s and fixed the text to better describe the actual
error for the failing example.
mk: add a all-no-docs target to build everything except docs
This makes things slightly more efficient for Debian's auto-builders where the
docs can be built on just one architecture, and distributed to users of all
other architectures as well.
Fix overflow checking in unsigned pow()
The pow() method for unsigned integers produced 0 instead of trapping overflow for certain inputs. Calls such as 2u32.pow(1024) produced 0 when they should trap an overflow. This also adds tests for the correctly handling overflow in unsigned pow().
This was previously fixed for signed integers in #28248, but it seems unsigned integers got missed that time.
For issue number #34913
Optimize the parser's last token handling.
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
librustc_mir: Remove `&*x` when `x` has a reference type.
This introduces a new `InstCombine` pass for us to place such peephole
optimizations.
r? @eddyb
Remove data structure specialization for .zip() iterator
Go back on half the specialization, the part that changed the Zip
struct's fields themselves depending on the types of the iterators.
Previous PR: #33090
This means that the Zip iterator will always carry two usize fields,
which are sometimes unused. If a whole for loop using a .zip() iterator is
inlined, these are simply removed and have no effect.
The same improvement for Zip of for example slice iterators remain, and
they still optimize well. However, like when the specialization of zip
was merged, the compiler is still very sensistive to the exact context.
For example this code only autovectorizes if the function is used, not
if the code in zip_sum_i32 is inserted inline where it was called:
```rust
fn zip_sum_i32(xs: &[i32], ys: &[i32]) -> i32 {
let mut s = 0;
for (&x, &y) in xs.iter().zip(ys) {
s += x * y;
}
s
}
fn zipdot_i32_default_zip(b: &mut test::Bencher)
{
let xs = vec![1; 1024];
let ys = vec![1; 1024];
b.iter(|| {
zip_sum_i32(&xs, &ys)
})
}
```
Include a test that checks that `Zip<T, U>` is covariant w.r.t. T and U.
Fixes#35727
Overhaul char_lit()
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`. The error-handling strategy is based on the one used
by byte_lit().
Avoid loading and parsing unconfigured non-inline modules.
For example, `#[cfg(any())] mod foo;` will always compile after this PR, even if `foo.rs` and `foo/mod.rs` do not exist or do not contain valid Rust.
Fixes#36478 and fixes#27873.
r? @nrc
trans: Let the collector find drop-glue for all vtables, not just VTableImpl.
This fixes#36260. So far, the collector has only recorded drop-glue for insertion into a vtable if the vtable was for an impl. But there's actually no reason why it shouldn't do just the same for closure vtables, afaict.
r? @eddyb
cc @rust-lang/compiler
Try to support py3 with rustbuild better
Annoying to have it fail when you run with `python` only to have to rerun later with `python2`.
r? @alexcrichton
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.
Be more specific when type parameter shadows primitive type
When a type parameter shadows a primitive type, the error message
was non obvious. For example, given the file `file.rs`:
```rust
trait Parser<T> {
fn parse(text: &str) -> Option<T>;
}
impl<bool> Parser<bool> for bool {
fn parse(text: &str) -> Option<bool> {
Some(true)
}
}
fn main() {
println!("{}", bool::parse("ok").unwrap_or(false));
}
```
The output was:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool a
|
= note: expected type `bool`
= note: found type `bool`
error: aborting due to previous error
```
We now show extra information about the type:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool a
|
= note: expected type `bool` (type parameter)
= note: found type `bool` (bool)
error: aborting due to previous error
```
Fixes#35030
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
When a type parameter shadows a primitive type, the error message
was non obvious. For example, given the file `file.rs`:
```rust
trait Parser<T> {
fn parse(text: &str) -> Option<T>;
}
impl<bool> Parser<bool> for bool {
fn parse(text: &str) -> Option<bool> {
Some(true)
}
}
fn main() {
println!("{}", bool::parse("ok").unwrap_or(false));
}
```
The output was:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool`
= note: found type `bool`
error: aborting due to previous error
```
We now show extra information about the type:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool` (type parameter)
= note: found type `bool` (bool)
error: aborting due to previous error
```
Fixes#35030
rustbuild: Fix dependency tracking with new Cargo
The recent Cargo update changed filenames, which broke a lot of incremental
rustbuild builds. What it thought were the output files were indeed no longer
the output files! (wreaking havoc).
This commit updates this to stop guessing filenames of Cargo and just manage
stamp files instead.
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`, and changes the error-handling to use vanilla
assert!() and unwrap().
