bors [Mon, 1 Jun 2020 05:21:50 +0000 (05:21 +0000)]
Auto merge of #72844 - Dylan-DPC:rollup-i51qv5z, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #72776 (fulfill: try using SmallVec or Box for stalled_on)
- #72818 (Clean up E0622 explanation)
- #72823 (Add descriptions for all queries)
- #72832 (RELEASES.md: Expand `cargo tree` note to mention `cargo tree -d`)
- #72834 (Rephrase term 'non-pointer type')
Dylan DPC [Mon, 1 Jun 2020 01:14:16 +0000 (03:14 +0200)]
Rollup merge of #72834 - JOE1994:correct_confusing_term, r=sfackler
Rephrase term 'non-pointer type'
Hello :cat2: ,
If the reader assumes that 'pointer type's include 'smart pointer's,
the term 'non-pointer type' could mislead the reader to assume that
x should not be a smart pointer type. I tried to rephrase the term
'non-pointer type' to remove ambiguity in the doc comments.
closes #72335
Thank you for reviewing this PR! :superhero_woman:
Dylan DPC [Mon, 1 Jun 2020 01:14:05 +0000 (03:14 +0200)]
Rollup merge of #72776 - lcnr:stalled_on-smallvec, r=nnethercote
fulfill: try using SmallVec or Box for stalled_on
Tested both `Box` and `SmallVec` for `stalled_on`, with both resulting in a perf loss.
Adds a comment mentioning this and removes an now outdated FIXME.
Logging the length of `stalled_on` resulted in the following distribution while building a part of stage 1 libs:
``` 22627647 counts:
( 1) 20983696 (92.7%, 92.7%): process_obligation_len: 1
( 2) 959711 ( 4.2%, 97.0%): process_obligation_len: 2
( 3) 682326 ( 3.0%,100.0%): process_obligation_len: 0
( 4) 1914 ( 0.0%,100.0%): process_obligation_len: 3
```
cc @eddyb
r? @nnethercote
JOE1994 [Sun, 31 May 2020 19:58:06 +0000 (15:58 -0400)]
Rephrase term 'non-pointer type'
If the reader assumes that 'pointer type's include 'smart pointer's,
the term 'non-pointer type' could mislead the reader to assume that
x should not be a smart pointer type. I tried to rephrase the term
'non-pointer type' to remove ambiguity in the doc comments.
Dylan DPC [Sun, 31 May 2020 19:30:05 +0000 (21:30 +0200)]
Rollup merge of #72829 - JOE1994:clarify_terms, r=jonas-schievink
Clarify terms in doc comments
Doc comments of `copy_from_slice` say that people should use `clone_from_slice`
when 'src' doesn't implement `Copy`. However, 'src' is a reference and
it always implements `Copy`. The term 'src' should be fixed to `T`(element type of slice 'src') in
the doc comments.
JOE1994 [Sun, 31 May 2020 18:37:26 +0000 (14:37 -0400)]
Clarify terms in doc comments
Doc comments of 'copy_from_slice' say that people should use 'clone_from_slice'
when 'src' doesn't implement 'Copy'. However, 'src' is a reference and
it always implements 'Copy'. The term 'src' should be fixed to 'T' in
the doc comments.
bors [Sun, 31 May 2020 17:14:44 +0000 (17:14 +0000)]
Auto merge of #72767 - pnkfelix:track-devirtualized-filenames-issue-70924, r=eddyb
Track devirtualized filenames
Split payload of FileName::Real to track both real and virtualized paths.
(Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`)
This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file.
bors [Sun, 31 May 2020 01:07:37 +0000 (01:07 +0000)]
Auto merge of #72116 - petrhosek:fuchsia-ld-flags, r=tmandry
Update the Fuchsia linker defaults
This updates the linker defaults aligning them with Clang. Specifically,
we use 4K pages on all platforms, we always use BIND_NOW, we prefer all
loadable segments be separate and page aligned, and we support RELR
relocations.
Ralf Jung [Sat, 30 May 2020 21:09:02 +0000 (23:09 +0200)]
Rollup merge of #72773 - Rantanen:is_char_boundary-docs, r=joshtriplett
Fix is_char_boundary documentation
Given the "start _and/or end_" wording in the original, the way I understood it was that the `str::is_char_boundary` method would also return `true` for the last byte in a UTF-8 code point sequence. (Which would have meant that for a string consisting of nothing but 1 and 2 byte UTF-8 code point sequences, it would return nothing but `true`.)
In practice the method returns `true` only for the starting byte of each sequence and the end of the string: [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e9f5fc4d6bf2f1bf57a75f3c9a180770)
I was also somewhat tempted to remove the _The start and end of the string are considered to be boundaries_, since that's implied by the first sentence, but I decided to avoid bikeshedding over it and left it as it was since it's not wrong in relation to how the method behaves.
Ralf Jung [Sat, 30 May 2020 21:09:00 +0000 (23:09 +0200)]
Rollup merge of #72772 - RalfJung:valid-char, r=petrochenkov
miri validation: clarify valid values of 'char'
The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
Ralf Jung [Sat, 30 May 2020 21:08:51 +0000 (23:08 +0200)]
Rollup merge of #72666 - ivanloz:profile_emit_flag, r=matthewjasper
Add -Z profile-emit=<path> for Gcov gcda output.
Adds a -Z flag to control the file path that the Gcov gcda output is
written to during runtime. This flag expects a path and filename, e.g.
-Z profile-emit=gcov/out/lib.gcda.
This works similar to GCC/Clang's -fprofile-dir flag which allows
control over the output path for gcda coverage files.
Ralf Jung [Sat, 30 May 2020 21:08:49 +0000 (23:08 +0200)]
Rollup merge of #72657 - flip1995:impl_lint_pass-ty, r=matthewjasper
Allow types (with lifetimes/generics) in impl_lint_pass
cc https://github.com/rust-lang/rust-clippy/pull/5279#discussion_r430790267
This allows to implement `LintPass` for types with lifetimes and/or generics. The only thing, I'm not sure of is the `LintPass::name` function, which now includes the lifetime(s) (which will be `'_` most of the time) in the name returned for the lint pass, if it exists. But I don't think that this should be a problem, since the `LintPass::name` is never used for output for the user (?).
Ralf Jung [Sat, 30 May 2020 21:08:44 +0000 (23:08 +0200)]
Rollup merge of #72625 - Amanieu:asm-srcloc, r=petrochenkov
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Ralf Jung [Sat, 30 May 2020 21:08:42 +0000 (23:08 +0200)]
Rollup merge of #72543 - estebank:opaque-missing-lts-in-fn, r=nikomatsakis
Account for missing lifetime in opaque and trait object return types
When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.
Esteban Küber [Sun, 24 May 2020 17:34:03 +0000 (10:34 -0700)]
Account for missing lifetime in opaque return type
When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.
Ralf Jung [Sat, 30 May 2020 11:45:11 +0000 (13:45 +0200)]
Rollup merge of #72563 - RalfJung:multi-return, r=matthewjasper
multiple Return terminators are possible
@ecstatic-morse mentioned in https://github.com/rust-lang/rust/issues/72515 that multiple `Return` terminators are possible. Update the docs accordingly.
Ralf Jung [Sat, 30 May 2020 11:45:10 +0000 (13:45 +0200)]
Rollup merge of #72540 - davidtwco:issue-67552-mono-collector-comparison, r=varkor
mir: adjust conditional in recursion limit check
Fixes #67552.
This PR adjusts the condition used in the recursion limit check of
the monomorphization collector, from `>` to `>=`.
In #67552, the test case had infinite indirect recursion, repeating a
handful of functions (from the perspective of the monomorphization
collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold`
-> `Iterator::next` -> `rec`.
During this process, `resolve_associated_item` was invoked for
`Iterator::fold` (during the construction of an `Instance`), and
ICE'd due to substitutions needing inference. However, previous
iterations of this recursion would have called this function for
`Iterator::fold` - and did! - and succeeded in doing so (trivially
checkable from debug logging, `()` is present where `_` is in the substs
of the failing execution).
The expected outcome of this test case would be a recursion limit error
(which is present when the `identity` fn indirection is removed), and
the recursion depth of `rec` is increasing (other functions finish
collecting their neighbours and thus have their recursion depths reset).
When the ICE occurs, the recursion depth of `rec` is 256 (which matches
the recursion limit), which suggests perhaps that a different part of
the compiler is using a `>=` comparison and returning a different result
on this recursion rather than what it returned in every previous
recursion, thus stopping the monomorphization collector from reporting
an error on the next recursion, where `recursion_depth_of_rec > 256`
would have been true.
With grep and some educated guesses, we can determine that
the recursion limit check at line 818 in
`src/librustc_trait_selection/traits/project.rs` is the other check that
is using a different comparison. Modifying either comparison to be `>` or
`>=` respectively will fix the error, but changing the monomorphization
collector produces the nicer error.
Ralf Jung [Sat, 30 May 2020 11:45:06 +0000 (13:45 +0200)]
Rollup merge of #72499 - mendess:master, r=dtolnay
Override Box::<[T]>::clone_from
Avoid dropping and reallocating when cloning to an existing box if the lengths are the same.
It would be nice if this could also be specialized for `Copy` but I don't know how that works since it's not on stable. Will gladly look into it if it's deemed as a good idea.
This is my first PR with code, hope I did everything right :smile:
Ralf Jung [Sat, 30 May 2020 11:45:04 +0000 (13:45 +0200)]
Rollup merge of #72441 - doctorn:late-bound-lifetime-ice, r=nikomatsakis
Fix ICE with explicit late-bound lifetimes
Rather than returning an explicit late-bound lifetime as a generic argument count mismatch (which is not necessarily true), this PR propagates the presence of explicit late-bound lifetimes.
This avoids an ICE that can occur due to the presence of explicit late-bound lifetimes when building generic substitutions by explicitly ignoring them.
r? @varkor
cc @davidtwco (this removes a check you introduced in #60892)
Ralf Jung [Sat, 30 May 2020 11:45:02 +0000 (13:45 +0200)]
Rollup merge of #72368 - CAD97:rangeto, r=dtolnay
Resolve overflow behavior for RangeFrom
This specifies a documented unspecified implementation detail of `RangeFrom` and makes it consistently implement the specified behavior.
Specifically, `(u8::MAX).next()` is defined to cause an overflow, and resolve that overflow in the same manner as the `Step::forward` implementation.
The inconsistency that has existed is `<RangeFrom as Iterator>::nth`. The existing behavior should be plain to see after #69659: the skipping part previously always panicked if it caused an overflow, but the final step (to set up the state for further iteration) has always been debug-checked.
The inconsistency, then, is that `RangeFrom::nth` does not implement the same behavior as the naive (and default) implementation of just calling `next` multiple times. This PR aligns `RangeFrom::nth` to have identical behavior to the naive implementation. It also lines up with the standard behavior of primitive math in Rust everywhere else in the language: debug checked overflow.
cc @Amanieu
---
Followup to #69659. Closes #25708 (by documenting the panic as intended).
The documentation wording is preliminary and can probably be improved.
This will probably need an FCP, as it changes observable stable behavior.
bors [Sat, 30 May 2020 07:56:05 +0000 (07:56 +0000)]
Auto merge of #72768 - JohnTitor:rollup-6kwokh6, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #72033 (Update RELEASES.md for 1.44.0)
- #72162 (Add Extend::{extend_one,extend_reserve})
- #72419 (Miri read_discriminant: return a scalar instead of raw underlying bytes)
- #72621 (Don't bail out of trait selection when predicate references an error)
- #72677 (Fix diagnostics for `@ ..` binding pattern in tuples and tuple structs)
- #72710 (Add test to make sure -Wunused-crate-dependencies works with tests)
- #72724 (Revert recursive `TokenKind::Interpolated` expansion for now)
- #72741 (Remove unused mut from long-linker-command-lines test)
- #72750 (Remove remaining calls to `as_local_node_id`)
- #72752 (remove mk_bool)
Split payload of FileName::Real to track both real and virutalized paths.
Such splits arise from metadata refs into libstd.
This way, we can (in a follow on commit) continue to emit the virtual name into
things like the like the StableSourceFileId that ends up in incremetnal build
artifacts, while still using the devirtualized file path when we want to access
the file.
Note that this commit is intended to be a refactoring; the actual fix to the bug
in question is in a follow-on commit.
Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level.
### Before
#### tuple
```
error: `..` patterns are not allowed here
--> src/main.rs:4:19
|
4 | (_a, _x @ ..) => {}
| ^^
|
= note: only allowed in tuple, tuple struct, and slice patterns
error[E0308]: mismatched types
--> src/main.rs:4:9
|
3 | match x {
| - this expression has type `({integer}, {integer}, {integer})`
4 | (_a, _x @ ..) => {}
| ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 2 elements
|
= note: expected tuple `({integer}, {integer}, {integer})`
found tuple `(_, _)`
error: aborting due to 2 previous errors
```
#### tuple struct
```
error: `..` patterns are not allowed here
--> src/main.rs:6:25
|
6 | Binder(_a, _x @ ..) => {}
| ^^
|
= note: only allowed in tuple, tuple struct, and slice patterns
error[E0023]: this pattern has 2 fields, but the corresponding tuple struct has 3 fields
--> src/main.rs:6:9
|
1 | struct Binder(i32, i32, i32);
| ----------------------------- tuple struct defined here
...
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 2
error: aborting due to 2 previous errors
```
### After
*Note: final output edited during source review discussion, see thread for details*
#### tuple
```
error: `_x @` is not allowed in a tuple
--> src/main.rs:4:14
|
4 | (_a, _x @ ..) => {}
| ^^^^^^^ is only allowed in a slice
|
help: replace with `..` or use a different valid pattern
|
4 | (_a, ..) => {}
| ^^
error[E0308]: mismatched types
--> src/main.rs:4:9
|
3 | match x {
| - this expression has type `({integer}, {integer}, {integer})`
4 | (_a, _x @ ..) => {}
| ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 1 element
|
= note: expected tuple `({integer}, {integer}, {integer})`
found tuple `(_,)`
error: aborting due to 2 previous errors
```
#### tuple struct
```
error: `_x @` is not allowed in a tuple struct
--> src/main.rs:6:20
|
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^ is only allowed in a slice
|
help: replace with `..` or use a different valid pattern
|
6 | Binder(_a, ..) => {}
| ^^
error[E0023]: this pattern has 1 field, but the corresponding tuple struct has 3 fields
--> src/main.rs:6:9
|
1 | struct Binder(i32, i32, i32);
| ----------------------------- tuple struct defined here
...
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 1
Yuki Okushi [Sat, 30 May 2020 03:39:14 +0000 (12:39 +0900)]
Rollup merge of #72621 - Aaron1011:fix/trait-select-error, r=nikomatsakis
Don't bail out of trait selection when predicate references an error
Fixes #72590
With PR #70551, observing a `ty::Error` guarantees that compilation is
going to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a `ty::Error` - we can only affect
whether or not additional error messags are emitted.
By not bailing out, we avoid incorrectly determining that types are
`!Sized` when a type error is present, which allows us to avoid emitting
additional spurious error messages.
The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.
Yuki Okushi [Sat, 30 May 2020 03:39:10 +0000 (12:39 +0900)]
Rollup merge of #72162 - cuviper:extend_one, r=Mark-Simulacrum
Add Extend::{extend_one,extend_reserve}
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
Josh Stone [Wed, 13 May 2020 03:09:55 +0000 (20:09 -0700)]
Add Extend::{extend_one,extend_reserve}
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
projects / rust.git / log