Re-enable trivial bounds
cc #50825
Remove implementations from global bounds in winnowing when there is ambiguity.
This results in the reverse of #24066 happening sometimes. I'm not sure if anything can be done about that though.
cc #48214
r? @nikomatsakis
Rollup of 13 pull requests
Successful merges:
- #50143 (Add deprecation lint for duplicated `macro_export`s)
- #51099 (Fix Issue 38777)
- #51276 (Dedup auto traits in trait objects.)
- #51298 (Stabilize unit tests with non-`()` return type)
- #51360 (Suggest parentheses when a struct literal needs them)
- #51391 (Use spans pointing at the inside of a rustdoc attribute)
- #51394 (Use scope tree depths to speed up `nearest_common_ancestor`.)
- #51396 (Make the size of Option<NonZero*> a documented guarantee.)
- #51401 (Warn on `repr` without hints)
- #51412 (Avoid useless Vec clones in pending_obligations().)
- #51427 (compiletest: autoremove duplicate .nll.* files (#51204))
- #51436 (Do not require stage 2 compiler for rustdoc)
- #51437 (rustbuild: generate full list of dependencies for metadata)
Failed merges:
Use spans pointing at the inside of a rustdoc attribute
Follow up to #51111.
Point to the link in a rustdoc attribute where intralink resolution failed, instead of the full rustdoc attribute's span.
r? @GuillaumeGomez cc @kennytm
Suggest parentheses when a struct literal needs them
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
Fix#47360, #50090. Leaving #42982 open to come back to this problem with a better solution.
Dedup auto traits in trait objects.
Fixes#47010
Note that the test file `run-pass/trait-object-auto-dedup.rs` passes before and after this change. It's the `ui` test that changed from compiling to not compiling. Which does make this a breaking change, but I cannot imagine anybody actually being broken by it.
NLL: report type moved from behind borrow of array/slice
When NLL has illegal move due to borrowed content in an array or slice, provide feedback about why the move wasn't a copy.
Drive by: While comparing the resulting `.nll.stderr` files to their old borrowck variants, I noticed that the test for borrowck-vec-pattern-nesting.rs was not signaling some errors under NLL due to the test assuming lexical lifetimes. So I fixed that too.
Fix#51190
Removes extra global bounds at the winnowing stage rather than when
normalizing the param_env. This avoids breaking inference when there is
a global bound.
Deny #[cfg] and #[cfg_attr] on generic parameters.
Fix#51279.
Attributes on generic parameters are not expanded, meaning `#[cfg]`, `#[cfg_attr]` and attribute proc macros are entirely ignored on them.
This PR makes using the first two attributes an error, because if they are correctly expanded will affect the AST and change code behavior.
I'm beta-nominating this, because generic parameter attributes are stabilizing in 1.27, and if we did not reserve their usage, we may never be able to repurpose the meaning of these attributes in the Rust 2015 edition.
Remove two redundant .nll.stderr files
It turns out that the diagnostics generated from NLL for these cases are now exactly the same as that produced by AST borrowck, and thus we can just fallback on those `.stderr` files that already exist for AST-borrowck.
Bravo!
(it is a good idea to remove these files, because it slightly reduces the amount of time humans will spend reviewing the .nll.stderr fileset...)
((it *might* be worthwhile trying to change the `compiletest` code to even issue a warning when two such files have equivalent contents... but I am not going so far as to try to implement that right now...))
Add Future and task system to the standard library
This adds preliminary versions of the `std::future` and `std::task` modules in order to unblock development of async/await (https://github.com/rust-lang/rust/issues/50547). These shouldn't be considered as final forms of these libraries-- design questions about the libraries should be left on https://github.com/rust-lang/rfcs/pull/2418. Once that RFC (or a successor) is merged, these APIs will be adjusted as necessary.
r? @aturon
Accept `..` in incorrect position to avoid further errors
We currently give a specific message when encountering a `..` anywhere
other than the end of a pattern. Modify the parser to accept it (while
still emitting the error) so that we don't also trigger "missing fields
in pattern" errors afterwards.
Add suggestions to either remove trailing `,` or moving the `..` to the
end.
Follow up to #49268.
Refactor the const eval diagnostic API
* no longer report "const eval error" for things that have typeck errors
* errors and lints have saner spans and messages
* unified the diagnostic logic (const eval errors were slightly different depending on where they were reported, and there was also code duplication between the different reporters)
* report errors if an erroneous constant is used inside a promoted (fixes most of #50814)
