Commit graph

149884 commits

Author SHA1 Message Date
Yuki Okushi
178d17f917
Rollup merge of #86285 - lnicola:rust-analyzer-2021-06-14, r=jonas-schievink
⬆️ rust-analyzer
2021-06-15 17:40:13 +09:00
Yuki Okushi
d921055a5e
Rollup merge of #86277 - jsha:remove-must-use, r=Manishearth
Remove must_use from ALLOWED_ATTRIBUTES

This is a fairly common attribute on methods, but is not something you need to know when reading the method docs - the purpose of the attribute is for the compiler to tell you about it if you forget to use a value.

Removing reclaims some valuable space in the summary of methods, particularly when the attribute has a long string value.

As discussed in #84309. Partially addresses #81482.

r? ```@Manishearth```
2021-06-15 17:40:12 +09:00
Yuki Okushi
e84ee522a9
Rollup merge of #86220 - est31:maybe-uninit-extra, r=RalfJung
Improve maybe_uninit_extra docs

For reasoning, see https://github.com/rust-lang/rust/issues/63567#issuecomment-858640987
2021-06-15 17:40:10 +09:00
Yuki Okushi
3f4d6d73a9
Rollup merge of #85792 - mjptree:refactor-windows-sockets, r=JohnTitor
Refactor windows sockets impl methods

No behavioural changes, but a bit tidier visual flow.
2021-06-15 17:40:09 +09:00
Yuki Okushi
5936ecc24f
Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics, r=m-ou-se
Stabilize `ops::ControlFlow` (just the type)

Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR).

With the new `?` desugar implemented, [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6).  (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).)  That resolves the only blocker I know of, so I'd like to propose that `ControlFlow` be considered for stabilization.

Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058, where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)).  Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594), and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589, https://github.com/jonhoo/rust-imap/issues/194).

As this will need an FCP, picking a libs member manually:
r? `@m-ou-se`

## Stabilized APIs

```rust
#[derive(Debug, Clone, Copy, PartialEq)]
pub enum ControlFlow<B, C = ()> {
    /// Exit the operation without running subsequent phases.
    Break(B),
    /// Move on to the next phase of the operation as normal.
    Continue(C),
}
```

As well as using `?` on a `ControlFlow<B, _>` in a function returning `ControlFlow<B, _>`.  (Note, in particular, that there's no `From::from`-conversion on the `Break` value, the way there is for `Err`s.)

## Existing APIs *not* stabilized here

All the associated methods and constants: `break_value`, `is_continue`, `map_break`, [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE), etc.

Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide.  But none of them are *essential*, so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow), they're all omitted from this PR.

They can be considered separately later, as further usage demonstrates which are important.
2021-06-15 17:40:08 +09:00
Yuki Okushi
1e14d397db
Rollup merge of #82179 - mbartlett21:patch-5, r=joshtriplett
Add functions `Duration::try_from_secs_{f32, f64}`

These functions allow constructing a Duration from a floating point value that could be out of range without panicking.

Tracking issue: #83400
2021-06-15 17:40:03 +09:00
Yuki Okushi
2d2f1a5e88
Rollup merge of #80269 - pickfire:patch-4, r=joshtriplett
Explain non-dropped sender recv in docs

Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Maybe it would be better to show an example of the pattern where `drop(tx)` is used when it is being cloned multiple times? Although I have seen it in quite a few articles but I am surprised that this part is not very clear with the current words without careful reading.

> If the corresponding Sender has disconnected, or it disconnects while this call is blocking, this call will wake up and return Err to indicate that no more messages can ever be received on this channel. However, since channels are buffered, messages sent before the disconnect will still be properly received.

Some words there may seemed similar if I carefully read and relate it but if I am new, I probably does not know "drop" makes it "disconnected". So I mention the words "drop" and "alive" to make it more relatable to lifetime.
2021-06-15 17:39:58 +09:00
bors
9089771daf Auto merge of #85541 - XAMPPRocky:relnotes_1.53.0, r=Mark-Simulacrum
Update RELEASES.md for 1.53.0

### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes_1.53.0/RELEASES.md)

r? `@Mark-Simulacrum`
cc `@rust-lang/release`
2021-06-15 05:18:37 +00:00
bors
d74b36ea2f Auto merge of #84867 - pnkfelix:rustdoc-revert-deref-recur, r=jyn514
rustdoc: revert deref recur to resume inclusion of impl ExtTrait<Local> for ExtType

As discussed here: https://github.com/rust-lang/rust/issues/82465#issuecomment-829290384, Revert PR #80653 to resolve issue #82465.

