bors [Sat, 20 Feb 2021 21:38:53 +0000 (21:38 +0000)]
Auto merge of #82341 - GuillaumeGomez:rollup-t7y7tyg, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #80595 (`impl PartialEq<Punct> for char`; symmetry for #78636)
- #81991 (Fix panic in 'remove semicolon' when types are not local)
- #82176 (fix MIR fn-ptr pretty-printing)
- #82244 (Keep consistency in example for Stdin StdinLock)
- #82260 (rustc: Show ``@path`` usage in stable)
- #82316 (Fix minor mistake in LTO docs.)
- #82332 (Don't generate src link on dummy spans)
Guillaume Gomez [Sat, 20 Feb 2021 19:37:00 +0000 (20:37 +0100)]
Rollup merge of #82176 - RalfJung:mir-fn-ptr-pretty, r=oli-obk
fix MIR fn-ptr pretty-printing
An uninitialized function pointer would get printed as `{{uninit fn()}` (notice the unbalanced parentheses), and a dangling fn ptr would ICE. This fixes both of that.
However, I have no idea how to add tests for this.
Also, I don't understand this MIR pretty-printing code. Somehow the print function `pretty_print_const_scalar` actually *returns* a transformed form of the const (but there is no doc comment explaining what is being returned); some match arms do `p!` while others do `self =`, and there's a wild mixture of `p!` and `write!`... all very mysterious and confusing.^^
Guillaume Gomez [Sat, 20 Feb 2021 19:36:57 +0000 (20:36 +0100)]
Rollup merge of #81991 - osa1:issue81839, r=estebank
Fix panic in 'remove semicolon' when types are not local
It's not possible to check if removing a semicolon fixes the type error
when checking match arms and one or both of the last arm's and the
current arm's return types are imported "opaque" types. In these cases
we don't generate a "consider removing semicolon" suggestions.
Fixes #81839
---
I'm not sure how to add a test for this. I think the test would need at least two crates. Do we have any existing tests that do this so that I can take a look?
bors [Sat, 20 Feb 2021 18:58:05 +0000 (18:58 +0000)]
Auto merge of #70951 - cjgillot:anarchy, r=oli-obk
Move the query engine out of rustc_middle
The handling of queries is moved to a trait `QueryEngine`.
It replaces `query::Queries` in the `TyCtxt`, allowing to move the query engine out of librustc_middle.
There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch,
or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`.
For now, I put it in librustc_incremental, which is very small.
This may not be the best place.
A significant part of the codegen time for librustc_middle is moved to the recipient crate.
bors [Fri, 19 Feb 2021 16:39:03 +0000 (16:39 +0000)]
Auto merge of #82020 - jyn514:mut-passes, r=camelid,GuillaumeGomez
Make `Clean` take &mut DocContext
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
This combined with https://github.com/rust-lang/rust/pull/82018 should hopefully help with https://github.com/rust-lang/rust/pull/82014 by allowing `cx.cache.exported_traits` to be modified in `register_res`. Previously it had to use interior mutability, which required either adding a RefCell to `cache.exported_traits` on *top* of the existing `RefCell<Cache>` or mixing reads and writes between `cx.exported_traits` and `cx.cache.exported_traits`. I don't currently have that working but I expect it to be reasonably easy to add after this.
bors [Fri, 19 Feb 2021 08:24:01 +0000 (08:24 +0000)]
Auto merge of #82281 - Dylan-DPC:rollup-raob2tu, r=Dylan-DPC
Rollup of 10 pull requests
Successful merges:
- #79747 (Add explanations and suggestions to `irrefutable_let_patterns` lint)
- #81496 (name async generators something more human friendly in type error diagnostic)
- #81873 (Add Mutex::unlock)
- #82093 (Add tests for Atomic*::fetch_{min,max})
- #82238 (ast: Keep expansion status for out-of-line module items)
- #82245 (Do not ICE when evaluating locals' types of invalid `yield`)
- #82259 (Fix popping singleton paths in when generating E0433)
- #82261 (rustdoc: Support argument files)
- #82274 (libtest: Fix unwrap panic on duplicate TestDesc)
- #82275 (Update cargo)
Dylan DPC [Fri, 19 Feb 2021 01:49:13 +0000 (02:49 +0100)]
Rollup merge of #82274 - andersk:test-unwrap, r=Mark-Simulacrum
libtest: Fix unwrap panic on duplicate TestDesc
It is possible for different tests to collide to the same `TestDesc` when macros are involved. That is a bug, but it didn’t cause a panic until #81367. For now, change the code to ignore this problem.
Dylan DPC [Fri, 19 Feb 2021 01:49:12 +0000 (02:49 +0100)]
Rollup merge of #82261 - ojeda:rustdoc-argfile, r=jyn514
rustdoc: Support argument files
Factors out the `rustc_driver` logic that handles argument files so that rustdoc supports them as well, e.g.:
rustdoc `@argfile`
This is needed to be able to generate docs for projects that already use argument files when compiling them, e.g. projects that pass a huge number of `--cfg` arguments.
Dylan DPC [Fri, 19 Feb 2021 01:49:08 +0000 (02:49 +0100)]
Rollup merge of #82238 - petrochenkov:nocratemod, r=Aaron1011
ast: Keep expansion status for out-of-line module items
I.e. whether a module `mod foo;` is already loaded from a file or not.
This is a pre-requisite to correctly treating inner attributes on such modules (https://github.com/rust-lang/rust/issues/81661).
With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`.
Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level.
Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`).
`ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.
Dylan DPC [Fri, 19 Feb 2021 01:49:07 +0000 (02:49 +0100)]
Rollup merge of #82093 - bjorn3:more_atomic_tests, r=kennytm
Add tests for Atomic*::fetch_{min,max}
This ensures that all atomic operations except for fences are tested. This has been useful to test my work on using atomic instructions for atomic operations in cg_clif instead of a global lock.
Dylan DPC [Fri, 19 Feb 2021 01:49:00 +0000 (02:49 +0100)]
Rollup merge of #81496 - guswynn:expected_async_block, r=oli-obk
name async generators something more human friendly in type error diagnostic
fixes #81457
Some details:
1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr
2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred
3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used)
4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
Miguel Ojeda [Thu, 18 Feb 2021 15:15:24 +0000 (16:15 +0100)]
rustdoc: Support argument files
Factors out the `rustc_driver` logic that handles argument files
so that rustdoc supports them as well, e.g.:
rustdoc @argfile
This is needed to be able to generate docs for projects that
already use argument files when compiling them, e.g. projects
that pass a huge number of `--cfg` arguments.
Anders Kaseorg [Thu, 18 Feb 2021 20:41:08 +0000 (12:41 -0800)]
libtest: Fix unwrap panic on duplicate TestDesc.
It is possible for different tests to collide to the same TestDesc
when macros are involved. That is a bug, but it didn’t cause a panic
until #81367. For now, change the code to ignore this problem.
bors [Thu, 18 Feb 2021 19:45:42 +0000 (19:45 +0000)]
Auto merge of #82263 - Dylan-DPC:rollup-cypm2uw, r=Dylan-DPC
Rollup of 10 pull requests
Successful merges:
- #81546 ([libtest] Run the test synchronously when hitting thread limit)
- #82066 (Ensure valid TraitRefs are created for GATs)
- #82112 (const_generics: Dont evaluate array length const when handling yet another error )
- #82194 (In some limited cases, suggest `where` bounds for non-type params)
- #82215 (Replace if-let and while-let with `if let` and `while let`)
- #82218 (Make sure pdbs are copied along with exe and dlls when bootstrapping)
- #82236 (avoid converting types into themselves (clippy::useless_conversion))
- #82246 (Add long explanation for E0549)
- #82248 (Optimize counting digits in line numbers during error reporting)
- #82256 (Print -Ztime-passes (and misc stats/logs) on stderr, not stdout.)
Dylan DPC [Thu, 18 Feb 2021 15:57:43 +0000 (16:57 +0100)]
Rollup merge of #82256 - eddyb:time-passes-stderr, r=varkor
Print -Ztime-passes (and misc stats/logs) on stderr, not stdout.
I've tried not to change anything that looked similar to `rustc --print`, where people might use automation, and/or any "bulk" prints, such as dumping an entire Graphviz (`dot`) graph on stdout.
The reason I want `-Ztime-passes` to be on stderr like debug logging is I can get a complete (and correctly interleaved) view just by looking at stderr, which is merely a convenience when running `rustc`/Cargo directly, but even more important when it's nested in a build script, as Cargo will split the build script output into stdout (named `output`) and `stderr`.
Dylan DPC [Thu, 18 Feb 2021 15:57:42 +0000 (16:57 +0100)]
Rollup merge of #82248 - nhwn:optimize-counting-digits, r=varkor
Optimize counting digits in line numbers during error reporting
Replaces `.to_string().len()` with simple loop and integer division, which avoids an unnecessary allocation.
Although I couldn't figure out how to directly profile `rustc`'s error reporting, I ran a microbenchmark on my machine (2.9 GHz Dual-Core Intel Core i5) on the two strategies for `0..100_000`, and the results seem promising:
```
test to_string_len ... bench: 12,124,792 ns/iter (+/- 700,652)
test while_loop ... bench: 30,333 ns/iter (+/- 562)
```
The x86_64 disassembly reduces integer division to a multiplication + shift, so I don't think there's any problems with using integer division.
For more (micro)optimization, it would be nice if we could avoid the initial check to see if the line number is nonzero, but I don't think `self.get_max_line_num(span, children)` _guarantees_ a nonzero line number.
Dylan DPC [Thu, 18 Feb 2021 15:57:33 +0000 (16:57 +0100)]
Rollup merge of #81546 - hyd-dev:libtest-run-out-of-threads, r=Mark-Simulacrum
[libtest] Run the test synchronously when hitting thread limit
libtest currently panics if it hits the thread limit. This often results in spurious test failures (<code>thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }'</code> ... `error: test failed, to rerun pass '--lib'`). This PR makes it continue to run the test synchronously if it runs out of threads.
Fix panic in 'remove semicolon' when types are not local
It's not possible to check if removing a semicolon fixes the type error
when checking match arms and one or both of the last arm's and the
current arm's return types are imported "opaque" types. In these cases
we don't generate a "consider removing semicolon" suggestions.
bors [Thu, 18 Feb 2021 10:13:36 +0000 (10:13 +0000)]
Auto merge of #81574 - tmiasko:p, r=oli-obk
Precompute ancestors when checking privacy
Precompute ancestors of the old error node set so that check for private
types and traits in public interfaces can in constant time determine if
the current item has any descendants in the old error set.
This removes disparity in compilation time between public and private type
aliases reported in #50614 (from 30 s to 5 s, in an example making extensive use
of private type aliases).
Yuki Okushi [Thu, 18 Feb 2021 06:57:27 +0000 (15:57 +0900)]
Rollup merge of #82155 - tmiasko:once, r=matthewjasper
Use !Sync std::lazy::OnceCell in usefulness checking
The `rustc_data_structures::sync::OnceCell` is thread-safe when building
a parallel compiler. This is unnecessary for the purposes of pattern
usefulness checking. Use `!Sync` `std::lazy::OnceCell` instead.
bors [Thu, 18 Feb 2021 04:22:16 +0000 (04:22 +0000)]
Auto merge of #81172 - SimonSapin:ptr-metadata, r=oli-obk
Implement RFC 2580: Pointer metadata & VTable
RFC: https://github.com/rust-lang/rfcs/pull/2580
~~Before merging this PR:~~
* [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278).
* [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513
* [x] Update `#[unstable]` attributes in the PR with the tracking issue number
----
This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts, parameters can be assumed to implement it without a corresponding bound.
For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals, so careful review is appreciated.
This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`:
```rust
pub trait Pointee {
/// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>`
type Metadata: Copy + Send + Sync + Ord + Hash + Unpin;
}
unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {}
unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {}
```
API differences from the RFC, in areas noted as unresolved questions in the RFC:
* Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T`, following the precedent of `null`, `slice_from_raw_parts`, etc.
* Added `to_raw_parts`