Stabilize `..` in tuple (struct) patterns
I'd like to nominate `..` in tuple and tuple struct patterns for stabilization.
This feature is a relatively small extension to existing stable functionality and doesn't have known blockers.
The feature first appeared in Rust 1.10 6 months ago.
An example of use: https://github.com/rust-lang/rust/pull/36203
Closes https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
macros: improve shadowing checks
This PR improves macro-expanded shadowing checks to work with out-of-(pre)order expansion.
Out-of-order expansion became possible in #37084, so this technically a [breaking-change] for nightly.
The regression test from this PR is an example of code that would break.
r? @nrc
Fix ICE when querying DefId on Def::Err.
Also moves computations into check that `kind_id` is `Ok(_)`, which is in theory an optimization, though I expect it's minor.
Fixes#37534.
r? @eddyb.
rustc: Add knowledge of Windows subsystems.
This commit is an implementation of [RFC 1665] which adds support for the
`#![windows_subsystem]` attribute. This attribute allows specifying either the
"windows" or "console" subsystems on Windows to the linker.
[RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md
Previously all Rust executables were compiled as the "console" subsystem which
meant that if you wanted a graphical application it would erroneously pop up a
console whenever opened. When compiling an application, however, this is
undesired behavior and the "windows" subsystem is used instead to have control
over user interactions.
This attribute is validated, but ignored on all non-Windows platforms.
cc #37499
detect extra region requirements in impls
The current "compare method" check fails to check for the "region obligations" that accrue in the fulfillment context. This branch switches that code to create a `FnCtxt` so that it can invoke the regionck code. Previous crater runs (I haven't done one with the latest tip) have found some small number of affected crates, so I went ahead and introduced a warning cycle. I will kick off a crater run with this branch shortly.
This is a [breaking-change] because previously unsound code was accepted. The crater runs also revealed some cases where legitimate code was no longer type-checking, so the branch contains one additional (but orthogonal) change. It improves the elaborator so that we elaborate region requirements more thoroughly. In particular, if we know that `&'a T: 'b`, we now deduce that `T: 'b` and `'a: 'b`.
I invested a certain amount of effort in getting a good error message. The error message looks like this:
```
error[E0276]: impl has stricter requirements than trait
--> traits-elaborate-projection-region.rs:33:5
|
21 | fn foo() where T: 'a;
| --------------------- definition of `foo` from trait
...
33 | fn foo() where U: 'a { }
| ^^^^^^^^^^^^^^^^^^^^^^^^ impl has extra requirement `U: 'a`
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #18937 <https://github.com/rust-lang/rust/issues/18937>
note: lint level defined here
--> traits-elaborate-projection-region.rs:12:9
|
12 | #![deny(extra_requirement_in_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Obviously the warning only prints if this is a _new_ error (that resulted from the bugfix). But all existing errors that fit this description are updated to follow the general template. In order to get the lint to preserve the span-labels and the error code, I separate out the core `Diagnostic` type (which encapsulates the error code, message, span, and children) from the `DiagnosticBuilder` (which layers on a `Handler` that can be used to report errors). I also extended `add_lint` with an alternative `add_lint_diagnostic` that takes in a full diagnostic (cc @jonathandturner for those changes). This doesn't feel ideal but feels like it's moving in the right direction =).
r? @pnkfelix
cc @arielb1
Fixes#18937
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
This commit is an implementation of [RFC 1665] which adds support for the
`#![windows_subsystem]` attribute. This attribute allows specifying either the
"windows" or "console" subsystems on Windows to the linker.
[RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md
Previously all Rust executables were compiled as the "console" subsystem which
meant that if you wanted a graphical application it would erroneously pop up a
console whenever opened. When compiling an application, however, this is
undesired behavior and the "windows" subsystem is used instead to have control
over user interactions.
This attribute is validated, but ignored on all non-Windows platforms.
cc #37499
Add semicolon to "Maybe a missing `extern crate foo`" message
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Fix bad error message with `::<` in types
Fix#36116.
Before:
```rust
error: expected identifier, found `<`
--> src/test/compile-fail/issue-36116.rs:16:52
|
16 | let f = Some(Foo { _a: 42 }).map(|a| a as Foo::<i32>);
| ^
error: chained comparison operators require parentheses
--> src/test/compile-fail/issue-36116.rs:16:52
|
16 | let f = Some(Foo { _a: 42 }).map(|a| a as Foo::<i32>);
| ^^^^^^
|
= help: use `::<...>` instead of `<...>` if you meant to specify type arguments
error: expected expression, found `)`
--> src/test/compile-fail/issue-36116.rs:16:57
|
16 | let f = Some(Foo { _a: 42 }).map(|a| a as Foo::<i32>);
| ^
error: expected identifier, found `<`
--> src/test/compile-fail/issue-36116.rs:20:17
|
20 | let g: Foo::<i32> = Foo { _a: 42 };
| ^
error: aborting due to 5 previous errors
```
After:
```rust
error: unexpected token: `::`
--> src/test/compile-fail/issue-36116.rs:16:50
|
16 | let f = Some(Foo { _a: 42 }).map(|a| a as Foo::<i32>);
| ^^
|
= help: use `<...>` instead of `::<...>` if you meant to specify type arguments
error: unexpected token: `::`
--> src/test/compile-fail/issue-36116.rs:20:15
|
20 | let g: Foo::<i32> = Foo { _a: 42 };
| ^^
|
= help: use `<...>` instead of `::<...>` if you meant to specify type arguments
error: aborting due to 2 previous errors
```
Diagnostics for struct path resolution errors in resolve and typeck are unified.
Self type is treated as a type alias in few places (not reachable yet).
Unsafe cell is seen in constants even through type aliases.
All checks for struct paths in typeck work on type level.
Make sufficiently old or low-impact compatibility lints deny-by-default
Tracking issues are updated/created when necessary.
Needs crater run before proceeding.
r? @nikomatsakis
Implement field shorthands in struct literal expressions.
Implements #37340 in a straight-forward way: `Foo { x, y: f() }` parses as `Foo { x: x, y: f() }`.
Because of the added `is_shorthand` to `ast::Field`, this is `[syntax-breaking]` (cc @Manishearth).
* [x] Mark the fields as being a shorthand (the exact same way we do it in patterns), for pretty-printing.
* [x] Gate the shorthand syntax with `#![feature(field_init_shorthand)]`.
* [x] Don't parse numeric field as identifiers.
* [x] Arbitrary field order tests.
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Add identifier to unused import warnings
Fix#37376.
For some reason, though, I'm getting warnings with messages like "76:9: 76:16: unused import: `self::g`" instead of "unused import: `self::g`". @pnkfelix Any ideas what might be causing this?
Convert byte literal pattern to byte array patterns when they are both
used together. so matching them is properly handled. I could've done the
conversion eagerly, but that could have caused a bad worst-case for
massive byte-array matches.
Fixes#18027.
Fixes#25051.
Fixes#26510.
check target abi support
This PR checks for each extern function / block whether the ABI / calling convention used is supported by the current target.
This was achieved by adding an `abi_blacklist` field to the target specifications, listing the calling conventions unsupported for that target.
