Auto merge of #75608 - estebank:suggest-boxed-match-exprs, r=lcnr,varkor
More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions
When encountering a `match` or `if` as a tail expression where the
different arms do not have the same type *and* the return type of that
`fn` is an `impl Trait`, check whether those arms can implement `Trait`
and if so, suggest using boxed trait objects.
Use structured suggestion for `impl T` to `Box<dyn T>`.
Auto merge of #75740 - GuillaumeGomez:stabilize-doc-alias-feature, r=ollie27
Stabilize doc_alias feature
Fixes #50146.
This PR intend to stabilize the `doc_alias` feature. The last remaining bits were missing checks on the attribute usage and on its arguments. Both have been added so I think we can now move to the next step.
Auto merge of #76549 - ehuss:lints-comments, r=wesleywiser
Auto-generate lint documentation.
This adds a tool which will generate the lint documentation in the rustc book automatically. This is motivated by keeping the documentation up-to-date, and consistently formatted. It also ensures the examples are correct and that they actually generate the expected lint. The lint groups table is also auto-generated. See https://github.com/rust-lang/compiler-team/issues/349 for the original proposal.
An outline of how this works:
- The `declare_lint!` macro now accepts a doc comment where the documentation is written. This is inspired by how clippy works.
- A new tool `src/tools/lint-docs` scrapes the documentation and adds it to the rustc book during the build.
- It runs each example and verifies its output and embeds the output in the book.
- It does a few formatting checks.
- It verifies that every lint is documented.
- Groups are collected from `rustc -W help`.
I updated the documentation for all the missing lints. I have also added an "Explanation" section to each lint providing a reason for the lint and suggestions on how to resolve it.
This can lead towards a future enhancement of possibly showing these docs via the `--explain` flag to make them easily accessible and discoverable.
This is quite a bad hack to fix #75486. There might be a better way to check if the self type depends on generic parameters, but I wasn't able to come up with one.
Auto merge of #76123 - tmiasko:inline-args-storage, r=wesleywiser
inliner: Emit storage markers for introduced arg temporaries
When introducing argument temporaries during inlining, emit storage
marker statements just before the assignment and in the beginning of
the return block.
This ensures that such temporaries will not be considered live across
yield points after inlining inside a generator.
Auto merge of #76656 - jonas-schievink:fewer-unstable-metadata-queries, r=lcnr
Don't query stability data when `staged_api` is off
This data only needs to be encoded when `#![feature(staged_api)]` or `-Zforce-unstable-if-unmarked` is on. Running these queries takes measurable time on large crates with many items, so skip it when the unstable flags have not been enabled.
Auto merge of #76678 - jonas-schievink:rollup-vzl9yhx, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #75559 (unions: test move behavior of non-Copy fields)
- #76441 (Note that parallel-compiler = true causes tests to fail)
- #76527 (Remove internal and unstable MaybeUninit::UNINIT.)
- #76629 (Simplify iter zip struct doc)
- #76640 (Simplify SyncOnceCell's `take` and `drop`.)
- #76646 (Add mailmap entry)
- #76651 (Remove Windows details from Unix and VmWorks symlink() docstrings)
- #76663 (Simplify iter chain struct doc)
- #76665 (slice::from_raw_parts: explicitly mention that data must be initialized)
- #76667 (Fix CI LLVM to work on NixOS out of the box)
- #76668 (Add visualization of rustc span in doc)
- #76677 (note that test_stable_pointers does not reflect a stable guarantee)
Auto merge of #76623 - slightlyoutofphase:master, r=jyn514
Use `is_unstable_const_fn` instead of `is_min_const_fn` in rustdoc where appropriate
This closes #76501. Specifically, it allows for nightly users with the `#![feature(const_fn)]` flag enabled to still have their `const fn` declarations documented as such, while retaining the desired behavior that rustdoc *not* document functions that have the `rustc_const_unstable` attribute as `const`.
Auto merge of #76598 - ad-anssi:diagnostic_errors_fix, r=estebank
Fixing memory exhaustion when formatting short code suggestion
Details can be found in issue #76597. This PR replaces substractions with `saturating_sub`'s to avoid usize wrapping leading to memory exhaustion when formatting short suggestion messages.
Auto merge of #76658 - Aaron1011:fix/encode-dummy-loc-span, r=lcnr
Properly encode spans with a dummy location and non-root `SyntaxContext`
Previously, we would throw away the `SyntaxContext` of any span with a
dummy location during metadata encoding. This commit makes metadata Span
encoding consistent with incr-cache Span encoding - an 'invalid span'
tag is only used when it doesn't lose any information.
Auto merge of #76588 - guswynn:debug_logging, r=jyn514,Mark-Simulacrum
Add a dedicated debug-logging option to config.toml
`@Mark-Simulacrum` and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. `@Mark-Simulacrum` mentioned that we should probably have a separate option for logging anyways.
this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false
to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true
Aaron Hill [Sun, 13 Sep 2020 03:26:17 +0000 (23:26 -0400)]
Properly encode spans with a dummy location and non-root `SyntaxContext`
Previously, we would throw away the `SyntaxContext` of any span with a
dummy location during metadata encoding. This commit makes metadata Span
encoding consistent with incr-cache Span encoding - an 'invalid span'
tag is only used when it doesn't lose any information.
Auto merge of #76349 - Mark-Simulacrum:dl-llvm, r=alexcrichton
Download LLVM from CI to bootstrap (linux-only to start)
This follows #76332, adding support for using CI-built LLVM rather than building it locally. This should essentially "just work," but is left off by default in this PR.
While we can support downloading LLVM for multiple host triples, this currently only downloads it for the build triple. That said, it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though, so this should cover most use cases.
Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332, we can fix this behavior to reduce downloads further.
Auto merge of #76306 - tmiasko:nrvo-debuginfo, r=ecstatic-morse
NRVO: Allow occurrences of the return place in var debug info
The non-use occurrence of the return place in var debug info does not
currently inhibit NRVO optimization, but it will fail assertion in
`visit_place` when optimization is performed.
Relax assertion check to allow the return place in var debug info.
This case might be impossible to hit in optimization pipelines as of
now, but can be encountered in customized mir-opt-level=2 pipeline with
copy propagation disabled. For example in:
```rust
pub fn b(s: String) -> String {
a(s)
}
#[inline]
pub fn a(s: String) -> String {
let x = s;
let y = x;
y
}
```
Auto merge of #73461 - calebzulawski:validate-attribute-placement, r=matthewjasper
Validate built-in attribute placement
Closes #54584, closes #47725, closes #54044.
I've changed silently ignoring some incorrectly placed attributes to errors. I'm not sure what the policy is since this can theoretically break code (should they be warnings instead? does it warrant a crater run?).
Mark Rousskov [Sat, 12 Sep 2020 19:10:13 +0000 (15:10 -0400)]
Set link-shared if LLVM ThinLTO is enabled in config.rs
This avoids missing a shared build when uplifting LLVM artifacts into the
sysroot. We were already producing a shared link anyway, though, so this is not
a visible change from the end user's perspective.
Auto merge of #76538 - fusion-engineering-forks:check-useless-unstable-trait-impl, r=lcnr
Warn for #[unstable] on trait impls when it has no effect.
Earlier today I sent a PR with an `#[unstable]` attribute on a trait `impl`, but was informed that this attribute has no effect there. (comment: https://github.com/rust-lang/rust/pull/76525#issuecomment-689678895, issue: https://github.com/rust-lang/rust/issues/55436)
This PR adds a warning for this situation. Trait `impl` blocks with `#[unstable]` where both the type and the trait are stable will result in a warning:
```
warning: An `#[unstable]` annotation here has no effect. See issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information.
--> library/std/src/panic.rs:235:1
|
235 | #[unstable(feature = "integer_atomics", issue = "32976")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
---
It detects three problems in the existing code:
1. A few `RefUnwindSafe` implementations for the atomic integer types in `library/std/src/panic.rs`. Example:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/panic.rs#L235-L236
2. An implementation of `Error` for `LayoutErr` in `library/std/srd/error.rs`:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/error.rs#L392-L397
3. `From` implementations for `Waker` and `RawWaker` in `library/alloc/src/task.rs`. Example:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/alloc/src/task.rs#L36-L37
Case 3 interesting: It has a bound with an `#[unstable]` trait (`W: Wake`), so appears to have much effect on stable code. It does however break similar blanket implementations. It would also have immediate effect if `Wake` was implemented for any stable type. (Which is not the case right now, but there are no warnings in place to prevent it.) Whether this case is a problem or not is not clear to me. If it isn't, adding a simple `c.visit_generics(..);` to this PR will stop the warning for this case.
Auto merge of #76639 - Mark-Simulacrum:ci-hosts, r=pietroalbini
Add host triples to CI builders
This is a follow-up to #76415, which changed how x.py interprets cross-compilation target/host flags. This should fix the known cases, but I'm still working through CI logs before/after that PR to identify if anything else is missing.
Mark Rousskov [Sat, 12 Sep 2020 14:05:10 +0000 (10:05 -0400)]
Print all step timings
It is really painful to inspect differences in what was built in CI if things
are appearing and disappearing randomly as they hover around the 100ms mark. No
matter what we choose there's always going to be quite a bit of variability on
CI in timing, so we're going to see things appear and vanish.
Auto merge of #76632 - andjo403:updateDep, r=Mark-Simulacrum
update the version of itertools and parking_lot
this is to avoid compiling multiple version of the crates in rustc speeding up compilation of rustc
an old version of parking_lot is still used in measureme but new version will not be released for some time see [zulip chat](https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile/topic/new.20release.20of.20measureme)
Rollup merge of #76599 - hameerabbasi:const-generics-revs, r=lcnr
Finish off revisions for const generics UI tests.
This time it really does fix it. 😅 The only ones left are `min-and-full-same-time.rs`, which doesn't need it, and `array-impls/` which check the feature indirectly.
Rollup merge of #76583 - CDirkx:os-doc, r=jonas-schievink
Update `std::os` module documentation.
Adds missing descriptions for the modules `std::os::linux::fs` and `std::os::windows::io`.
Also adds punctuation for consistency with other descriptions.
Rollup merge of #76484 - fusion-engineering-forks:maybe-uninit-drop, r=RalfJung
Add MaybeUninit::assume_init_drop.
`ManuallyDrop`'s documentation tells the user to use `MaybeUninit` instead when handling uninitialized data. However, the main functionality of `ManuallyDrop` (`drop`) is not available directly on `MaybeUninit`. Adding it makes it easier to switch from one to the other.
I re-used the `maybe_uninit_extra` feature and tracking issue number (#63567), since it seems very related. (And to avoid creating too many features tracking issues for `MaybeUninit`.)
Rollup merge of #76114 - marmeladema:duration-saturating-ops, r=shepmaster
Add saturating methods for `Duration`
In some project, I needed a `saturating_add` method for `Duration`. I implemented it myself but i thought it would be a nice addition to the standard library as it matches closely with the integers types.
3 new methods have been introduced and are gated by the new `duration_saturating_ops` unstable feature:
* `Duration::saturating_add`
* `Duration::saturating_sub`
* `Duration::saturating_mul`
If have left the tracking issue to `none` for now as I want first to understand if those methods would be acceptable at all. If agreed, I'll update the PR with the tracking issue.
Further more, to match the behavior of integers types, I introduced 2 associated constants:
* `Duration::MIN`: this one is somehow a duplicate from `Duration::zero()` method, but at the time this method was added, `MIN` was rejected as it was considered a different semantic (see https://github.com/rust-lang/rust/pull/72790#issuecomment-636511743).
* `Duration::MAX`
Both have been gated by the already existing unstable feature `duration_constants`, I can introduce a new unstable feature if needed or just re-use the `duration_saturating_ops`.
We might have to decide whether:
* `MIN` should be replaced by `ZERO`?
* associated constants over methods?
- Add `PerNS::into_iter()` so I didn't have to keep rewriting hacks around it. Also add `PerNS::iter()` for consistency. Let me know if this should be `impl IntoIterator` instead.
- Make `ResolutionFailure` an enum instead of a unit variant. This was most of the changes: everywhere that said `ErrorKind::ResolutionFailure` now has to say _why_ the link failed to resolve.
- Store the resolution in case of an anchor failure. Previously this was implemented as variants on `AnchorFailure` which was prone to typos and had inconsistent output compared to the rest of the diagnostics.
- Turn some `Err`ors into unwrap() or panic()s, because they're rustdoc bugs and not user error. These have comments as to why they're bugs (in particular this would have caught #76073 as a bug a while ago).
- If an item is not in scope at all, say the first segment in the path that failed to resolve
- If an item exists but not in the current namespaces, say that and suggests linking to that namespace.
- If there is a partial resolution for an item (part of the segments resolved, but not all of them), say the partial resolution and why the following segment didn't resolve.
- Add the `DefId` of associated items to `kind_side_channel` so it can be used for diagnostics (tl;dr of the hack: the rest of rustdoc expects the id of the item, but for diagnostics we need the associated item).
- No longer suggests escaping the brackets for every link that failed to resolve; this was pretty obnoxious. Now it only suggests `\[ \]` if no segment resolved and there is no `::` in the link.
- Add `Suggestion`, which says _what_ to prefix the link with, not just 'prefix with the item kind'.
Places where this is currently buggy:
<details><summary>All outdated</summary>
~~1. When the link has the wrong namespace:~~ Now fixed.
<details>
```rust
/// [type@S::h]
impl S {
pub fn h() {}
}
/// [type@T::g]
pub trait T {
fn g() {}
}
```
```
error: unresolved link to `T::g`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:53:6
|
53 | /// [type@T::g]
| ^^^^^^^^^
|
= note: this link partially resolves to the trait `T`,
= note: `T` has no field, variant, or associated item named `g`
error: unresolved link to `S::h`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:48:6
|
48 | /// [type@S::h]
| ^^^^^^^^^
|
= note: this link partially resolves to the struct `S`,
= note: `S` has no field, variant, or associated item named `h`
```
Instead it should suggest changing the disambiguator, the way it currently does for macros:
```
error: unresolved link to `S`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:38:6
|
38 | /// [S!]
| ^^ help: to link to the unit struct, use its disambiguator: `value@S`
|
= note: this link resolves to the unit struct `S`, which is not in the macro namespace
```
</details>
2. ~~Associated items for values. It says that the value isn't in scope; instead it should say that values can't have associated items.~~ Fixed.
<details>
```
error: unresolved link to `f::A`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:14:6
|
14 | /// [f::A]
| ^^^^
|
= note: no item named `f` is in scope
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
```
This is _mostly_ fixed, it now says
```rust
warning: unresolved link to `f::A`
--> /home/joshua/test-rustdoc/f.rs:1:6
|
1 | /// [f::A]
| ^^^^
|
= note: this link partially resolves to the function `f`
= note: `f` is a function, not a module
```
'function, not a module' seems awfully terse when what I actually mean is '`::` isn't allowed here', though.
</details>
It looks a lot nicer now, it says
```
error: unresolved link to `f::A`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:13:6
|
13 | /// [f::A]
| ^^^^
|
= note: `f` is a function, not a module or type, and cannot have associated items
```
3. ~~I'm also not very happy with the second note for this error:~~
<details>
```
error: unresolved link to `S::A`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:19:6
|
19 | /// [S::A]
| ^^^^
|
= note: this link partially resolves to the struct `S`,
= note: `S` has no field, variant, or associated item named `A`
```
but I'm not sure how better to word it.
I ended up going with 'no `A` in `S`' to match `rustc_resolve` but that seems terse as well.
</details>
This now says
```
error: unresolved link to `S::A`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:17:6
|
17 | /// [S::A]
| ^^^^
|
= note: the struct `S` has no field or associated item named `A`
```
which I think looks pretty good :)
4. This is minor, but it would be nice to say that `path` wasn't found instead of the full thing:
```
error: unresolved link to `path::to::nonexistent::module`
--> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:8:6
|
8 | /// [path::to::nonexistent::module]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
It will now look at most 3 paths up (so it reports `path::to` as not in scope), but it doesn't work with arbitrarily many paths.
</details>
~~I recommend only reviewing the last few commits - the first 7 are all from #74489.~~ Rebased so that only the relevant commits are shown. Let me know if I should squash the history some more.
Auto merge of #75021 - cuviper:array_chunks_mut, r=scottmcm
Add `slice::array_chunks_mut`
This follows `array_chunks` from #74373 with a mutable version, `array_chunks_mut`. The implementation is identical apart from mutability. The new tests are adaptations of the `chunks_exact_mut` tests, plus an inference test like the one for `array_chunks`.
I reused the unstable feature `array_chunks` and tracking issue #74985, but I can separate that if desired.
Auto merge of #74328 - yoshuawuyts:stabilize-future-readiness-fns, r=sfackler
Stabilize core::future::{pending,ready}
This PR stabilizes `core::future::{pending,ready}`, tracking issue https://github.com/rust-lang/rust/issues/70921.
## Motivation
These functions have been on nightly for three months now, and have lived as part of the futures ecosystem for several years. In that time these functions have undergone several iterations, with [the `async-std` impls](https://docs.rs/async-std/1.6.2/async_std/future/index.html) probably diverging the most (using `async fn`, which in hindsight was a mistake).
It seems the space around these functions has been _thoroughly_ explored over the last couple of years, and the ecosystem has settled on the current shape of the functions. It seems highly unlikely we'd want to make any further changes to these functions, so I propose we stabilize.
## Implementation notes
This stabilization PR was fairly straightforward; this feature has already thoroughly been reviewed by the libs team already in https://github.com/rust-lang/rust/pull/70834. So all this PR does is remove the feature gate.
Esteban Küber [Tue, 18 Aug 2020 05:39:46 +0000 (22:39 -0700)]
Suggest boxed trait objects in tail `match` and `if` expressions
When encountering a `match` or `if` as a tail expression where the
different arms do not have the same type *and* the return type of that
`fn` is an `impl Trait`, check whether those arms can implement `Trait`
and if so, suggest using boxed trait objects.
Add `peek` and `peek_from` to `UnixStream` and `UnixDatagram`
This is my first PR, so I'm sure I've done some things wrong.
This PR:
* adds `peek` function to `UnixStream`;
* adds `peek` and `peek_from` to `UnixDatagram`;
* moves `UnixDatagram::recv_from` implementation to a private function `recv_from_flags`, as `peek_from` uses the same code, just with different flags.
I've taken the documentation from `TcpStream` and `UdpStream`, so it may or may not make sense (I'm bad with english words).
Also, I'm not sure what I should write in the `unstable` attribute, so I've made up the name and set the issue to "none".
Auto merge of #76499 - guswynn:priv_des, r=petrochenkov
Give better diagnostic when using a private tuple struct constructor
Fixes #75907
Some notes:
1. This required some deep changes, including removing a Copy impl for PatKind. If some tests fail, I would still appreciate review on the overall approach
2. this only works with basic patterns (no wildcards for example), and fails if there is any problems getting the visibility of the fields (i am not sure what the failure that can happen in resolve_visibility_speculative, but we check the length of our fields in both cases against each other, so if anything goes wrong, we fall back to the worse error. This could be extended to more patterns
3. this does not yet deal with #75906, but I believe it will be similar
4. let me know if you want more tests
5. doesn't yet at the suggestion that `@yoshuawuyts` suggested at the end of their issue, but that could be added relatively easily (i believe)
Auto merge of #76415 - Mark-Simulacrum:bootstrap-cross-compilation, r=alexcrichton
rustbuild: avoid trying to inversely cross-compile for build triple from host triples
This changes rustbuild's cross compilation logic to better match what users expect,
particularly, avoiding trying to inverse cross-compile for the build triple from host triples.
That is, if build=A, host=B, target=B, we do not want to try and compile for A from B.
Indeed, the only "known to run" triple when cross-compiling is the build triple A.
When testing for a particular target we need to be able to run binaries compiled for
that target though.
The last commit also modifies the default set of host/target triples to avoid producing
needless artifacts for the build triple:
The new behavior is to respect --host and --target when passed as the *only*
configured triples (no triples are implicitly added). The default for --host is
the build triple, and the default for --target is the host triple(s), either
configured or the default build triple.
Fixes #76333
r? `@alexcrichton` if possible, otherwise we'll need to hunt down a reviewer
projects / rust.git / log