Issue #82465 was we had stopped including certain trait implementations, namely implementations on an imported type of an imported trait *instantiated on a local type*. That bug was injected by PR #80653.

Reverting #80653 means we don't list all the methods that you have accessible via recursively applying `Deref`.

[Discussion in last week's rustc triage meeting](https://zulip-archive.rust-lang.org/238009tcompilermeetings/19557weekly2021042954818.html#236680594) led us to conclude that the bug was worse than the enhancement, and there was not an obvious fix for the bug itself. So for the short term we  remove the enhancement, while in the long term we will work on figuring out a way to have our imported trait implementation cake and eat it too.
2021-06-15 00:13:53 +00:00
bors
539d7bd399 Auto merge of #86275 - lqd:ctfe-validation, r=RalfJung
Improve CTFE UB validation error messages

As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix.

From:
`type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0`

To:
`type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
2021-06-14 20:17:02 +00:00
Scott McMurray
590d4526e9 Master is 1.55 now :( 2021-06-14 10:37:05 -07:00
bors
304441960e Auto merge of #86117 - ehuss:force-warns-underscore, r=rylev
Fix force-warns to allow dashes.

The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores.  This changes it to allow dashes to match the behavior of the A/W/D/F flags.
2021-06-14 17:21:28 +00:00
Rémy Rakic
5af1c72513 Adjust throw_validation_failure macro to shorten the use of with_no_trimmed_paths 2021-06-14 18:57:53 +02:00
Rémy Rakic
19fddc019f Improve documentation on UndefinedBehaviorInfo::ValidationFailure 2021-06-14 18:57:06 +02:00
bors
a216131c35 Auto merge of #86273 - JohnTitor:stabilize-maybe-uninit-ref, r=RalfJung
Stabilize `maybe_uninit_ref`

This stabilizes `assume_init_{ref,mut}`. FCP is complete: https://github.com/rust-lang/rust/issues/63568#issuecomment-590121300
The renaming was done by #76047 and FIXME was resolved by #76241, so I think we can now stabilize them finally 🎉
Still, it's const-unstable as `assert_inhabited` is unstable.

Closes #63568
2021-06-14 13:05:54 +00:00
mbartlett21
7803955cae Use try_from_secs_* in Duration::from_secs_* functions.
`Duration::from_secs_{f32, f64}` now use the results from the
non-panicking functions and unwrap it.
2021-06-14 12:17:53 +00:00
mbartlett21
c2c1ca071f Add functions Duration::try_from_secs_{f32, f64}
This also adds the error type used, `FromSecsError` and its `impl`s.
2021-06-14 12:16:13 +00:00
est31
8710258714 Improve maybe_uninit_extra docs
For reasoning, see https://github.com/rust-lang/rust/issues/63567#issuecomment-858640987
2021-06-14 13:30:58 +02:00
bors
7510b0ca45 Auto merge of #85758 - petertodd:2021-revert-manuallydrop-clone-from, r=m-ou-se
Revert #85176 addition of `clone_from` for `ManuallyDrop`

Forwarding `clone_from` to the inner value changes the observable behavior, as previously the inner value would *not* be dropped by the default implementation.

Frankly, this is a super-niche case, so #85176 is welcome to argue the behavior should be otherwise! But if we overrride it, IMO documenting the behavior would be good.

Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c5d0856686fa850c1d7ee16891014efb
2021-06-14 10:24:48 +00:00
Laurențiu Nicola
69f88f55c5 ⬆️ rust-analyzer 2021-06-14 09:44:02 +03:00
Jacob Hoffman-Andrews
74e8e7bb60 Remove must_use from ALLOWED_ATTRIBUTES
This is a fairly common attribute on methods, but is not something you
need to know when reading the method docs - the purpose of the attribute
is for the compiler to tell you about it if you forget to use a value.

Removing reclaims some valuable space in the summary of methods.
2021-06-13 17:57:16 -07:00
bors
14831568d5 Auto merge of #86270 - Shadlock0133:patch-1, r=jackh726
Fix typo `with custom a custom` -> `with a custom`
2021-06-13 22:42:02 +00:00
Rémy Rakic
b87724053e update tests involving CTFE validation 2021-06-13 23:26:06 +02:00
Rémy Rakic
87ecf84c36 Improve CTFE validation error message 2021-06-13 22:40:42 +02:00
bors
f586d79d18 Auto merge of #86271 - GuillaumeGomez:fix-font-weight, r=jsha
Fix font weight

Fixes #86256.

I realized that the only cases where we actually needed to have bold text was inside `impl-items`.

cc `@camelid`
r? `@jsha`
2021-06-13 20:13:32 +00:00
Yuki Okushi
7fa1308db1
Stabilize maybe_uninit_ref 2021-06-14 05:08:03 +09:00
Guillaume Gomez
466aec9957 Add test to ensure font-weight is applied correctly 2021-06-13 21:50:11 +02:00
Guillaume Gomez
d87ec7ae19 Update browser-ui-test version 2021-06-13 21:49:30 +02:00
Guillaume Gomez
a8318e420d Fix font-weight 2021-06-13 21:49:10 +02:00
Shadlock0133
dab89b51ac
Fix typo with custom a custom -> with a custom 2021-06-13 21:21:45 +02:00
bors
fb3ea63d9b Auto merge of #86245 - lqd:const-ub-align, r=RalfJung
Fix ICEs on invalid vtable size/alignment const UB errors

The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that.

Fixes #86193

r? `@RalfJung`

(It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
2021-06-13 12:08:59 +00:00
Rémy Rakic
e29f3e837f Test invalid vtable size/alignment const UB errors 2021-06-13 13:11:07 +02:00
Rémy Rakic
cae1918b29 Turn incorrect vtable size/alignment errors into hard const-UB errors
They were "freeform const UB" error message, but could reach validation
and trigger ICEs there. We now catch them during validation to avoid
that.
2021-06-13 13:11:07 +02:00
bors
6cc5d5432a Auto merge of #86185 - klensy:ast-val, r=petrochenkov
simplify validate_generic_param_order
2021-06-13 09:36:12 +00:00
bors
a75e74df89 Auto merge of #86233 - JohnTitor:stabilize-simd-x86-bittest, r=Amanieu
Stabilize `simd_x86_bittest` feature

This pulls https://github.com/rust-lang/stdarch/pull/1180, FCP is complete: https://github.com/rust-lang/rust/issues/59414#issuecomment-826072554
Closes #59414
2021-06-13 01:27:37 +00:00
bors
302468e71c Auto merge of #86207 - ehuss:update-cargo, r=ehuss
Update cargo

11 commits in aa8b09297bb3156b849e73db48af4cd050492fe6..44456677b5d1d82fe981c955dc5c67734b31f340
2021-06-09 00:28:53 +0000 to 2021-06-12 18:00:01 +0000
- Fix package_default_run test. (rust-lang/cargo#9577)
- Change how the fix_deny_warnings_but_not_others test works (rust-lang/cargo#9571)
- Add mising documentation regarding `cargo doc` (rust-lang/cargo#9565)
- Implement warning for ignored trailing arguments (rust-lang/cargo#9561)
- Make clippy happy (rust-lang/cargo#9569)
- Fix rustc/rustdoc config values to be config-relative. (rust-lang/cargo#9566)
- Update rustfix. (rust-lang/cargo#9567)
- Warn if an "all" target is specified, but we don't match anything (rust-lang/cargo#9549)
- add default_run to SerializedPackage (rust-lang/cargo#9550)
- respect user choice of lib/bin over heuristics (rust-lang/cargo#9522)
- Add a mean to mutably access the members of a workspace (rust-lang/cargo#9547)
2021-06-12 23:08:16 +00:00
klensy
6a19867417 simplify validate_generic_param_order 2021-06-13 01:39:57 +03:00
bors
24bdc6d73a Auto merge of #86240 - tmiasko:verbose-generator-witness, r=jackh726
Pretty print generator witness only in `-Zverbose` mode

In release build of deeply-nested-async benchmark the size of
`no-opt.bc` file is reduced from 46MB to 62kB.

Helps with #84873, where in one of reported test cases the size of `no-opt.bc`
file is reduced from 2.3GB to 799kB.
2021-06-12 20:38:17 +00:00
Eric Huss
d371bb4d59 Update cargo 2021-06-12 12:11:50 -07:00
Yuki Okushi
b8b559cfcb Update stdarch submodule to stabilize simd_x86_bittest feature 2021-06-13 02:29:17 +09:00
Tomasz Miąsko
06ca736e14 Pretty print generator witness only in -Zverbose mode
In release build of deeply-nested-async benchmark the size of
`no-opt.bc` file is reduced from 46MB to 62kB.
2021-06-12 18:28:17 +02:00
bors
da7ada584a Auto merge of #82703 - iago-lito:nonzero_add_mul_pow, r=m-ou-se
Implement nonzero arithmetics for NonZero types.

Hello'all, this is my first PR to this repo.

Non-zero natural numbers are stable by addition/multiplication/exponentiation, so it makes sense to make this arithmetic possible with `NonZeroU*`.

The major pitfall is that overflowing underlying `u*` types possibly lead to underlying `0` values, which break the major invariant of `NonZeroU*`. To accommodate it, only `checked_` and `saturating_` operations are implemented.

Other variants allowing wrapped results like `wrapping_` or `overflowing_` are ruled out *de facto*.

`impl Add<u*> for NonZeroU* { .. }` was considered, as it panics on overflow which enforces the invariant, but it does not so in release mode. I considered forcing `NonZeroU*::add` to panic in release mode by deferring the check to `u*::checked_add`, but this is less explicit for the user than directly using `NonZeroU*::checked_add`.
Following `@Lokathor's` advice on zulip, I have dropped the idea.

`@poliorcetics` on Discord also suggested implementing `_sub` operations, but I'd postpone this to another PR if there is a need for it. My opinion is that it could be useful in some cases, but that it makes less sense because non-null natural numbers are not stable by subtraction even in theory, while the overflowing problem is just about technical implementation.

One thing I don't like is that the type of the `other` arg differs in every implementation: `_add` methods accept any raw positive integer, `_mul` methods only accept non-zero values otherwise the invariant is also broken, and `_pow` only seems to accept `u32` for a reason I ignore but that seems consistent throughout `std`. Maybe there is a better way to harmonize this?

This is it, Iope I haven't forgotten anything and I'll be happy to read your feedback.
2021-06-12 15:29:51 +00:00
bors
60f1a2fc4b Auto merge of #86215 - FabianWolff:unnameable-types, r=jackh726
Do not suggest to add type annotations for unnameable types

Consider this example:
```rust
const A = || 42;

struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
 --> src/lib.rs:1:7
  |
1 | const A = || 42;
  |       ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/lib.rs:4:10
  |
4 | const B: _ = S { t: || 42 };
  |          ^
  |          |
  |          not allowed in type signatures
  |          help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`

error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
 --> test.rs:1:7
  |
1 | const A = || 42;
  |       ^
  |
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
 --> test.rs:1:11
  |
1 | const A = || 42;
  |           ^^^^^

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> test.rs:4:10
  |
4 | const B: _ = S { t: || 42 };
  |          ^ not allowed in type signatures
  |
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
 --> test.rs:4:14
  |
4 | const B: _ = S { t: || 42 };
  |              ^^^^^^^^^^^^^^

error: aborting due to 2 previous errors
```
2021-06-12 11:12:16 +00:00
Iago-lito
7afdaf2c06 Stop relying on #[feature(try_trait)] in doctests. 2021-06-12 10:58:37 +02:00
bors
d59b80d588 Auto merge of #86130 - BoxyUwU:abstract_const_as_cast, r=oli-obk
const_eval_checked: Support as casts in abstract consts
2021-06-12 08:50:22 +00:00
Ivan Tham
0f3c7d18fb Explain non-dropped sender recv in docs
Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Fix minor tidbits in sender recv doc

Co-authored-by: Dylan DPC <dylan.dpc@gmail.com>

Add example for unbounded receive loops in doc

Show the drop(tx) pattern, based on tokio docs
https://tokio-rs.github.io/tokio/doc/tokio/sync/index.html

Fix example code for drop sender recv

Fix wording in sender docs

Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-06-12 14:56:46 +08:00
bors
0f6ba39fd8 Auto merge of #86180 - cjgillot:defmv, r=petrochenkov
Hash DefId in rustc_span.

This is mostly just moving code around. Changes are simplifications of unneeded callbacks from rustc_span to rustc_middle.

r? `@petrochenkov`
2021-06-12 06:09:20 +00:00
bors
b84ffce1aa Auto merge of #86234 - Mark-Simulacrum:new-vers, r=Mark-Simulacrum
Bump to 1.55

r? `@Mark-Simulacrum`
2021-06-12 03:46:33 +00:00
bors
3198c523cc Auto merge of #86226 - JohnTitor:rollup-5ubdolf, r=JohnTitor
Rollup of 7 pull requests

Successful merges:

 - #85800 (Fix some diagnostic issues with const_generics_defaults feature gate)
 - #85823 (Do not suggest ampmut if rhs is already mutable)
 - #86153 (Print dummy spans as `no-location`)
 - #86174 (Detect incorrect vtable alignment during const eval)
 - #86189 (Make `relate_type_and_mut` public)
 - #86205 (Run full const-generics test for issue-72293)
 - #86217 (Remove "generic type" in boxed.rs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-06-12 01:21:56 +00:00
Mark Rousskov
0dc44561b8 Bump to 1.54 2021-06-11 19:19:55 -04:00