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.
Jake Degen [Thu, 18 Jun 2020 12:48:37 +0000 (08:48 -0400)]
Added tooltip for should_panic code examples.
Previously, compile_fail and ignore code examples displayed a tooltip
indicating this in the documentation. This tooltip has now also been
added to should_panic examples.
bors [Wed, 17 Jun 2020 11:30:56 +0000 (11:30 +0000)]
Auto merge of #69890 - lenary:lenary/riscv-frame-pointers, r=hanna-kruppe,Mark-Simulacrum
[RISC-V] Do not force frame pointers
We have been seeing some very inefficient code that went away when using
`-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at
`-Oz` was compiled into a function which consisted entirely of saving
registers to the stack, then using the frame pointer to restore the same
registers (without any instructions between the prolog and epilog).
The RISC-V LLVM backend supports frame pointer elimination, so it makes
sense to allow this to happen when using Rust. It's not clear to me that
frame pointers have ever been required in the general case.
In rust-lang/rust#61675 it was pointed out that this made reassembling
stack traces easier, which is true, but there is a code generation
option for forcing frame pointers, and I feel the default should not be
to require frame pointers, given it demonstrably makes code size worse
(around 10% in some embedded applications).
The kinds of targets mentioned in rust-lang/rust#61675 are popular, but
should not dictate that code generation should be worse for all RISC-V
targets, especially as there is a way to use CFI information to
reconstruct the stack when the frame pointer is eliminated. It is also
a misconception that `fp` is always used for the frame pointer. `fp` is
an ABI name for `x8` (aka `s0`), and if no frame pointer is required,
`x8` may be used for other callee-saved values.
---
I am partly posting this to get feedback from @fintelia who introduced the change to require frame pointers, and @hanna-kruppe who had issues with the original PR. I would understand if we wanted to remove this setting on only a subset of RISC-V targets, but my preference would be to remove this setting everywhere.
There are more details on the code size savings seen in Tock here: https://github.com/tock/tock/pull/1660
bors [Tue, 16 Jun 2020 14:58:14 +0000 (14:58 +0000)]
Auto merge of #73402 - Dylan-DPC:rollup-8udzpfu, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #73237 (Check for overflow in DroplessArena and align returned memory)
- #73339 (Don't run generator transform when there's a TyErr)
- #73372 (Re-order correctly the sections in the sidebar)
- #73373 (Use track caller for bug! macro)
- #73380 (Add more info to `x.py build --help` on default value for `-j JOBS`.)
- #73381 (Fix typo in docs of std::mem)
- #73389 (Use `Ipv4Addr::from<[u8; 4]>` when possible)
- #73400 (Fix forge-platform-support URL)
Dylan DPC [Tue, 16 Jun 2020 13:08:40 +0000 (15:08 +0200)]
Rollup merge of #73372 - GuillaumeGomez:re-order-sidebar-sections, r=kinnison
Re-order correctly the sections in the sidebar
Before that, "trait implementations" and "implementors" titles in the sidebar were before "methods" for example. Which wasn't logical considering that the two sections come after in the "content".
Dylan DPC [Tue, 16 Jun 2020 13:08:37 +0000 (15:08 +0200)]
Rollup merge of #73339 - jonas-schievink:unbug, r=estebank
Don't run generator transform when there's a TyErr
Not sure if this might cause any problems later on, but we shouldn't be hitting codegen or const eval for the produced MIR anyways, so it should be fine.
cc https://github.com/rust-lang/rust/issues/72685#issuecomment-643749020
Dylan DPC [Tue, 16 Jun 2020 13:08:35 +0000 (15:08 +0200)]
Rollup merge of #73237 - tmiasko:arena, r=nnethercote
Check for overflow in DroplessArena and align returned memory
* Check for overflow when calculating the slice start & end position.
* Align the pointer obtained from the allocator, ensuring that it
satisfies user requested alignment (the allocator is only asked for
layout compatible with u8 slice).
* Remove an incorrect assertion from DroplessArena::align.
* Avoid forming references to an uninitialized memory in DroplessArena.
bors [Tue, 16 Jun 2020 11:26:45 +0000 (11:26 +0000)]
Auto merge of #73285 - Mark-Simulacrum:clippy-fail, r=RalfJung,oli-obk
Avoid prematurely recording toolstates
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in #73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
bors [Tue, 16 Jun 2020 06:22:52 +0000 (06:22 +0000)]
Auto merge of #72962 - lcnr:ObligationCause-lrc, r=ecstatic-morse
store `ObligationCause` on the heap
Stores `ObligationCause` on the heap using an `Rc`.
This PR trades off some transient memory allocations to reduce the size of–and thus the number of instructions required to memcpy–a few widely used data structures in trait solving.
Mark Rousskov [Fri, 12 Jun 2020 15:06:26 +0000 (11:06 -0400)]
Avoid prematurely recording toolstates
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in 73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
Esteban Küber [Mon, 15 Jun 2020 04:36:25 +0000 (21:36 -0700)]
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.
bors [Mon, 15 Jun 2020 15:21:45 +0000 (15:21 +0000)]
Auto merge of #72357 - ortem:new-dbg-pretty-printers, r=pnkfelix
Implement new gdb/lldb pretty-printers
Reopened #60826
This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters).
The current state of lldb pretty-printers is poor, because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support, I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill, so I got rid of it.
The new pretty-printers have to support all types supported by current pretty-printers, and also support `Rc`, `Arc`, `Cell`, `Ref`, `RefCell`, `RefMut`, `HashMap`, `HashSet`.
bors [Mon, 15 Jun 2020 11:39:23 +0000 (11:39 +0000)]
Auto merge of #73369 - RalfJung:rollup-hl8g9zf, r=RalfJung
Rollup of 10 pull requests
Successful merges:
- #72707 (Use min_specialization in the remaining rustc crates)
- #72740 (On recursive ADT, provide indirection structured suggestion)
- #72879 (Miri: avoid tracking current location three times)
- #72938 (Stabilize Option::zip)
- #73086 (Rename "cyclone" to "apple-a7" per changes in upstream LLVM)
- #73104 (Example about explicit mutex dropping)
- #73139 (Add methods to go from a nul-terminated Vec<u8> to a CString)
- #73296 (Remove vestigial CI job msvc-aux.)
- #73304 (Revert heterogeneous SocketAddr PartialEq impls)
- #73331 (extend network support for HermitCore)
That compiles as of stable 1.44.0 but fails in beta with:
```console
error[E0284]: type annotations needed
--> src/main.rs:3:41
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
| ^^^^^ cannot infer type for type parameter `F` declared on the associated function `parse`
|
= note: cannot satisfy `<_ as std::str::FromStr>::Err == _`
help: consider specifying the type argument in the method call
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse::<F>().unwrap());
|
```
Ralf Jung [Mon, 15 Jun 2020 10:01:11 +0000 (12:01 +0200)]
Rollup merge of #73296 - ehuss:remove-msvc-aux, r=Mark-Simulacrum
Remove vestigial CI job msvc-aux.
This CI job isn't really doing anything, so it seems prudent to remove it.
For some history:
* This was introduced in #48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things:
* tidy
* src/test/pretty
* src/test/run-pass/pretty
* src/test/run-fail/pretty
* src/test/run-pass-valgrind/pretty
* src/test/run-pass-fulldeps/pretty
* src/test/run-fail-fulldeps/pretty
* Tidy was removed in #60777.
* run-pass and run-pass-fulldeps moved to UI in #63029
* src/test/pretty removed in #58140
* src/test/run-fail moved to UI in #71185
* run-fail-fulldeps removed in #51285
Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here.
I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
Ralf Jung [Mon, 15 Jun 2020 10:01:07 +0000 (12:01 +0200)]
Rollup merge of #73104 - poliorcetics:explicit-mutex-drop-example, r=dtolnay
Example about explicit mutex dropping
Fixes #67457.
Following the remarks made in #73074, I added an example on the main `Mutex` type, with a situation where there is mutable data and a computation result.
In my testing it is effectively needed to explicitly drop the lock, else it deadlocks.
r? @dtolnay because you were the one to review the previous PR.
Ralf Jung [Mon, 15 Jun 2020 10:01:05 +0000 (12:01 +0200)]
Rollup merge of #73086 - trevyn:apple-a7, r=nikic
Rename "cyclone" to "apple-a7" per changes in upstream LLVM
It looks like they intended to keep "cyclone" as a legacy option, but removed it from the list of subtarget features. This created a flood of warnings when targeting aarch64-apple-ios, and probably also created incorrectly optimized artifacts.
Ralf Jung [Mon, 15 Jun 2020 10:01:01 +0000 (12:01 +0200)]
Rollup merge of #72879 - RalfJung:miri-tctx-at, r=oli-obk
Miri: avoid tracking current location three times
Miri tracks the current instruction to execute in the call stack, but it also additionally has two `TyCtxtAt` that carry a `Span` that also tracks the current instruction. That is quite silly, so this PR uses `TyCtxt` instead, and then uses a method for computing the current span when a `TyCtxtAt` is needed. Having less redundant (semi-)global state seems like a good improvement to me. :D
To keep the ConstProp errors the same, I had to add the option to `error_to_const_error` to overwrite the span. Also for some reason this changes cycle errors a bit -- not sure if we are now better or worse as giving those queries the right span. (It is unfortunately quite easy to accidentally use `DUMMY_SP` by calling the query on a `TyCtxt` instead of a `TyCtxtAt`.)
projects / rust.git / log