| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilise irrefutable if-let and while-let patterns
This stabilises RFC 2086 (https://github.com/rust-lang/rust/issues/44495).
This replaces https://github.com/rust-lang/rust/pull/55639, as we want to stabilise this in time for the beta cut-off.
Closes https://github.com/rust-lang/rust/pull/55639.
r? @Centril
|
|
Stabilize `let` bindings and destructuring in constants and const fn
r? @Centril
This PR stabilizes the following features in constants and `const` functions:
* irrefutable destructuring patterns (e.g. `const fn foo((x, y): (u8, u8)) { ... }`)
* `let` bindings (e.g. `let x = 1;`)
* mutable `let` bindings (e.g. `let mut x = 1;`)
* assignment (e.g. `x = y`) and assignment operator (e.g. `x += y`) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like `x[3] = 42`)
* expression statements (e.g. `3;`)
This PR does explicitly *not* stabilize:
* mutable references (i.e. `&mut T`)
* dereferencing mutable references
* refutable patterns (e.g. `Some(x)`)
* operations on `UnsafeCell` types (as that would need raw pointers and mutable references and such, not because it is explicitly forbidden. We can't explicitly forbid it as such values are OK as long as they aren't mutated.)
* We are not stabilizing `let` bindings in constants that use `&&` and `||` short circuiting operations. These are treated as `&` and `|` inside `const` and `static` items right now. If we stopped treating them as `&` and `|` after stabilizing `let` bindings, we'd break code like `let mut x = false; false && { x = true; false };`. So to use `let` bindings in constants you need to change `&&` and `||` to `&` and `|` respectively.
|
|
|
|
This stabilises RFC 2086 (https://github.com/rust-lang/rust/issues/44495).
Co-Authored-By: Sebastian Malton <sebastian@malton.name>
|
|
use the correct supertrait substitution in `object_ty_for_trait`
beta-nominating because regression.
Fixes #57156.
|
|
|
|
|
|
Make sure feature gate errors are recoverable (take 2)
Continuation of https://github.com/rust-lang/rust/pull/56999/commits/15cefe4b2a65bb2a4febcd353cb37b90dfafa4f1.
Turns out I missed the most important part - the main feature gate checking pass.
|
|
|
|
use structured suggestion for method calls
Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.
I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice.
The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas?
r? @estebank
|
|
Modify mismatched type error for functions with no return
Fix #50009.
```
error[E0308]: mismatched types
--> $DIR/coercion-missing-tail-expected-type.rs:3:24
|
LL | fn plus_one(x: i32) -> i32 { //~ ERROR mismatched types
| -------- ^^^ expected i32, found ()
| |
| this function's body doesn't return
LL | x + 1;
| - help: consider removing this semicolon
|
= note: expected type `i32`
found type `()`
```
instead of
```
error[E0308]: mismatched types
--> $DIR/coercion-missing-tail-expected-type.rs:3:28
|
LL | fn plus_one(x: i32) -> i32 { //~ ERROR mismatched types
| ____________________________^
LL | | x + 1;
| | - help: consider removing this semicolon
LL | | }
| |_^ expected i32, found ()
|
= note: expected type `i32`
found type `()`
```
|
|
Fixes #57156.
|
|
Fix broken links to second edition TRPL.
Fixes https://github.com/rust-lang/rust/issues/57104.
Remove `second-edition/` from TRPL hyperlinks.
|
|
Fix #56806 by using `delay_span_bug` in object safety layout sanity checks
It's possible that `is_object_safe` is called on a trait method that with an invalid receiver type. This caused an ICE in #56806, because `receiver_is_dispatchable` returns `true` for `self: Box<dyn Trait>`, which causes one of the layout sanity checks in object_safety.rs to fail. Replacing `bug!` with `delay_span_bug` solves this.
The fact that `receiver_is_dispatchable` returns `true` here could be considered a bug. It passes the check that the method implements, though: `Box<dyn Trait>` implements `DispatchFromDyn<Box<dyn Trait>>` because `dyn Trait` implements `Unsize<dyn Trait>`. It would be good to hear what @eddyb and @nikomatsakis think.
Note that I only added a test for the case encountered in #56806. I could not come up with a case that triggered an ICE from the other check, `bug!("receiver when Self = dyn Trait should be ScalarPair, found Scalar")`. There is no way, to my knowledge, that you can make `receiver_is_dispatchable` return true but still have a `Scalar` ABI when `Self = dyn Trait`.
One other case I encountered while debugging #56806 was that if you have a type parameter `T` that implements `Deref<Target=Self>` and `DispatchFromDyn<T>`, and use it as a method receiver, it will cause an ICE during `is_object_safe` because `T` has no layout ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d9b7497b3be0ca8382fa7d9497263214)):
```rust
trait Trait<T: Deref<Target=Self> + DispatchFromDyn<T>> {
fn foo(self: T) -> dyn Trait<T>;
}
```
I don't intend to remove the ICE there because it is a pathological case, especially since there is no way to implement `DispatchFromDyn<T>` for `T` — the checks in typeck/coherence/builtin.rs do not allow that.
fixes #56806
r? @varkor
|
|
Add support for trait-objects without a principal
The hard-error version of #56481 - should be merged after we do something about the `traitobject` crate.
Fixes #33140.
Fixes #57057.
r? @nikomatsakis
|
|
It's possible that `is_object_safe` is called on a trait that is ill-formed, and we shouldn't ICE unless there are no errors being raised. Using `delay_span_bug` solves this.
fixes #56806
|
|
Fixes #57162.
|
|
make `panictry!` private to libsyntax
This commit completely removes usage of the `panictry!` macro from
outside libsyntax. The macro causes parse errors to be fatal, so using
it in libsyntax_ext caused parse failures *within* a syntax extension to
be fatal, which is probably not intended.
Furthermore, this commit adds spans to diagnostics emitted by empty
extensions if they were missing, à la #56491.
|
|
This makes sure they are printed in a compiler-version-independent
order, avoiding ui test instability.
|
|
|
|
Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.
|
|
Still not great, but good enough to land this PR.
|
|
In particular, when we want to indicate that there is a connection
between the self type and the other types.
|
|
|
|
|
|
|
|
This commit completely removes usage of the `panictry!` macro from
outside libsyntax. The macro causes parse errors to be fatal, so using
it in libsyntax_ext caused parse failures *within* a syntax extension to
be fatal, which is probably not intended.
Furthermore, this commit adds spans to diagnostics emitted by empty
extensions if they were missing, à la #56491.
|
|
Improve type mismatch error messages
Closes #56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
|
|
Suggest using raw identifiers in 2018 edition when using keywords
|
|
Fixes https://github.com/rust-lang/rust/issues/57104.
|
|
Replace "integral variable" with "integer" and replace
"floating-point variable" with "floating-point number" to make the
message less confusing.
|
|
privacy: Use common `DefId` visiting infrastructure for all privacy visitors
One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them.
This is the case because visibilities and reachabilities are attached to `DefId`s.
Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard".
This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since https://github.com/rust-lang/rust/pull/32674#discussion_r58291608 - factoring out the common visiting logic!
Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`).
A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in https://github.com/rust-lang/rust/pull/46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes https://github.com/rust-lang/rust/pull/56837#discussion_r241962239 in particular.
Also this will help with implementing https://github.com/rust-lang/rust/issues/48054.
|
|
|
|
use structured suggestions for nonexistent fields
r? @estebank
|
|
|
|
|
|
- Suggest raw ident escaping in all editions
- Keep primary label in all cases
|
|
Do not complain about missing crate named as a keyword
Fix #57198.
|
|
|
|
Add specific diagnostic when attempting to transmute between equal generic types
Also clarifies the wording of E0512.
Fixes https://github.com/rust-lang/rust/issues/49793.
|
|
|
|
Do not point at the entire block span on fn return type mismatches
caused by missing return.
|
|
Improve error recovery for some built-in macros
Fixes https://github.com/rust-lang/rust/issues/55897
|
|
|
|
Add a note describing the type of the non-Copy moved variable
Closes #56654
r?@davidtwco
|
|
|
|
Implement RFC 2338, "Type alias enum variants"
This PR implements [RFC 2338](https://github.com/rust-lang/rfcs/pull/2338), allowing one to write code like the following.
```rust
#![feature(type_alias_enum_variants)]
enum Foo {
Bar(i32),
Baz { i: i32 },
}
type Alias = Foo;
fn main() {
let t = Alias::Bar(0);
let t = Alias::Baz { i: 0 };
match t {
Alias::Bar(_i) => {}
Alias::Baz { i: _i } => {}
}
}
```
Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern.
Fixes issues #56199 and #56611.
N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](https://github.com/rust-lang/rust/issues/49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.
```rust
Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error
```
I do not know if this will need an FCP, but let's start one if so.
|
|
|
|
|
|
AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end
This way we can avoid aborting compilation if expansion produces errors and generate `ExprKind::Err`s instead.
|
