Rollup merge of #63781 - mati865:clippy, r=oli-obk,ehuss
Run Clippy without json-rendered flag
Removed in https://github.com/rust-lang/rust/pull/62766
Replacing it with `--json=diagnostic-rendered-ansi` fails:
```
error: using `--json` requires also using `--error-format=json`
```
Running `./x.py clippy src/libstd` locally works fine (with colors) on Linux so I don't know if there is something to fix.
Rollup merge of #63780 - u32i64:issue-63712, r=estebank
Improve diagnostics: break/continue in wrong context
- Fix #63712
- Use `` `break` `` or `` `continue` `` instead of always `break` in `cannot _...`
- Show the enclosing closure or async block we're talking about
- `` `break` outside of loop `` -> `` `break` outside of a loop `` for consistency
Rollup merge of #61236 - GuillaumeGomez:system-theme, r=Mark-Simulacrum
take into account the system theme
Fixes #61079.
The CSS can now take into account the system theme. I used it to generate some content on the document and from there, if no theme has already been selected, it'll look at the system level theme.
bors [Wed, 21 Aug 2019 11:40:23 +0000 (11:40 +0000)]
Auto merge of #63779 - Centril:rollup-sx96dli, r=Centril
Rollup of 7 pull requests
Successful merges:
- #63721 (Do not emit JSON dumps of diagnostic codes)
- #63753 (Bump toml dependency.)
- #63755 (Use dedicated type for spans in pre-expansion gating.)
- #63759 (Allow 'default async fn' to parse.)
- #63760 (Update books)
- #63762 (`async_await` was stabilized in 1.39.0, not 1.38.0.)
- #63766 (Remove some duplication when resolving constants)
Rollup merge of #63760 - ehuss:update-books, r=ehuss
Update books
## nomicon
25 commits in 8a7d05615e5bc0a7fb961b4919c44f5221ee54da..38b9a76bc8b59ac862663807fc51c9b757337fd6
2019-08-07 07:46:59 -0500 to 2019-08-19 10:04:32 -0400
- Fix transmute_copy link
- some edits
- drop parenthetical
- clarify dangling
- fix def.n of dangling
- fold uninit integer rule with reading uninit memory
- refactor null a bit
- resolve some nits
- raw ptrs must be initialized like integers
- Apply suggestions from code review
- explain when metadata is invalid
- mention !
- add more cases of UB
- avoid redundant UB
- stick to broader UB for raw ptr offsets/derefs for now
- be more precise about dangling
- subsume the NonNull things as library types
- handle recursion in the heading
- Define 'producing'
- NonNull, NonZero*
- list more ptr offset computations
- UB
- Fix typo in subtyping
- Add colon to `MySuperSliceable` too
- Fix typo `str::mem` to `std::mem`
Rollup merge of #63721 - Mark-Simulacrum:decouple-error-index, r=matthewjasper
Do not emit JSON dumps of diagnostic codes
This decouples the error index generator from libsyntax for the most part (though it still depends on librustdoc for the markdown parsing and generation).
Rollup merge of #63723 - josephlr:sigemptyset, r=alexcrichton
Consolidate sigemptyset workarounds
In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.
Rollup merge of #63722 - Mark-Simulacrum:bootstrap-rustflags, r=alexcrichton
Don't use stage naming in RUSTFLAGS environment variables
This patch supports less behavior than before, since specifiying stage 1
vs stage 2 is no longer possible, but that is presumably a somewhat rare
use case anyway, so not supporting it seems acceptable (and it can be
readded easily if desired).
Rollup merge of #63691 - timvermeulen:chain-size-hint, r=scottmcm
Fix bug in iter::Chain::size_hint
`Chain::size_hint` currently ignores `self.state`, which means that the size hints of the underlying iterators are always combined regardless of the iteration state. This, of course, should only happen when the state is `ChainState::Both`.
Rollup merge of #63216 - oconnor663:take_read_to_end, r=sfackler
avoid unnecessary reservations in std::io::Take::read_to_end
Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:
1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.
The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.
Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.
Joe Richey [Mon, 19 Aug 2019 23:14:07 +0000 (16:14 -0700)]
Consolidate sigemptyset workarounds
In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.
Mark Rousskov [Mon, 19 Aug 2019 22:52:14 +0000 (18:52 -0400)]
Don't use stage naming in RUSTFLAGS environment variables
This patch supports less behavior than before, since specifiying stage 1
vs stage 2 is no longer possible, but that is presumably a somewhat rare
use case anyway, so not supporting it seems acceptable (and it can be
readded easily if desired).
Rollup merge of #63699 - gilescope:async-move-diagnostic, r=estebank
Fix suggestion from incorrect `move async` to `async move`.
PR for #61920. Happy with the test. There must be a better implementation though - possibly a MIR visitor to estabilsh a span that doesn't include the `async` keyword?
Rollup merge of #63376 - nikomatsakis:async-await-issue-62517, r=cramertj
use different lifetime name for object-lifetime-default elision
Introduce a distinct value for `LifetimeName` to use when this is a object-lifetime-default elision. This allows us to avoid creating incorrect lifetime parameters for the opaque types that result. We really need to overhaul this setup at some point! It's getting increasingly byzantine. But this seems like a relatively... surgical fix.
Rollup merge of #63252 - nrc:arc-doc, r=alexcrichton
Remove recommendation about idiomatic syntax for Arc::clone
I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs.
The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls.
Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional.
The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years.
The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case).
cc @nical (who added the docs in the first place; sorry :-) )
r? @alexcrichton (or someone else on @rust-lang/libs )
Niko Matsakis [Mon, 12 Aug 2019 14:41:05 +0000 (10:41 -0400)]
use static as object-lifetime default for type XX in `Foo<Item=XX>`
Currently the default is "inherited" from context, so e.g. `&impl
Foo<Item = dyn Bar>` would default to `&'x impl Foo<Item = dyn Bar +
'x>`, but this triggers an ICE and is not very consistent.
This patch doesn't implement what I expect would be the correct
semantics, because those are likely too complex. Instead, it handles
what I'd expect to be the common case -- where the trait has no
lifetime parameters.
Niko Matsakis [Thu, 8 Aug 2019 07:36:24 +0000 (03:36 -0400)]
distinguish object-lifetime-default elision from other elision
Object-lifetime-default elision is distinct from other forms of
elision; it always refers to some enclosing lifetime *present in the
surrounding type* (e.g., `&dyn Bar` expands to `&'a (dyn Bar + 'a)`.
If there is no enclosing lifetime, then it expands to `'static`.
Therefore, in an `impl Trait<Item = dyn Bar>` setting, we don't expand
to create a lifetime parameter for the `dyn Bar + 'X` bound. It will
just be resolved to `'static`.
Annoyingly, the responsibility for this resolution is spread across
multiple bits of code right now (`middle::resolve_lifetimes`,
`lowering`). The lowering code knows that the default is for an object
lifetime, but it doesn't know what the correct result would be.
Probably this should be fixed, but what we do now is a surgical fix:
we have it generate a different result for elided lifetimes in a
object context, and then we can ignore those results when figuring out
the lifetimes that are captured in the opaque type.
bors [Mon, 19 Aug 2019 17:04:10 +0000 (17:04 +0000)]
Auto merge of #63579 - alexcrichton:new-lockfile, r=Mark-Simulacrum
Use to Cargo's experimental lockfile format
This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
Alex Crichton [Thu, 15 Aug 2019 00:45:09 +0000 (17:45 -0700)]
Use to Cargo's experimental lockfile format
This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
projects / rust.git / log