bors [Sat, 20 Jun 2020 02:45:08 +0000 (02:45 +0000)]
Auto merge of #73528 - Manishearth:rollup-7djz8nd, r=Manishearth
Rollup of 16 pull requests
Successful merges:
- #71420 (Specialization is unsound)
- #71899 (Refactor `try_find` a little)
- #72689 (add str to common types)
- #72791 (update coerce docs and unify relevant tests)
- #72934 (forbid mutable references in all constant contexts except for const-fns)
- #73027 (Make `need_type_info_err` more conservative)
- #73347 (Diagnose use of incompatible sanitizers)
- #73359 (shim.rs: avoid creating `Call` terminators calling `Self`)
- #73399 (Clean up E0668 explanation)
- #73436 (Clean up E0670 explanation)
- #73440 (Add src/librustdoc as an alias for src/tools/rustdoc)
- #73442 (pretty/mir: const value enums with no variants)
- #73452 (Unify region variables when projecting associated types)
- #73458 (Use alloc::Layout in DroplessArena API)
- #73484 (Update the doc for std::prelude to the correct behavior)
- #73506 (Bump Rustfmt and RLS)
Rollup merge of #73452 - matthewjasper:auto-rec, r=nikomatsakis
Unify region variables when projecting associated types
This is required to avoid cycles when evaluating auto trait predicates.
Notably, this is required to be able add Chalk types to `CtxtInterners` for `cfg(parallel_compiler)`.
Rollup merge of #73442 - davidtwco:issue-72181-pretty-print-const-val-enum-no-variants, r=oli-obk
pretty/mir: const value enums with no variants
Fixes #72181.
This PR modifies the pretty printer and const eval in the MIR so that `destructure_const` (used in `pretty_print_const_value`) can handle enums with no variants (or types containing enums with no variants).
I'm not convinced that this is the correct approach, folks more familiar with `destructure_const` would be able to say - happy to adjust the PR. Looking through `destructure_const` and the functions that it invokes, it didn't seem like it was written to handle zero-variant-enums - I assume that case is handled earlier in some way so `destructure_const` doesn't need to under normal circumstances. It didn't seem like it would be straightforward to make `destructure_const` handle this case in a first-class-feeling way (e.g. adding a `Variants::None` variant), so this PR makes some minimal changes to avoid ICEs.
Rollup merge of #73347 - tmiasko:incompatible-sanitizers, r=nikic
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
Rollup merge of #73027 - doctorn:issue-72690, r=estebank
Make `need_type_info_err` more conservative
Makes sure arg patterns we are going to suggest on are actually contained within the span of the obligation that caused the inference error (credit to @lcnr for suggesting this fix).
There's a subtle trade-off regarding the handling of local patterns which I've left a comment about.
Rollup merge of #72689 - lcnr:common_str, r=estebank
add str to common types
I already expected this to be the case and it may slightly improve perf.
Afaict if we ever want to change str into a lang item this would have to get reverted.
As that would be fairly simple I don't believe this to cause any problems in the future.
Rollup merge of #71899 - cuviper:try_find_map, r=dtolnay
Refactor `try_find` a little
~~This works like `find_map`, but mapping to a `Try` type. It stops when `Ok` is `Some(value)`, with an additional short-circuit on `Try::Error`. This is similar to the unstable `try_find`, but has the advantage of being able to directly return the user's `R: Try` type directly, rather than converting to `Result`.~~
(removed -- `try_find_map` was declined in review)
This PR also refactors `try_find` a little to match style. The `E` type parameter was unnecessary, so it's now removed. The folding closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional change in this.
Rollup merge of #71420 - RalfJung:specialization-incomplete, r=matthewjasper
Specialization is unsound
As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949, it might be a good idea to warn users of specialization that the feature they are using is unsound.
I also expanded the "incomplete feature" warning to link the user to the tracking issue.
bors [Fri, 19 Jun 2020 23:04:41 +0000 (23:04 +0000)]
Auto merge of #73511 - Manishearth:rollup-3iffxd8, r=Manishearth
Rollup of 13 pull requests
Successful merges:
- #71568 (Document unsafety in slice/sort.rs)
- #72709 (`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc)
- #73214 (Add asm!() support for hexagon)
- #73248 (save_analysis: improve handling of enum struct variant)
- #73257 (ty: projections in `transparent_newtype_field`)
- #73261 (Suggest `?Sized` when applicable for ADTs)
- #73300 (Implement crate-level-only lints checking.)
- #73334 (Note numeric literals that can never fit in an expected type)
- #73357 (Use `LocalDefId` for import IDs in trait map)
- #73364 (asm: Allow multiple template string arguments; interpret them as newline-separated)
- #73382 (Only display other method receiver candidates if they actually apply)
- #73465 (Add specialization of `ToString for char`)
- #73489 (Refactor hir::Place)
Josh Stone [Mon, 4 May 2020 18:25:54 +0000 (11:25 -0700)]
Refactor `try_find` a little
The `E` type parameter was unnecessary, so it's now removed. The folding
closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional
change in this.
Rollup merge of #73489 - sexxi-goose:init_place_refactor, r=nikomatsakis
Refactor hir::Place
For the following code
```rust
let c = || bar(foo.x, foo.x)
```
We generate two different `hir::Place`s for both `foo.x`.
Handling this adds overhead for analysis we need to do for RFC 2229.
We also want to store type information at each Projection to support
analysis as part of the RFC. This resembles what we have for
`mir::Place`
This commit modifies the Place as follows:
- Rename to `PlaceWithHirId`, where there `hir_id` is that of the
expressioin.
- Move any other information that describes the access out to another
struct now called `Place`.
- Removed `Span`, it can be accessed using the [hir
API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span)
- Modify `Projection` to be a strucutre of its own, that currently only
contains the `ProjectionKind`.
Adding type information to projections wil be completed as part of https://github.com/rust-lang/project-rfc-2229/issues/5
Rollup merge of #73364 - joshtriplett:inline-asm, r=Amanieu
asm: Allow multiple template string arguments; interpret them as newline-separated
Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument.
This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`.
For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings:
```rust
fn main() {
let mut bits = [0u8; 64];
for value in 0..=1024u64 {
let popcnt;
unsafe {
asm!(
" popcnt {popcnt}, {v}",
"2:",
" blsi rax, {v}",
" jz 1f",
" xor {v}, rax",
" tzcnt rax, rax",
" stosb",
" jmp 2b",
"1:",
v = inout(reg) value => _,
popcnt = out(reg) popcnt,
out("rax") _, // scratch
inout("rdi") bits.as_mut_ptr() => _,
);
}
println!("bits of {}: {:?}", value, &bits[0..popcnt]);
}
}
```
Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
Rollup merge of #73334 - ayazhafiz:err/num-type-cannot-fit, r=estebank
Note numeric literals that can never fit in an expected type
re https://github.com/rust-lang/rust/pull/72380#discussion_r438289385
Given the toy code
```rust
fn is_positive(n: usize) {
n > -1_isize;
}
```
We currently get a type mismatch error like the following:
```
error[E0308]: mismatched types
--> src/main.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^ expected `usize`, found `isize`
|
help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit
|
2 | n > (-1_isize).try_into().unwrap();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
But clearly, `-1` can never fit into a `usize`, so the suggestion will
always panic. A more useful message would tell the user that the value
can never fit in the expected type:
```
error[E0308]: mismatched types
--> test.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^ expected `usize`, found `isize`
|
note: `-1_isize` can never fit into `usize`
--> test.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^
```
Which is what this commit implements.
I only added this check for negative literals because
- Currently we can only perform such a check for literals (constant
value propagation is outside the scope of the typechecker at this
point)
- A lint error for out-of-range numeric literals is already emitted
IMO it makes more sense to put this check in librustc_lint, but as far
as I can tell the typecheck pass happens before the lint pass, so I've
added it here.
Rollup merge of #73300 - crlf0710:crate_level_only_check, r=petrochenkov
Implement crate-level-only lints checking.
This implements a crate_level_only flag on lints, and when it is true, it becomes an error when user tries to specify this flag upon nodes other than crate node.
This also turns on this flag for all non_ascii_ident lints.
Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc, r=nikomatsakis
`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc
This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint, i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations.
This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065
Tracking issue for the feature: #71668.
~~Blocked on #71862.~~
r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?
David Wood [Thu, 18 Jun 2020 09:37:59 +0000 (10:37 +0100)]
pretty/mir: const value enums with no variants
This commit modifies the pretty printer and const eval in the MIR so
that `destructure_const` (used in `pretty_print_const_value`) can handle
enums with no variants (or types containing enums with no variants).
Ralf Jung [Fri, 19 Jun 2020 12:29:35 +0000 (14:29 +0200)]
Rollup merge of #73352 - ehuss:bootstrap-metadata, r=Mark-Simulacrum
Speed up bootstrap a little.
The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation, and this attempts to avoid the extra calls. On my system, a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4.
An overview of the changes:
- Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config).
- Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there, it looks like a mistake or vestigial from previous behavior.
- Remove check for `_shim`, I believe all the `_shim` crates are now gone.
- Remove check for `rustc_` and `*san` for `test::Crate::should_run`, these are no longer dependencies in the `test` tree.
- Use relative paths in `./x.py test -h -v` output.
- Some code cleanup (remove unnecessary `find_compiler_crates`, etc.).
- Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output.
- Some doc comments.
Ralf Jung [Fri, 19 Jun 2020 12:29:33 +0000 (14:29 +0200)]
Rollup merge of #73350 - nodakai:install-rs-support-nonexistent-prefix, r=Mark-Simulacrum
bootstrap/install.rs: support a nonexistent `prefix` in `x.py install`
PR #49778 introduced fs::canonicalize() which fails for a nonexistent path.
This is a surprise for someone used to GNU Autotools' configure which can create any necessary intermediate directories in prefix.
This change makes it run fs::create_dir_all() before canonicalize().
Ralf Jung [Fri, 19 Jun 2020 12:29:31 +0000 (14:29 +0200)]
Rollup merge of #73317 - davidtwco:bootstrap-config-env-var, r=Mark-Simulacrum
bootstrap: read config from $RUST_BOOTSTRAP_CONFIG
This PR modifies bootstrap so that `config.toml` is read first from `RUST_BOOTSTRAP_CONFIG`, then `--config` and finally `config.toml` in the current directory.
This is a subjective change, intended to improve the ergnomics when using "development shells" for rustc development (for example, using tools such as Nix) which set environment variables to ensure a reproducible environment (these development shells can then be version controlled, e.g. [my rustc shell](https://github.com/davidtwco/veritas/blob/6b74a5c170b6efb2c7b094352932f9158f97eec0/nix/shells/rustc.nix)). By optionally reading `config.toml` from an environment variable, a `config.toml` can be defined in the development shell and a path to it exposed in the `RUST_BOOTSTRAP_CONFIG` environment variable - avoiding the need to manually symlink the contents of this file to `config.toml` in the working directory.
Ralf Jung [Fri, 19 Jun 2020 12:29:26 +0000 (14:29 +0200)]
Rollup merge of #73136 - alexcrichton:thinlto-compiler-builtins, r=Mark-Simulacrum
Change how compiler-builtins gets many CGUs
This commit intends to fix an accidental regression from #70846. The
goal of #70846 was to build compiler-builtins with a maximal number of
CGUs to ensure that each module in the source corresponds to an object
file. This high degree of control for compiler-builtins is desirable to
ensure that there's at most one exported symbol per CGU, ideally
enabling compiler-builtins to not conflict with the system libgcc as
often.
In #70846, however, only part of the compiler understands that
compiler-builtins is built with many CGUs. The rest of the compiler
thinks it's building with `sess.codegen_units()`. Notably the
calculation of `sess.lto()` consults `sess.codegen_units()`, which when
there's only one CGU it disables ThinLTO. This means that
compiler-builtins is built without ThinLTO, which is quite harmful to
performance! This is the root of the cause from #73135 where intrinsics
were found to not be inlining trivial functions.
The fix applied in this commit is to remove the special-casing of
compiler-builtins in the compiler. Instead the build system is now
responsible for special-casing compiler-builtins. It doesn't know
exactly how many CGUs will be needed but it passes a large number that
is assumed to be much greater than the number of source-level modules
needed. After reading the various locations in the compiler source, this
seemed like the best solution rather than adding more and more special
casing in the compiler for compiler-builtins.
Ralf Jung [Fri, 19 Jun 2020 12:29:22 +0000 (14:29 +0200)]
Rollup merge of #73044 - tmiasko:compiletest-san, r=nikomatsakis
compiletest: Add directives to detect sanitizer support
Add needs-sanitizer-{address,leak,memory,thread} directive indicating
that test requires target with support for specific sanitizer.
This is an addition to the existing needs-sanitizer-support directive
indicating that test requires a sanitizer runtime library.
The existing needs-sanitizer-support directive could be incorporated into the
new ones, but I decided to retain it, since it enables running sanitizer
codegen tests even when building of sanitizer runtime libraries is disabled.
Ralf Jung [Fri, 19 Jun 2020 12:29:20 +0000 (14:29 +0200)]
Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass, r=tmandry
first stage of implementing LLVM code coverage
This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST).
This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation.
This initial version only injects counters at the top of each function, and does not yet implement the required coverage map.
Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch.
Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
***[I put together some development notes here, under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
Ralf Jung [Fri, 19 Jun 2020 12:29:16 +0000 (14:29 +0200)]
Rollup merge of #72280 - nbdd0121:typeck, r=nikomatsakis
Fix up autoderef when reborrowing
Currently `(f)()` and `f.call_mut()` behaves differently if expression `f` contains autoderef in it. This causes a weird error in #72225.
When `f` is type checked, `Deref` is used (this is expected as we can't yet determine if we should use `Fn` or `FnMut`). When subsequently we determine the actual trait to be used, when using the `f.call_mut()` syntax the `Deref` is patched to `DerefMut`, while for the `(f)()` syntax case it is not.
David Wood [Fri, 12 Jun 2020 15:14:05 +0000 (16:14 +0100)]
ty: simplify `transparent_newtype_field`
This commit removes the normalization from `transparent_newtype_field` -
turns out it wasn't necessary and that makes it a bunch simpler -
particularly when handling projections.
David Wood [Fri, 12 Jun 2020 12:30:39 +0000 (13:30 +0100)]
lint: prohibit fields with opaque types
Opaque types cannot be used in extern declarations, and normally cannot
exist in fields - except with type aliases to `impl Trait` and
projections which normalize to them.
bors [Fri, 19 Jun 2020 08:34:50 +0000 (08:34 +0000)]
Auto merge of #73498 - RalfJung:rollup-1mfjcju, r=RalfJung
Rollup of 13 pull requests
Successful merges:
- #70740 (Enabling static-pie for musl)
- #72331 (Report error when casting an C-like enum implementing Drop)
- #72486 (Fix asinh of negative values)
- #72497 (tag/niche terminology cleanup)
- #72999 (Create self-contained directory and move there some of external binaries/libs)
- #73130 (Remove const prop for indirects)
- #73142 (Ensure std benchmarks get tested.)
- #73305 (Disallow loading crates with non-ascii identifier name.)
- #73346 (Add rust specific features to print target features)
- #73362 (Test that bounds checks are elided when slice len is checked up-front)
- #73459 (Reduce pointer casts in Box::into_boxed_slice)
- #73464 (Document format correction)
- #73479 (Minor tweaks to liballoc)
Ralf Jung [Fri, 19 Jun 2020 06:56:12 +0000 (08:56 +0200)]
Rollup merge of #73346 - aszenz:patch-1, r=cuviper
Add rust specific features to print target features
Fixes #71583
`crt-static` is a rust specific target feature that's absent from llvm feature table, adding it there so that it shows under `rustc --print target-features`.
Probably the most native implementation I could think of, would love to get feedback.
Ralf Jung [Fri, 19 Jun 2020 06:56:08 +0000 (08:56 +0200)]
Rollup merge of #73142 - ehuss:std-benches, r=dtolnay
Ensure std benchmarks get tested.
This ensures that the std benchmarks don't break in the future. Currently they aren't compiled or tested on CI, so they can easily bitrot. Testing a benchmark runs it with one iteration. Adding these should only add a few seconds to CI.
Ralf Jung [Fri, 19 Jun 2020 06:56:04 +0000 (08:56 +0200)]
Rollup merge of #72999 - mati865:separate-self-contained-dir, r=Mark-Simulacrum
Create self-contained directory and move there some of external binaries/libs
One of the steps to reach design described in https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380
This PR moves things around and allows link code to handle the new directory structure.
Ralf Jung [Fri, 19 Jun 2020 06:56:02 +0000 (08:56 +0200)]
Rollup merge of #72497 - RalfJung:tag-term, r=oli-obk
tag/niche terminology cleanup
The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).
After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).
This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419.
(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)
Ralf Jung [Fri, 19 Jun 2020 06:55:59 +0000 (08:55 +0200)]
Rollup merge of #72486 - Ralith:asinh-fix, r=dtolnay
Fix asinh of negative values
Rust's current implementation of asinh has [large errors](https://www.wolframalpha.com/input/?i=arcsinh%28x%29%2C+ln%28x%2B%28x%5E2%2B1%29%5E0.5%29%2C+x+from+-67452095.07139316+to+0) in its negative range. ~These are (mostly) not numerical, but rather seem due to an incorrect implementation.~ This appears to be due to avoidable catastrophic cancellation.
[Playground before/after](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bd04ae6d86d06612e4e389a8b95d19ab).
[glibc uses](https://github.com/bminor/glibc/blob/81dca813cc35f91414731fdd0ff6b756d5e1827f/sysdeps/ieee754/dbl-64/s_asinh.c#L56) abs here.
Many thanks to @danieldeankon for finding this weird behavior, @jebrosen for diagnosing it, and @toasteater for identifying the probable implementation error!
Aman Arora [Wed, 17 Jun 2020 22:13:05 +0000 (18:13 -0400)]
Refactor hir::Place
For the following code
```rust
let c = || bar(foo.x, foo.x)
```
We generate two different `hir::Place`s for both `foo.x`.
Handling this adds overhead for analysis we need to do for RFC 2229.
We also want to store type information at each Projection to support
analysis as part of the RFC. This resembles what we have for
`mir::Place`
This commit modifies the Place as follows:
- Rename to `PlaceWithHirId`, where there `hir_id` is that of the
expressioin.
- Move any other information that describes the access out to another
struct now called `Place`.
- Removed `Span`, it can be accessed using the [hir
API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span)
- Modify `Projection` to be a strucutre of its own, that currently only
contains the `ProjectionKind`.
Adding type information to projections wil be completed as part of https://github.com/rust-lang/project-rfc-2229/issues/5
Rollup merge of #73476 - JakobDegen:should_panic_rustdoc, r=GuillaumeGomez
Added tooltip for should_panic code examples
This change adds a tooltip to the documentation for `should_panic` examples. It currently displays identically to `compile_fail` examples, save for the changed text. It may be helpful to change the color that this displays in to make it visually more clear what is going on, but I'm unsure if additional colors wouldn't just be distracting.
I brought this [up on internals](https://internals.rust-lang.org/t/indicating-that-an-example-is-should-panic-in-docs/12544) a few days ago, and there seemed to be a mild positive response to it.
Rollup merge of #73425 - poliorcetics:zeroed-functions-pointers, r=dtolnay
Mention functions pointers in the documentation
Fixes #51615.
This mentions function pointers in the documentation for `core::mem::zeroed`, adding them to the list of types that are **always** wrong when zeroed, with `&T` and `&mut T`.
Rollup merge of #73361 - estebank:non-primitive-cast, r=davidtwco
Tweak "non-primitive cast" error
- Suggest borrowing expression if it would allow cast to work.
- Suggest using `<Type>::from(<expr>)` when appropriate.
- Minor tweak to `;` typo suggestion.
Rollup merge of #72968 - integer32llc:docs-arrow-keys, r=GuillaumeGomez
Only highlight doc search results via mouseover if mouse has moved
## What happens
- Go to https://doc.rust-lang.org/stable/std/index.html
- Put your mouse cursor somewhere in the middle where search results will appear and then don't move the mouse
- Press 's' to focus the search box
- Type a query that brings up enough search results to go under where your mouse cursor is
- Press the down arrow
- The search result that is one below where your mouse cursor is will be highlighted.
## What I expected
When not currently using the mouse, I expect doing a search and then pressing the down arrow to always highlight the first search result immediately below the search box.
## The fix
This feels a bit hacky to me; I'm open to other solutions. This introduces a global JS var that keeps track of whether the person searching has moved their mouse after doing a search or not, and only uses the mouse position to highlight search results if the person HAS moved the mouse AFTER doing a search.
Rollup merge of #72836 - poliorcetics:std-time-os-specificities, r=shepmaster
Complete the std::time documentation to warn about the inconsistencies between OS
Fixes #48980.
I put the new documentation in `src/libstd/time.rs` at the module-level because it affects all types, even the one that are not directly system dependents if they are used with affected types, but there may be a better place for it.
Rollup merge of #72814 - RalfJung:mir-visir-terminator, r=oli-obk
remove visit_terminator_kind from MIR visitor
For some reason, we had both `visit_terminator` and `visit_terminator_kind`. In contrast, for `Statement` we just have `visit_statement`. So this cleans things up by removing `visit_terminator_kind` and porting its users to `visit_terminator`.
Rollup merge of #72804 - estebank:opaque-missing-lts-in-fn-2, r=nikomatsakis
Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position
* Suggest substituting `'static` lifetime in impl/dyn `Trait + 'static` instead of `Trait + 'static + '_`
* When `'static` is explicit, also suggest constraining argument with it
* Reduce verbosity of suggestion message and mention lifetime in label
* Tweak output for overlapping required/captured spans
* Give these errors an error code
Rollup merge of #72628 - MikailBag:array-default-tests, r=shepmaster
Add tests for 'impl Default for [T; N]'
Related: #71690.
This pull request adds two tests:
- Even it T::default() panics, no leaks occur.
- [T; 0] is Default even if T is not.
I believe at some moment `Default` impl for arrays will be rewritten to use const generics instead of macros, and these tests will help to prevent behavior changes.
Rollup merge of #72279 - RalfJung:raw-ref-macros, r=nikomatsakis
add raw_ref macros
In https://github.com/rust-lang/rust/issues/64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.
I'll create the tracking issue if we're okay moving forward with this.
Rollup merge of #71976 - mibac138:let-recovery, r=estebank
Improve diagnostics for `let x += 1`
Fixes(?) #66736
The code responsible for the `E0404` errors is [here](https://github.com/rust-lang/rust/blob/master/src/librustc_parse/parser/ty.rs#L399-L424) which I don't think can be easily modified to prevent emitting an error in one specific case. Because of this I couldn't get rid of `E0404` and instead added `E0067` along with a help message which will fix the problem.
bors [Thu, 18 Jun 2020 21:50:45 +0000 (21:50 +0000)]
Auto merge of #73446 - ecstatic-morse:issue-73431, r=pnkfelix
Make novel structural match violations not a `bug`
Fixes (on master) #73431.
Ideally, `CustomEq` would emit a strict subset of the structural match errors that are found by `search_for_structural_match_violation`, since it allows more cases due to value-based reasoning. However, const qualification is more conservative than `search_for_structural_match_violation` around associated constants, since qualification does not try to substitute type parameters.
In the long term, we should probably make const qualification work for generic associated constants, but I don't like extending its capabilities even further.