bors [Thu, 21 Jan 2021 12:18:32 +0000 (12:18 +0000)]
Auto merge of #81240 - JohnTitor:rollup-ieaz82a, r=JohnTitor
Rollup of 11 pull requests
Successful merges:
- #79655 (Add Vec visualization to understand capacity)
- #80172 (Use consistent punctuation for 'Prelude contents' docs)
- #80429 (Add regression test for mutual recursion in obligation forest)
- #80601 (Improve grammar in documentation of format strings)
- #81046 (Improve unknown external crate error)
- #81178 (Visit only terminators when removing landing pads)
- #81179 (Fix broken links with `--document-private-items` in the standard library)
- #81184 (Remove unnecessary `after_run` function)
- #81185 (Fix ICE in mir when evaluating SizeOf on unsized type)
- #81187 (Fix typo in counters.rs)
- #81219 (Document security implications of std::env::temp_dir)
fn main() {
let dst = Inline::<dyn Debug>::new(0); // line 27
}
```
these errors are printed, both for line 27 (annotated line above):
- "no function or associated item named `new` found for struct `Inline<dyn
Debug>` in the current scope"
- "the size for values of type `dyn Debug` cannot be known at compilation time"
Second error makes sense, but I'm not sure about the first one and why it's
even printed.
Finally, I'm not sure about the span passing in `const_eval`.
Yuki Okushi [Thu, 21 Jan 2021 11:04:50 +0000 (20:04 +0900)]
Rollup merge of #81179 - CPerezz:fix_interal_doc_warns, r=jyn514
Fix broken links with `--document-private-items` in the standard library
As it was suggested in #81037 `SpecFromIter` is not
in the scope and therefore we get a warning when we try to
do document private intems in `rust/library/alloc/`.
This addresses #81037 by adding the trait in the scope as ```@jyn514```
suggested and also adding an `allow(unused_imports)` flag so that
the compiler does not complain, Since the trait is not used
per se in the code, it's just needed to have properly documented
docs.
Yuki Okushi [Thu, 21 Jan 2021 11:04:43 +0000 (20:04 +0900)]
Rollup merge of #80601 - steffahn:improve_format_string_grammar, r=m-ou-se
Improve grammar in documentation of format strings
The docs previously were
* using some weird `<` and `>` around some nonterminals
* _correct me if these **did** have any meaning_
* using of a (not explicitly defined) `text` nonterminal that didn’t explicitly disallow productions containing `'{'` or `'}'`
* incorrect in not allowing for `x?` and `X?` productions of `type`
* unnecessarily ambiguous, both
* allowing `type` to be `''`, and
* using an optional `[type]`
* using inconsistent underscore/hyphenation style between `format_string` and `format_spec` vs `maybe-format`
Yuki Okushi [Thu, 21 Jan 2021 11:04:41 +0000 (20:04 +0900)]
Rollup merge of #80429 - JulianKnodt:ob_forest, r=Mark-Simulacrum
Add regression test for mutual recursion in obligation forest
Add regression test for #75860 with a slightly smaller example.
I was looking at what caused the issue and was surprised when it errors out on nightly, so I just added a regression test which should effectively close the issue, altho it would be nice to find the fix for reference.
Also I found that 80066 is not fixed by whatever fixed 75860.
Yuki Okushi [Thu, 21 Jan 2021 11:04:38 +0000 (20:04 +0900)]
Rollup merge of #79655 - pickfire:visual-vec, r=m-ou-se
Add Vec visualization to understand capacity
Visualize vector while differentiating between stack and heap.
Inspired by cheats.rs, as this is probably the first place beginner go,
they could understand stack and heap, length and capacity with this. Not
sure if adding this means we should add to other places too.
Superseeds #76066
r? `@m-ou-se`
cc `@the8472` I put back the order of the fields as it feels weird, the note already explains that the order of fields is not guaranteed
bors [Thu, 21 Jan 2021 09:14:37 +0000 (09:14 +0000)]
Auto merge of #80958 - bstrie:deptbdnums, r=KodrAus
Deprecate-in-future the constants superceded by RFC 2700
Successor to #78335, re-opened after addressing the issues tracked in #68490.
This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see #78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future).
With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696).
bors [Thu, 21 Jan 2021 05:27:30 +0000 (05:27 +0000)]
Auto merge of #81231 - jyn514:flaky-test-2, r=Mark-Simulacrum
Remove flaky test
See https://github.com/rust-lang/rust/pull/81197 for what's going on
here; this is a temporary stopgap until someone has time to review the
proper fix.
Joshua Nelson [Thu, 21 Jan 2021 00:18:23 +0000 (19:18 -0500)]
Remove flaky test
See https://github.com/rust-lang/rust/pull/81197 for what's going on
here; this is a temporary stopgap until someone has time to review the
proper fix.
Ivan Tham [Thu, 3 Dec 2020 02:56:13 +0000 (10:56 +0800)]
Add Vec visualization to understand capacity
Visualize vector while differentiating between stack and heap.
Inspired by cheats.rs, as this is probably the first place beginner go,
they could understand stack and heap, length and capacity with this. Not
sure if adding this means we should add to other places too.
bors [Wed, 20 Jan 2021 04:10:36 +0000 (04:10 +0000)]
Auto merge of #81063 - CraftSpider:jsondocck, r=jyn514
Add JsonDocCk Tool for rustdoc-json
Implements a new test system for rustdoc JSON output, jsondocck. Modeled after htmldocck, this tool reads directives in the test file and checks them against the output. These directives use JSONPath, a pair to XPath for json. This obsoletes the old strict subset tool, allowing both finer-grained control of what is tested and better errors on failure.
Not sure on the changes to Cargo.lock, I can back that out if needed.
bors [Tue, 19 Jan 2021 22:20:58 +0000 (22:20 +0000)]
Auto merge of #79578 - alexcrichton:update-waasi, r=KodrAus
std: Update wasi-libc commit of the wasm32-wasi target
This brings in an implementation of `current_dir` and `set_current_dir`
(emulation in `wasi-libc`) as well as an updated version of finding
relative paths. This also additionally updates clang to the latest
release to build wasi-libc with.
bors [Tue, 19 Jan 2021 16:42:19 +0000 (16:42 +0000)]
Auto merge of #79705 - ijackson:bufwriter-disassemble, r=m-ou-se
BufWriter: Provide into_raw_parts
If something goes wrong, one might want to unpeel the layers of nested
Writers to perform recovery actions on the underlying writer, or reuse
its resources.
`into_inner` can be used for this when the inner writer is still
working. But when the inner writer is broken, and returning errors,
`into_inner` simply gives you the error from flush, and the same
`Bufwriter` back again.
Here I provide the necessary function, which I have chosen to call
`into_raw_parts`.
I had to do something with `panicked`. Returning it to the caller as
a boolean seemed rather bare. Throwing the buffered data away in this
situation also seems unfriendly: maybe the programmer knows something
about the underlying writer and can recover somehow.
So I went for a custom Error. This may be overkill, but it does have
the nice property that a caller who actually wants to look at the
buffered data, rather than simply extracting the inner writer, will be
told by the type system if they forget to handle the panicked case.
If a caller doesn't need the buffer, it can just be discarded. That
WriterPanicked is a newtype around Vec<u8> means that hopefully the
layouts of the Ok and Err variants can be very similar, with just a
boolean discriminant. So this custom error type should compile down
to nearly no code.
*If this general idea is felt appropriate, I will open a tracking issue, etc.*
Guillaume Gomez [Tue, 19 Jan 2021 09:27:54 +0000 (10:27 +0100)]
Rollup merge of #81115 - ssomers:btree_drainy_refactor_4, r=Mark-Simulacrum
BTreeMap: prefer bulk_steal functions over specialized ones
The `steal_` functions (apart from their return value) are basically specializations of the more general `bulk_steal_` functions. This PR removes the specializations. The library/alloc benchmarks say this is never slower and up to 6% faster.
Guillaume Gomez [Tue, 19 Jan 2021 09:27:50 +0000 (10:27 +0100)]
Rollup merge of #80382 - GuillaumeGomez:search-result-tab-picking, r=Nemo157,pickfire
Improve search result tab handling
Fixes #80378.
If the current search result tab is empty, it picks the first non-empty one. If all are empty, the current one doesn't change. It can be tested with "-> string" (where only the "returned elements" tab is not empty).
bors [Tue, 19 Jan 2021 08:59:37 +0000 (08:59 +0000)]
Auto merge of #81110 - LeSeulArtichaut:fix-unused-unsafe-label, r=RalfJung
Fix `unused_unsafe` label with `unsafe_block_in_unsafe_fn
Previously, the following code:
```rust
#![feature(unsafe_block_in_unsafe_fn)]
unsafe fn foo() {
unsafe { unsf() }
}
unsafe fn unsf() {}
```
Would give the following warning:
```
warning: unnecessary `unsafe` block
--> src/lib.rs:4:5
|
4 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
```
which doesn't point out that the block is in an `unsafe fn`.
bors [Tue, 19 Jan 2021 05:58:51 +0000 (05:58 +0000)]
Auto merge of #81169 - dylni:fix-soundness-issue-for-replace-range, r=KodrAus
Fix soundness issue for `replace_range` and `range`
Fixes #81138 by only calling `start_bound` and `end_bound` once.
I also fixed the same issue for [`BTreeMap::range`](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range) and [`BTreeSet::range`](https://doc.rust-lang.org/std/collections/struct.BTreeSet.html#method.range).
bors [Tue, 19 Jan 2021 02:54:58 +0000 (02:54 +0000)]
Auto merge of #81103 - zackmdavis:comma_trail, r=davidtwco
don't suggest erroneous trailing comma after `..`
In #76612, suggestions were added for missing fields in patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the last field. This resulted in the "if you don't care about missing fields" suggestion to recommend code with a trailing comma after the field ellipsis (`..,`), which is actually not legal ("`..` must be at the end and cannot have a trailing comma")!
Incidentally, the doc-comment on `error_unmentioned_fields` was using `you_cant_use_this_field` as an example field name (presumably copy-paste inherited from the description of Issue #76077), but the present author found this confusing, because unmentioned fields aren't necessarily unusable.
The suggested code in the diff this commit introduces to `destructuring-assignment/struct_destructure_fail.stderr` doesn't work, but it didn't work beforehand, either (because of the "found reserved identifier `_`" thing), so you can't really call it a regression; it could be fixed in a separate PR.
CPerezz [Mon, 18 Jan 2021 22:47:01 +0000 (23:47 +0100)]
Fix internal rustdoc broken links
As it was suggested in #81037 `SpecFromIter` is not
in the scope and therefore (even it should fail),
we get a warning when we try do document private
intems in `rust/library/alloc/`.
This fixes #81037 by adding the trait in the scope
and also adding an `allow(unused_imports)` flag so that
the compiler does not complain, Since the trait is not used
per se in the code, it's just needed to have properly documented
docs.
bors [Mon, 18 Jan 2021 20:54:36 +0000 (20:54 +0000)]
Auto merge of #80707 - oli-obk:stability_hole_const_intrinsics, r=RalfJung
Stability oddity with const intrinsics
cc `@RalfJung`
In https://github.com/rust-lang/rust/pull/80699#discussion_r551495670 `@usbalbin` realized we accepted some intrinsics as `const` without a `#[rustc_const_(un)stable]` attribute. I did some digging, and that example works because intrinsics inherit their stability from their parents... including `#[rustc_const_(un)stable]` attributes. While we may want to fix that (not sure, wasn't there just a MCPed PR that caused this on purpose?), we definitely want tests for it, thus this PR adding tests and some fun tracing statements.
bors [Mon, 18 Jan 2021 14:36:30 +0000 (14:36 +0000)]
Auto merge of #81165 - KodrAus:rollup-s7llxis, r=KodrAus
Rollup of 12 pull requests
Successful merges:
- #81038 (Update Clippy)
- #81071 (rustc_parse_format: Fix character indices in find_skips)
- #81100 (prevent potential bug in `encode_with_shorthand`.)
- #81105 (Initialize a few variables directly)
- #81116 (ConstProp: Copy body span instead of querying it)
- #81121 (Avoid logging the whole MIR body in SimplifyCfg)
- #81123 (Update cmp.rs)
- #81125 (Add track_caller to .steal())
- #81128 (validation test: turn some const_err back into validation failures)
- #81131 (Edit rustc_middle::ty::cast docs)
- #81142 (Replace let Some(..) = with .is_some())
- #81153 (Remove unused linkcheck exceptions)
Ashley Mannix [Mon, 18 Jan 2021 11:53:26 +0000 (21:53 +1000)]
Rollup merge of #81100 - lcnr:encode_with_shorthand, r=oli-obk
prevent potential bug in `encode_with_shorthand`.
see https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Remove.20PredicateKind.20in.20favor.20of.20only.20Bin.E2.80.A6.20compiler-team.23397/near/223012169
bors [Mon, 18 Jan 2021 05:44:40 +0000 (05:44 +0000)]
Auto merge of #80865 - oliviacrain:proj_based, r=RalfJung
Use PlaceRef projection abstractions more consistently in rustc_mir
PlaceRef contains abstractions for dealing with the `projections` array. This PR uses these abstractions more consistently within the `rustc_mir` crate.
bors [Sun, 17 Jan 2021 23:44:46 +0000 (23:44 +0000)]
Auto merge of #80537 - ehuss:macos-posix-spawn-chdir, r=dtolnay
Don't use posix_spawn_file_actions_addchdir_np on macOS.
There is a bug on macOS where using `posix_spawn_file_actions_addchdir_np` with a relative executable path will cause `posix_spawnp` to return ENOENT, even though it successfully spawned the process in the given directory.
`posix_spawn_file_actions_addchdir_np` was introduced in macOS 10.15 first released in Oct 2019. I have tested macOS 10.15.7 and 11.0.1.
Example offending program:
```rust
use std::fs;
use std::os::unix::fs::PermissionsExt;
use std::process::*;
fn main() {
fs::create_dir_all("bar").unwrap();
fs::create_dir_all("foo").unwrap();
fs::write("foo/foo.sh", "#!/bin/sh\necho hello ${PWD}\n").unwrap();
let perms = fs::Permissions::from_mode(0o755);
fs::set_permissions("foo/foo.sh", perms).unwrap();
let c = Command::new("../foo/foo.sh").current_dir("bar").spawn();
eprintln!("{:?}", c);
}
```
This prints:
```
Err(Os { code: 2, kind: NotFound, message: "No such file or directory" })
hello /Users/eric/Temp/bar
```
I wanted to open this PR to get some feedback on possible solutions. Alternatives:
* Do nothing.
* Document the bug.
* Try to detect if the executable is a relative path on macOS, and avoid using `posix_spawn_file_actions_addchdir_np` only in that case.
I looked at the [XNU source code](https://opensource.apple.com/source/xnu/xnu-6153.141.1/bsd/kern/kern_exec.c.auto.html), but I didn't see anything obvious that would explain the behavior. The actual chdir succeeds, it is something else further down that fails, but I couldn't see where.
EDIT: I forgot to mention, relative exe paths with `current_dir` in general are discouraged (see #37868). I don't know if #37868 is fixable, since normalizing it would change the semantics for some platforms. Another option is to convert the executable to an absolute path with something like joining the cwd with the new cwd and the executable, but I'm uncertain about that.
bors [Sun, 17 Jan 2021 17:52:01 +0000 (17:52 +0000)]
Auto merge of #80524 - jyn514:unknown-tool-lints, r=flip1995,matthewjasper
Don't make tools responsible for checking unknown and renamed lints
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
This may interact with the unstable `tool_lint` feature, which I don't entirely understand, but it will take the burden off those external tools to add their own lint pass, which seems like a step in the right direction to me.
- Don't mark `ineffective_unstable_trait_impl` as an internal lint
- Use clippy's more advanced lint suggestions
- Deprecate the `UNKNOWN_CLIPPY_LINTS` pass (and make it a no-op)
- Say 'unknown lint `clippy::x`' instead of 'unknown lint x'
This is tested by existing clippy tests. When https://github.com/rust-lang/rust/pull/80527 merges, it will also be tested in rustdoc tests. AFAIK there is no way to test this with rustc directly.