deduplicate projection error (E0271) messages
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
r? @estebank
MIR-borrowck: fix diagnostics for closures
Emit notes for captured variables in the same manner as AST borrowck.
```
error[E0499]: cannot borrow `x` as mutable more than once at a time (Ast)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
error[E0499]: cannot borrow `x` as mutable more than once at a time (Mir)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
```
Fixes#45362.
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
Make saturating u128 -> f32 casts the default behavior
... rather than being gated by `-Z saturating-float-casts`. There are several reasons for this:
1. Const eval already implements this behavior.
2. Unlike with float->int casts, this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in.
3. Having two orthogonal features under one flag is silly, and never should have happened in the first place.
4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any).
Fixes#41799
Implement arbitrary_self_types
r? @arielb1
cc @nikomatsakis
Partial implementation of #44874. Supports trait and struct methods with arbitrary self types, as long as the type derefs (transitively) to `Self`. Doesn't support raw-pointer `self` yet.
Methods with non-standard self types (i.e. anything other than `&self, &mut self, and Box<Self>`) are not object safe, because dynamic dispatch hasn't been implemented for them yet.
I believe this is also a (partial) fix for #27941.
Fix checking of auto trait bounds in trait objects.
Any auto trait is allowed in trait object bounds. Fix duplicate check of type and lifetime parameter count, which we were [emitting twice](https://play.rust-lang.org/?gist=37dbbdbbec62dec423bb8f6d92f137cc&version=stable).
Note: This was the last use of `Send` in the compiler, meaning after a new `stage0` we could remove the `send` lang item.
rustc: add item name to deprecated lint warning
It can sometimes be difficult to know what is actually deprecated when you have `foo.bar()` and `bar` comes from a trait in another crate.
... rather than being gated by -Z saturating-float-casts.
There are several reasons for this:
1. Const eval already implements this behavior.
2. Unlike with float->int casts, this behavior is uncontroversially the
right behavior and it is not as performance critical. Thus there is no
particular need to make the bug fix for u128->f32 casts opt-in.
3. Having two orthogonal features under one flag is silly, and never
should have happened in the first place.
4. Benchmarking float->int casts with the -Z flag should not pick up
performance changes due to the u128->f32 casts (assuming there are any).
Fixes#41799
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
incr.comp.: Verify stability of incr. comp. hashes and clean up various other things.
The main contribution of this PR is that it adds the `-Z incremental-verify-ich` functionality. Normally, when the red-green tracking system determines that a certain query result has not changed, it does not re-compute the incr. comp. hash (ICH) for that query result because that hash is already known. `-Z incremental-verify-ich` tells the compiler to re-hash the query result and compare the new hash against the cached hash. This is a rather thorough way of
- testing hashing implementation stability,
- finding missing `[input]` annotations on `DepNodes`, and
- finding missing read-edges,
since both a missed read and a missing `[input]` annotation can lead to something being marked as green instead of red and thus will have a different hash than it should have.
Case in point, implementing this verification logic and activating it for all `src/test/incremental` tests has revealed several such oversights, all of which are fixed in this PR.
r? @nikomatsakis
Saturating casts between integers and floats
Introduces a new flag, `-Z saturating-float-casts`, which makes code generation for int->float and float->int casts safe (`undef`-free), implementing [the saturating semantics laid out by](https://github.com/rust-lang/rust/issues/10184#issuecomment-299229143) @jorendorff for float->int casts and overflowing to infinity for `u128::MAX` -> `f32`.
Constant evaluation in trans was changed to behave like HIR const eval already did, i.e., saturate for u128->f32 and report an error for problematic float->int casts.
Many thanks to @eddyb, whose APFloat port simplified many parts of this patch, and made HIR constant evaluation recognize dangerous float casts as mentioned above.
Also thanks to @ActuallyaDeviloper whose branchless implementation served as inspiration for this implementation.
cc #10184#41799fixes#45134
Only instantiate inline- and const-fns if they are referenced (again).
It seems that we have regressed on not translating `#[inline]` functions unless they are actually used. This should bring back this optimization. I also added a regression test this time so it doesn't happen again accidentally.
Fixes#40392.
r? @alexcrichton
UPDATE & PSA
---------------------
This patch **makes translation very lazy** -- in general this is a good thing (we don't want the compiler to do unnecessary work) but it has two consequences:
1. Some error messages are only generated when an item is actually translated. Consequently, this patch will lead to more cases where the compiler will only start emitting errors when the erroneous function is actually used. This has always been true to some extend (e.g. when passing generic values to an intrinsic) but since this is something user-facing it's worth mentioning.
2. When writing tests, one has to make sure that the functions in question are actually generated. In other words, it must not be dead code. This can usually be achieved by either
1. making sure the function is exported from the resulting binary or
2. by making sure the function is called from something that is exported (or `main()`).
Note that it depends on the crate type what functions are exported:
1. For rlibs and dylibs everything that is reachable from the outside is exported.
2. For executables, cdylibs, and staticlibs, items are only exported if they are additionally `#[no_mangle]` or have an `#[export_name]`.
The commits in this PR contain many examples of how tests can be updated to comply to the new requirements.
This affects regular code generation as well as constant evaluation in trans,
but not the HIR constant evaluator because that one returns an error for
overflowing casts and NaN-to-int casts. That error is conservatively
correct and we should be careful to not accept more code in constant
expressions.
The changes to code generation are guarded by a new -Z flag, to be able
to evaluate the performance impact. The trans constant evaluation changes
are unconditional because they have no run time impact and don't affect
type checking either.
Pretty print parens around casts on the LHS of `<`/`<<`
When pretty printing a cast expression occuring on the LHS of a `<` or `<<` expression, we should add parens around the cast. Otherwise, the `<`/`<<` gets interpreted as the beginning of the generics for the type on the RHS of the cast.
Consider:
$ cat parens_cast.rs
macro_rules! negative {
($e:expr) => { $e < 0 }
}
fn main() {
negative!(1 as i32);
}
Before this PR, the output of the following is not valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { 1 as i32 < 0; }
After this PR, the output of the following is valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { (1 as i32) < 0; }
I've gone through several README/wiki style documents but I'm still not sure where to test this though. I'm not even sure if this sort of thing is tested...
Handle anon lifetime arg being returned with named lifetime return type
When there's a lifetime mismatch between an argument with an anonymous
lifetime being returned in a method with a return type that has a named
lifetime, show specialized lifetime error pointing at argument with a
hint to give it an explicit lifetime matching the return type.
```
error[E0621]: explicit lifetime required in the type of `other`
--> file2.rs:21:21
|
17 | fn bar(&self, other: Foo) -> Foo<'a> {
| ----- consider changing the type of `other` to `Foo<'a>`
...
21 | other
| ^^^^^ lifetime `'a` required
```
Follow up to #44124 and #42669. Fix#44684.
Allow overriding the TLS model
This PR adds the ability to override the default "global-dynamic" TLS model with a more specific one through a target json option or a command-line option. This allows for better code generation in certain situations.
This is similar to the `-ftls-model=` option in GCC and Clang.
