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 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.
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.
bors [Sun, 17 Jan 2021 14:50:24 +0000 (14:50 +0000)]
Auto merge of #81113 - m-ou-se:rollup-a1unz4x, r=m-ou-se
Rollup of 13 pull requests
Successful merges:
- #79298 (correctly deal with late-bound lifetimes in anon consts)
- #80031 (resolve: Reject ambiguity built-in attr vs different built-in attr)
- #80201 (Add benchmark and fast path for BufReader::read_exact)
- #80635 (Improve diagnostics when closure doesn't meet trait bound)
- #80765 (resolve: Simplify collection of traits in scope)
- #80932 (Allow downloading LLVM on Windows and MacOS)
- #80983 (Remove is_dllimport_foreign_item definition from cg_ssa)
- #81064 (Support non-stage0 check)
- #81080 (Force vec![] to expression position only)
- #81082 (BTreeMap: clean up a few more comments)
- #81084 (Use Option::map instead of open-coding it)
- #81095 (Use Option::unwrap_or instead of open-coding it)
- #81107 (Add NonZeroUn::is_power_of_two)
Mara Bos [Sun, 17 Jan 2021 12:25:01 +0000 (12:25 +0000)]
Rollup merge of #81107 - scottmcm:nonzero-is_power_of_two, r=kennytm
Add NonZeroUn::is_power_of_two
This saves instructions on both new and old machines <https://rust.godbolt.org/z/4fjTMz>
- On the default x64 target (with no fancy instructions available) it saves a few instructions by not needing to also check for zero.
- On newer targets (with BMI1) it uses `BLSR` for super-short assembly.
This can be used for things like checks against alignments stored in `NonZeroUsize`.
Mara Bos [Sun, 17 Jan 2021 12:24:53 +0000 (12:24 +0000)]
Rollup merge of #81064 - Mark-Simulacrum:support-stage1-check, r=jyn514
Support non-stage0 check
Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).
Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.
Mara Bos [Sun, 17 Jan 2021 12:24:49 +0000 (12:24 +0000)]
Rollup merge of #80932 - jyn514:download-windows-llvm, r=Mark-Simulacrum
Allow downloading LLVM on Windows and MacOS
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Only special case MacOS when dynamic linking. Static linking works fine.
- Enable building LLVM tests
This works around the following llvm bug:
```
llvm-config: error: component libraries and shared library
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
```
I'm not sure why llvm-config thinks these are required, but to avoid
the error, this builds them anyway.
- Bump version of `download-ci-llvm-stamp`
`src/llvm-project` hasn't changed, but the generated tarball has.
This works on both MacOS and Windows! :tada: :tada: Thanks to ```@nagisa,``` ```@halkcyon,``` ```@Lokathor,``` ```@jryans,``` and ```@poliorcetics``` for helping me test!
The `if-available` check now supports all tier 1 platforms. Although only x64 apple and x64 msvc have been tested, none of the changes here are Windows or Mac specific, and I expect this to work anywhere that LLVM artifacts are uploaded to CI (i.e. the `rust-dev` component exists).
## Windows
Note that if you have an old version of MSVC build tools you'll need to update them. VS Build Tools 2019 14.28 and later are known to work. With old tools, you may see an error like the following:
```
error LNK2001: unresolved external symbol __imp___std_init_once_complete
```
Mara Bos [Sun, 17 Jan 2021 12:24:47 +0000 (12:24 +0000)]
Rollup merge of #80765 - petrochenkov:traitsinscope, r=matthewjasper
resolve: Simplify collection of traits in scope
"Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace.
Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in #80762 correction to visibilites of trait items caused some traits to not be in scope anymore.
I previously had some comments and concerns about this in https://github.com/rust-lang/rust/pull/65351.
In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits.
It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway.
The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names.
I'm not sure whether it is desirable or not, but I think it's acceptable for now.
The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope.
If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well.
---
The PR also contains a couple of pure refactorings
- Scope walk is done by using `visit_scopes` instead of a hand-rolled version.
- Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all.
Mara Bos [Sun, 17 Jan 2021 12:24:44 +0000 (12:24 +0000)]
Rollup merge of #80635 - sexxi-goose:use-place-instead-of-symbol, r=nikomatsakis`
Improve diagnostics when closure doesn't meet trait bound
Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled.
Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
Mara Bos [Sun, 17 Jan 2021 12:24:39 +0000 (12:24 +0000)]
Rollup merge of #79298 - lcnr:new-elysium, r=matthewjasper
correctly deal with late-bound lifetimes in anon consts
adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }
fn test<'a>() {
let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.
r? ```@matthewjasper``` cc ```@varkor``` ```@eddyb```
projects / rust.git / log