Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute
There are so many questions around promoting const fn calls... it seems saner to try to limit automatic promotion to const fns which were explicitly opted in for promotion.
I added the attribute to all public stable const fns that were already promotable (e.g. not Cell::new) in order to not cause any breakage
r? @eddyb
cc @nikomatsakis
handle outlives predicates in trait evaluation
This handles higher-ranked outlives predicates in trait evaluation the same way they are handled in projection.
Fixes#54302. I think this is a more correct fix than #54401 because it fixes the root case in evaluation instead of making evaluation used in less cases. However, we might want to go to a direction closer to @nikomatsakis's solution with Chalk.
r? @nikomatsakis
suggest `crate::...` for "local" paths in 2018
Fixes#54230.
This commit adds suggestions for unresolved imports in the cases where
there could be a missing `crate::`, `super::`, `self::` or a missing
external crate name before an import.
r? @nikomatsakis
resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module"
Currently if macro name may refer to both a `macro_rules` macro definition and a macro defined/imported into module we conservatively report an ambiguity error.
Unfortunately, these errors became a source of regressions when macro modularization was enabled - see issue https://github.com/rust-lang/rust/issues/54472.
This PR disambiguates such conflicts in favor of `macro_rules` if both the `macro_rules` item and in-module macro name are defined in the same normal (named) module and `macro_rules` is closer in scope to the point of use (see the tests for examples).
This is a subset of more general approach described in https://github.com/rust-lang/rust/issues/54472#issuecomment-424666659.
The subset is enough to fix all the regressions from https://github.com/rust-lang/rust/issues/54472, but it can be extended to apply to all "macro_rules" vs "macro name in module" conflicts in the future.
To give an analogy, this is equivalent to scoping rules for `let` variables and items defined in blocks (`macro_rules` behaves like "`let` at module level" in general).
```rust
{ // beginning of the block
use xxx::m; // (1)
// Starting from the beginning of the block and until here m!() refers to (1)
macro_rules! m { ... } // (2)
// Starting from here and until the end of the block m!() refers to (2)
} // end of the block
```
More complex examples with `use` and `macro_rules` from different modules still report ambiguity errors, even if equivalent examples with `let` are legal.
Fixes https://github.com/rust-lang/rust/issues/54472 (stable-to-beta regression)
This commit adds suggestions for unresolved imports in the cases where
there could be a missing `crate::`, `super::`, `self::` or a missing
external crate name before an import.
NLL fails to suggest "try removing `&mut` here"
Fixes#51191.
This PR adds ``try removing `&mut` here`` suggestions to functions where a mutable borrow is being taken of a `&mut self` or a `self: &mut Self`. This PR also enables the suggestion for adding a `mut` pattern to by-value implicit self arguments without `mut` patterns already.
r? @nikomatsakis
Renumber `proc_macro` tracking issues
Lots of issue links in the compiler still point to https://github.com/rust-lang/rust/issues/38356 which is a bit of a monster issue that isn't serving much purpose any more. I've split the issue into a number of more fine-grained tracking issues to track stabilizations.
do not promote comparing function pointers
This *could* break existing code that relied on fn ptr comparison getting promoted to `'static` lifetime.
Fixes https://github.com/rust-lang/rust/issues/54696
Use impl_header_lifetime_elision in libcore
The feature is approved for stabilization, so let's use it to remove about 300 `'a`s.
Tracking issue for the feature: https://github.com/rust-lang/rust/issues/15872
make run-pass tests with empty main just compile-pass tests
Many run-pass tests have an empty main, so there is not actually any point in running them. This makes them `compile-pass` tests instead, saving some time (generating the binary and then running it).
For now I did this only for `run-pass/issues`; if there is interest I can also do it for the other directories. I used `^\s*fn\s+main\(\s*\)\s*\{\s*\}` as regexp to identify these files.
Add `crate::` to trait suggestions in Rust 2018.
Fixes#54559.
In the 2018 edition, when suggesting traits to import that implement a
given method that is being invoked, suggestions will now include the
`crate::` prefix if the suggested trait is local to the current crate.
r? @nikomatsakis
Allow both explicit and elided lifetimes in the same impl header
While still prohibiting explicit and in-band in the same header.
Fixes#54456
As usual, I don't know the broader context of the code I'm changing, so please let me know whatever I can do better.
Pre-existing test that mixing explicit and in-band remains an error: https://github.com/rust-lang/rust/blob/master/src/test/ui/in-band-lifetimes/E0688.rs
#53840: Consolidate pattern check errors
#53840 on this PR we are aggregating `cannot bind by-move and by-ref in the same pattern` message present on the different lines into one diagnostic message. Here we are first gathering those `spans` on `vector` then we are throwing them with the help of `MultiSpan`
r? @estebank
Addresses: #53480
we are consolidating `cannot bind by-move and by-ref in the same
pattern` message present on the different lines into single diagnostic
message.
To do this, we are first gathering those spans into the vector
after that we are throwing them with the help of MultiSpan in
a separate block.
Addresses: #53840
In the 2018 edition, when suggesting traits to import that implement a
given method that is being invoked, suggestions will now include the
`crate::` prefix if the suggested trait is local to the current crate.
This commit improves mutability error suggestions by suggesting the
removal of `&mut` where a mutable borrow is being taken of a `&mut self`
or a `self: &mut Self`.
This commit adds an `ImplicitSelfKind` to the HIR and the MIR that keeps
track of whether a implicit self argument is immutable by-value, mutable
by-value, immutable reference or mutable reference so that the addition
of the `mut` keyword can be suggested for the immutable by-value case.
do not normalize all non-scalar constants to a ConstValue::ScalarPair
We still need `ConstValue::ScalarPair` for match handling (matching slices and strings), but that will never see anything `Undef`. For non-fat-ptr `ScalarPair`, just point to the allocation like larger data structures do.
Fixes https://github.com/rust-lang/rust/issues/54387
r? @eddyb
Remove `-Z disable_ast_check_for_mutation_in_guard`
One should use `#![feature(bind_by_move_pattern_guards)]` over `-Z disable_ast_check_for_mutation_in_guard`
cc #15287
Don't lint non-extern-prelude extern crate's in Rust 2018.
Fixes#54381 by silencing the lint telling users to remove `extern crate` when `use` doesn't work.
r? @alexcrichton cc @petrochenkov @nikomatsakis @Centril
Add a per-tree error cache to the obligation forest
This implements part of what @nikomatsakis mentioned in https://github.com/rust-lang/rust/pull/30533#issuecomment-170705871:
> 1. If you find that a new obligation is a duplicate of one already in the tree, the proper processing is:
> * if that other location is your parent, you should abort with a cycle error (or accept it, if coinductive)
> * if that other location is not an ancestor, you can safely ignore the new obligation
In particular it implements the "if that other location is your parent accept it, if coinductive" part. This fixes#40827.
I have to say that I'm not 100% confident that this is rock solid. This is my first pull request 🎉, and I didn't know anything about the trait resolver before this. In particular I'm not totally sure that comparing predicates is enough (for instance, do we need to compare `param_env` as well?). Also, I'm not sure what @nikomatsakis mentions [here](https://github.com/rust-lang/rust/issues/30977#issue-127091096), but it might be something that affects this PR:
> In particular, I am wary of getting things wrong around inference variables! We can always add things to the set in their current state, and if unifications occur then the obligation is just kind of out-of-date, but I want to be sure we don't accidentally fail to notice that something is our ancestor. I decided this was subtle enough to merit its own PR.
Anyway, go ahead and review 🙂.
Ref #30977.
# Performance
We are now copying vectors around, so I decided to do some benchmarking. A simple benchmark shows that this does not seem to affect performance in a measurable way:
I ran `cargo clean && cargo build` 20 times on actix-web (84b27db) and these are the results:
```text
rustc master:
Mean Std.Dev. Min Median Max
real 66.637 2.996 57.220 67.714 69.314
user 307.293 14.741 258.093 312.209 320.702
sys 12.524 0.653 10.499 12.726 13.193
rustc fix-bug-overflow-send:
Mean Std.Dev. Min Median Max
real 66.297 4.310 53.532 67.516 70.348
user 306.812 22.371 236.917 314.748 326.229
sys 12.757 0.952 9.671 13.125 13.544
```
I will do a more comprehensive benchmark (compiling rustc stage1) and post the results.
r? @nikomatsakis, @nnethercote
PS: It is better to review this commit-by-commit.
Enable NLL compare mode for more tests
Most of these tests were disabled due to NLL bugs that have since been fixed. A few needed updating for NLL.
r? @nikomatsakis
use closure def-id in returns, but base def-id in locals
The refactorings to handle `let x: impl Trait` wound up breaking `impl Trait` in closure return types. I think there are some deeper problems with the code in question, but this a least should make @eddyb's example work.
Fixes#54593
r? @eddyb
