| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
Accept interpolated patterns in trait method parameters
Permit this, basically
```rust
macro_rules! m {
($pat: pat) => {
trait Tr {
fn f($pat: u8) {}
}
}
}
```
it previously caused a parsing error during expansion because trait methods accept only very restricted set of patterns during parsing due to ambiguities caused by [anonymous parameters](https://github.com/rust-lang/rust/issues/41686), and this set didn't include interpolated patterns.
Some outdated messages from "no patterns allowed" errors are also removed.
Addresses https://github.com/rust-lang/rust/issues/35203#issuecomment-341937159
|
|
|
|
Remove some outdated messages from "no patterns allowed" errors
|
|
restore move out dataflow, add report of move out errors
fix https://github.com/rust-lang/rust/issues/45363
r? @arielb1
|
|
r=nikomatsakis
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.
|
|
Make positional argument error in format! clearer
r? @estebank
Fixes #44954
|
|
Updated tests
Fixes #45702
|
|
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.
|
|
resolve: Use same rules for disambiguating fresh bindings in `match` and `let`
Resolve `Unit` as a unit struct pattern in
```rust
struct Unit;
let Unit = x;
```
consistently with
```rust
match x {
Unit => {}
}
```
It was previously an error.
(The change also applies to unit variants and constants.)
Fixes https://users.rust-lang.org/t/e0530-cannot-shadow-unit-structs-what-in-the-earthly-what/13054
(This particular change doesn't depend on a fix for the issue mentioned in https://users.rust-lang.org/t/e0530-cannot-shadow-unit-structs-what-in-the-earthly-what/13054/4)
cc @rust-lang/lang
r? @nikomatsakis
|
|
[intrinsics] add missing div and rem vector intrinsics
|
|
fixes to MIR effectck
r? @eddyb
beta-nominating because regression (MIR effectck is new)
|
|
Fix help for duplicated names: `extern crate (...) as (...)`
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
Fix #45829.
|
|
|
|
Normalizing method signatures can unify inference variables, which can
cause receiver unification to fail. Unify the receivers first to avoid
that.
Fixes #36701.
Fixes #45801.
Fixes #45855.
|
|
|
|
now that we've fixed the bug where constraint origins were getting overwritten, the good error messages are back (with some tweaks)
|
|
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
|
|
put the error message on one line so the test suite does not think it is two errors
use a substring of the error message so it fits in 100 chars for tidy
|
|
|
|
Detect `=` -> `:` typo in let bindings
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
Fix #43703.
|
|
|
|
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
|
|
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 #41799
fixes #45134
|
|
messages that I don't understand why they changed, so the tests pass
|
|
|
|
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.
|
|
checks
|
|
|
|
|
|
- removed the inherent impls compile-fail test, because we’ll be
supporting them
- remove E0308-2 because it’s gonna be supported now (behind a feature
gate)
- replaced the mismatched method receiver error message with something
better, so fixed the tests that that broke
|
|
|
|
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.
|
|
|
|
Fixes #45087.
|
|
|
|
|
|
Fixes #45729
|
|
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.
|
|
new rules for merging expected and supplied types in closure signatures
As uncovered in #38714, we currently have some pretty bogus code for combining the "expected signature" of a closure with the "supplied signature". To set the scene, consider a case like this:
```rust
fn foo<F>(f: F)
where
F: for<'a> FnOnce(&'a u32) -> &'a u32
// ^ *expected* signature comes from this where-clause
{
...
}
fn main() {
foo(|x: &u32| -> &u32 { .. }
// ^^^^^^^^^^^^^^^^^ supplied signature
// comes from here
}
```
In this case, the supplied signature (a) includes all the parts and (b) is the same as the expected signature, modulo the names used for the regions. But often people supply only *some* parts of the signature. For example, one might write `foo(|x| ..)`, leaving *everything* to be inferred, or perhaps `foo(|x: &u32| ...)`, which leaves the return type to be inferred.
In the current code, we use the expected type to supply the types that are not given, but otherwise use the type the user gave, except for one case: if the user writes `fn foo(|x: _| ..)` (i.e., an underscore at the outermost level), then we will take the expected type (rather than instantiating a fresh type variable). This can result in nonsensical situations, particularly with bound regions that link the types of parameters to one another or to the return type. Consider `foo(|x: &u32| ...)` -- if we *literally* splice the expected return type of `&'a u32` together with what the user gave, we wind up with a signature like `for<'a> fn(&u32) -> &'a u32`. This is not even permitted as a type, because bound regions like `'a` must appear also in the arguments somewhere, which is why #38714 leads to an ICE.
This PR institutes some new rules. These are not meant to be the *final* set of rules, but they are a kind of "lower bar" for what kind of code we accept (i.e., we can extend these rules in the future to be smarter in some cases, but -- as we will see -- these rules do accept some things that we then would not be able to back off from).
These rules are derived from a few premises:
- First and foremost, anonymous regions in closure annotation are mostly requests for the code to "figure out the right lifetime" and shouldn't be read too closely. So for example when people write a closure signature like `|x: &u32|`, they are really intended for us to "figure out" the right region for `x`.
- In contrast, the current code treats this supplied type as being more definitive. In particular, writing `|x: &u32|` would always result in the region of `x` being bound in the closure type. In other words, the signature would be something like `for<'a> fn(&'a u32)` -- this is derived from the fact that `fn(&u32)` expands to a type where the region is bound in the fn type.
- This PR takes a different approach. The "binding level" for reference types appearing in closure signatures can be informed in some cases by the expected signature. So, for example, if the expected signature is something like `(&'f u32)`, where the region of the first argument appears free, then for `|x: &u32|`, the new code would infer `x` to also have the free region `'f`.
- This inference has some limits. We don't do this for bindings that appear within the selected types themselves. So e.g. `|x: fn(&u32)|`, when combined with an expected type of `fn(fn(&'f u32))`, would still result in a closure that expects `for<'a> fn(&'a u32)`. Such an annotation will ultimately result in an error, as it happens, since `foo` is supplying a `fn(&'f u32)` to the closure, but the closure signature demands a `for<'a> fn(&'a u32)`. But still we choose to trust it and have the user change it.
- I wanted to preserve the rough intuition that one can copy-and-paste a type out of the fn signature and into the fn body without dramatically changing its meaning. Interestingly, if one has `|x: &u32|`, then regardless of whether the region of `x` is bound or free in the closure signature, it is also free in the region body, and that is also true when one writes `let x: &u32`, so that intuition holds here. But the same would not be true for `fn(&u32)`, hence the different behavior.
- Second, we must take either **all** the references to bound regions from the expected type or **none**. The current code, as we saw, will happily take a bound region in the return type but drop the other place where it is used, in the parameters. Since bound regions are all about linking multiple things together, I think it's important not to do that. (That said, we could conceivably be a bit less strict here, since the subtyping rules will get our back, but we definitely don't want any bound regions that appear only in the return type.)
- Finally, we cannot take the bound region names from the supplied types and "intermix" them with the names from the expected types.
- We *could* potentially do some alpha renaming, but I didn't do that.
- Ultimately, if the types the user supplied do not match expectations in some way that we cannot recover from, we fallback to deriving the closure signature solely from those expected types.
- For example, if the expected type is `u32` but the user wrote `i32`.
- Or, more subtle, if the user wrote e.g. `&'x u32` for some named lifetime `'x`, but the expected type includes a bound lifetime (`for<'a> (&'a u32)`). In that case, preferring the type that the user explicitly wrote would hide an appearance of a bound name from the expected type, and we try to never do that.
The detailed rules that I came up with are found in the code, but for ease of reading I've also [excerpted them into a gist](https://gist.github.com/nikomatsakis/e69252a2b57e6d97d044c2f254c177f1). I am not convinced they are correct and would welcome feedback for alternative approaches.
(As an aside, the way I think I would ultimately *prefer* to think about this is that the conversion from HIR types to internal types could be parameterized by an "expected type" that it uses to guide itself. However, since that would be a pain, I opted *in the code* to first instantiate the supplied types as `Ty<'tcx>` and then "merge" those types with the `Ty<'tcx>` from the expected signature.)
I think we should probably FCP this before landing.
cc @rust-lang/lang
r? @arielb1
|
|
Any auto trait is allowed in trait object bounds.
Fix duplicate check of type and lifetime parameter count.
|
|
RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute
This work-in-progress pull request contains my changes to implement [RFC 2008](https://github.com/rust-lang/rfcs/pull/2008). The related tracking issue is #44109.
As of writing, enum-related functionality is not included and there are some issues related to tuple/unit structs. Enum related tests are currently ignored.
WIP PR requested by @nikomatsakis [in Gitter](https://gitter.im/rust-impl-period/WG-compiler-middle?at=59e90e6297cedeb0482ade3e).
|
|
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
|
|
|
|
|
|
add TerminatorKind::FalseEdges and use it in matches
impl #45184 and fixes #45043 right way.
False edges unexpectedly affects uninitialized variables analysis in MIR borrowck.
|
|
|
|
[Syntax] Implement auto trait syntax
Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`.
See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231.
The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate.
When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet).
Observations:
- If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant.
- The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser.
- Rustfmt and clippy are broken, need to fix those.
- Rustdoc just ignores it for now.
ping @petrochenkov @nikomatsakis
|
|
This moves the well formedness checks to the AST validation pass. Tests
were adjusted.
The auto keyword should be back-compat now.
|
|
|
