introduce type-op for user-type ascription in NLL
Handle user-type ascription in a type operator, which gives us a lot more flexibility around the order in which we resolve things.
r? @pnkfelix
Fixes#55219Fixes#55241
Add `extern crate` items to extern prelude
With this patch each `extern crate orig_name as name` item adds name `name` into the extern prelude, as if it was passed with `--extern`.
What changes this causes in practice?
Almost none! After all, `--extern` passed from Cargo was supposed to replace `extern crate` items in source, so if some code has `extern crate` item (or had it on 2015 edition), then it most likely uses `--extern` as well...
... with exception of a few important cases.
- Crates using `proc_macro`. `proc_macro` is not passed with `--extern` right now and is therefore not in extern prelude.
Together with 2018 edition import behavior this causes problems like https://github.com/rust-lang/rust/issues/54418, e.g.
```rust
extern crate proc_macro;
use proc_macro::TokenStream;
```
doesn't work.
It starts working after this patch.
- `#[no_std]` crates using `std` conditionally, like @aturon described in https://github.com/rust-lang/rust/issues/53166#issuecomment-425219286, and still wanting to write `std` instead of `crate::std`. This PR covers that case as well.
This allows us to revert placing `std` into the extern prelude unconditionally, which was, I think, a [bad idea](https://github.com/rust-lang/rust/issues/53166#issuecomment-425117829).
- Later `extern crate` syntax can be extended to support adding an alias to some local path to extern prelude, as it may be required for resolving https://github.com/rust-lang/rust/issues/54647.
Notes:
- Only `extern crate` items from the root module added to the prelude, mostly because this behavior for items from inner modules would look very strange, rather than for technical reasons.
This means you can opt out from the prelude additions with something like
```rust
mod inner {
pub(crate) extern crate foo;
}
use inner::foo;
```
- I haven't updated logic for 2018 import canaries to work fully correctly with this. The cases where it matters are pretty exotic (the `extern crate` item must be "sufficiently macro expanded") and I'd rather spend the time on eliminating the canaries entirely.
Add regression tests for #55219 and #55241
Also another test where a duplicate-like error appears to have been
suppressed; I'm not 100% sure why this output changes, though I could
imagine that some duplicate suppression is enabled by this PR.
enforce user annotations in closure signatures
Not *quite* ready yet but I'm opening anyway. Still have to finish running tests locally.
Fixes#54692Fixes#54124
r? @matthewjasper
This fixes `issue-28848.rs` -- it also handles another case that the
AST region checker gets wrong (`wf-self-type.rs`). I don't actually
think that this is the *right way* to be enforcing this constraint --
I think we should probably do it more generally, perhaps by editing
`predicates_of` for the impl itself. The chalk-style implied bounds
setup ought to fix this.
#45829 when a renamed import conflict with a previous import
Fix the suggestion when a renamed import conflict.
It check if the snipped contains `" as "`, and if so uses everything before for the suggestion.
Use a keyword in raw identifier example
That's a very small documentation fix. The text says "you can now use keywords as identifiers" but example didn't use a keyword and would work without raw identifiers.
[NLL] Use new region infer errors when explaining borrows
Use the new free region infer errors for explaining borrows
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure to a captured variable. (E0521)
Closes#51026 - `regions-nested-fns-2.rs` isn't changed to that diagnostic, since that would not be the correct error here.
Closes#51169
cc #53882 - The error is (IMO) better now, but it could be better when we trace lifetimes in these error messages.
r? @nikomatsakis cc @pnkfelix
