This is gated on edition 2018 & the `async_await` feature gate.
The parser will accept `async fn` and `async unsafe fn` as fn
items. Along the same lines as `const fn`, only `async unsafe fn`
is permitted, not `unsafe async fn`.The parser will not accept
`async` functions as trait methods.
To do a little code clean up, four fields of the function type
struct have been merged into the new `FnHeader` struct: constness,
asyncness, unsafety, and ABI.
Also, a small bug in HIR printing is fixed: it previously printed
`const unsafe fn` as `unsafe const fn`, which is grammatically
incorrect.
[MIR] Change "scopes" from "visibility scopes" to "source scopes".
These scopes are already used for source-oriented diagnostics, lint levels and unsafety checks.
This PR generalizes the naming around scopes, making the type `SourceScope`, and flips (across several commits) the relationship/priority between `LocalDecl`'s "visibility" and "syntactic" scopes.
r? @nikomatsakis
(This is just the data structure changes and some boilerplate match
code that followed from it; the actual emission of these statements
comes in a follow-up commit.)
CheckLoopVisitor: also visit closure arguments
This turns the ICE #50581 in this code:
```rust
fn main() {
|_: [u8; break]| ();
}
```
from
```
'assertion failed: self.tcx.sess.err_count() > 0', librustc_typeck/check/mod.rs
```
to
```
librustc_mir/hair/cx/expr.rs:543: invalid loop id for break: not inside loop scope
```
which is an ICE as well but at a later stage during compilation and most importantly
fixes of bug #50576 will fix this as well.
As this "only" moves an ICE to a later stage, I didn't add any tests.
Now I have manually verified the default impls of the visitor trait to check whether we have missed any other opportunity to visit more stuff and coudln't find anything (except the missing `break` visit I've fixed in #50829 but that one was already r+'d so I didn't want to push more commits).
This turns an ICE on this code:
fn main() {
|_: [u8; break]| ();
}
from
'assertion failed: self.tcx.sess.err_count() > 0', librustc_typeck/check/mod.rs
to
librustc_mir/hair/cx/expr.rs:543: invalid loop id for break: not inside loop scope
which is at a later stage during compilation and most importantly
fixes of bug #50576 will fix this as well.
tidy: Add a check for empty UI test files
Check for empty `.stderr` and `.stdout` files in UI test directories.
Empty files could still pass testing for `compile-pass` tests with no output
so they can get into the repo accidentally, but they are not necessary and can
be removed.
This is very much an in progress pull request. I'm having an issue with rustfmt. It wanted to reformat the entire file for almost every file by default. And when I run tidy it just errors out because it catches the empty files that are already in the repo.
My next step is goin got be to remove those empty file and see if running tidy again will actually reformat things outside of the context of `cargo fmt`
Fixes https://github.com/rust-lang/rust/issues/50785
When we want to implement label-break-value,
we can't really decide whether to emit ScopeTarget::Loop or
ScopeTarget::Block in the code that is supposed to create it.
So we get rid of it and reconstruct the information when
needed.
Avoid many `cmt` allocations.
`cmt` is a ref-counted wrapper around `cmt_` The use of refcounting
keeps `cmt` handling simple, but a lot of `cmt` instances are very
short-lived, and heap-allocating the short-lived ones takes up time.
This patch changes things in the following ways.
- Most of the functions that produced `cmt` instances now produce `cmt_`
instances. The `Rc::new` calls that occurred within those functions
now occur at their call sites (but only when necessary, which isn't
that often).
- Many of the functions that took `cmt` arguments now take `&cmt_`
arguments. This includes all the methods in the `Delegate` trait.
As a result, the vast majority of the heap allocations are avoided. In
an extreme case, the number of calls to malloc in tuple-stress drops
from 9.9M to 7.9M, a drop of 20%. And the compile times for many runs of
coercions, deep-vector, and tuple-stress drop by 1--2%.
`cmt` is a ref-counted wrapper around `cmt_` The use of refcounting
keeps `cmt` handling simple, but a lot of `cmt` instances are very
short-lived, and heap-allocating the short-lived ones takes up time.
This patch changes things in the following ways.
- Most of the functions that produced `cmt` instances now produce `cmt_`
instances. The `Rc::new` calls that occurred within those functions
now occur at their call sites (but only when necessary, which isn't
that often).
- Many of the functions that took `cmt` arguments now take `&cmt_`
arguments. This includes all the methods in the `Delegate` trait.
As a result, the vast majority of the heap allocations are avoided. In
an extreme case, the number of calls to malloc in tuple-stress drops
from 9.9M to 7.9M, a drop of 20%. And the compile times for many runs of
coercions, deep-vector, and tuple-stress drop by 1--2%.
Better error message when trying to write default impls
Previously, if you tried to write this (using the specialization
feature flag):
default impl PartialEq<MyType> {
...
}
The compiler would give you the mysterious warning "inherent impls
cannot be default". What it really means is that you're trying to
write an impl for a Structure or *Trait Object*, and that cannot
be "default". However, one of the ways to encounter this error
(as shown by the above example) is when you forget to write "for
MyType".
This PR adds a help message that reads "maybe missing a `for`
keyword?" This is useful, actionable advice that will help any user
identify their mistake, and doesn't get in the way or mislead any
user that really meant to use the "default" keyword for this weird
purpose. In particular, this help message will be useful for any
users who don't know the "inherent impl" terminology, and/or users
who forget that inherent impls CAN be written for traits (they apply
to the trait objects). Both of these are somewhat confusing, seldom-
used concepts; a one-line error message without any error number for
longer explanation is NOT the place to introduce these ideas.
I wasn't quite sure what grammar / wording to use. I'm open to suggestions. CC @rust-lang/docs (I hope I'm doing that notation right)
(Apparently not. :( )
