bors [Tue, 16 Mar 2021 19:19:06 +0000 (19:19 +0000)]
Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled
This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments
To do so, we
- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code
bors [Tue, 16 Mar 2021 16:37:43 +0000 (16:37 +0000)]
Auto merge of #83199 - JohnTitor:rollup-zrfk94a, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81822 (Added `try_exists()` method to `std::path::Path`)
- #83072 (Update `Vec` docs)
- #83077 (rustdoc: reduce GC work during search)
- #83091 (Constify `copy` related functions)
- #83156 (Fall-back to sans-serif if Arial is not available)
- #83157 (No background for code in portability snippets)
- #83160 (Deprecate RustcEncodable and RustcDecodable.)
- #83162 (Specify *.woff2 files as binary)
- #83172 (More informative diagnotic from `x.py test` attempt atop beta checkout)
- #83196 (Use delay_span_bug instead of panic in layout_scalar_valid_range)
Yuki Okushi [Tue, 16 Mar 2021 14:54:03 +0000 (23:54 +0900)]
Rollup merge of #83196 - tmiasko:valid-range-delay-span-bug, r=oli-obk
Use delay_span_bug instead of panic in layout_scalar_valid_range
#83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Yuki Okushi [Tue, 16 Mar 2021 14:54:02 +0000 (23:54 +0900)]
Rollup merge of #83172 - pnkfelix:bootstrap-tell-me-what-to-do-about-tidy-on-beta, r=Mark-Simulacrum
More informative diagnotic from `x.py test` attempt atop beta checkout
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
Yuki Okushi [Tue, 16 Mar 2021 14:53:59 +0000 (23:53 +0900)]
Rollup merge of #83157 - nagisa:nagisa/portability-background, r=GuillaumeGomez
No background for code in portability snippets
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
![Listing of items in a module with some portability snippets attached to some of the items (light theme). The portability snippet has a light blue background and all of the text in it, monospace or not, is the same colour – black](https://user-images.githubusercontent.com/679122/111196363-1900f500-85b5-11eb-8f97-e283c59002a4.png)
![Listing of items in a module with some portability snippets attached to some of the items (dark theme). The portability snippet has a light blue background and all of the text in it, monospace or not, is the same colour – black](https://user-images.githubusercontent.com/679122/111196366-19998b80-85b5-11eb-9914-4d14d9d13ed3.png)
There should be no observable changes to the ayu theme.
Yuki Okushi [Tue, 16 Mar 2021 14:53:58 +0000 (23:53 +0900)]
Rollup merge of #83156 - nagisa:nagisa/sans-serif-please, r=GuillaumeGomez
Fall-back to sans-serif if Arial is not available
Otherwise on systems where Arial is not available the UA will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
Yuki Okushi [Tue, 16 Mar 2021 14:53:52 +0000 (23:53 +0900)]
Rollup merge of #81822 - Kixunil:path_try_exists, r=kennytm
Added `try_exists()` method to `std::path::Path`
This method is similar to the existing `exists()` method, except it
doesn't silently ignore the errors, leading to less error-prone code.
This change intentionally does NOT touch the documentation of `exists()`
nor recommend people to use this method while it's unstable.
Such changes are reserved for stabilization to prevent confusing people.
Apart from that it avoids conflicts with #80979.
`@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil)
bors [Tue, 16 Mar 2021 10:05:46 +0000 (10:05 +0000)]
Auto merge of #82838 - Amanieu:rustdoc_asm, r=nagisa
Allow rustdoc to handle asm! of foreign architectures
This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one.
bors [Tue, 16 Mar 2021 04:24:48 +0000 (04:24 +0000)]
Auto merge of #82898 - oli-obk:tait_🧊, r=nikomatsakis
Add a `min_type_alias_impl_trait` feature gate
This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
Tomasz Miąsko [Tue, 16 Mar 2021 00:00:00 +0000 (00:00 +0000)]
Use delay_span_bug instead of panic in layout_scalar_valid_range
83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
bors [Mon, 15 Mar 2021 18:32:10 +0000 (18:32 +0000)]
Auto merge of #83121 - the8472:env-rwlock-2, r=joshtriplett
use RWlock when accessing os::env (take 2)
This reverts commit acdca316c3d42299d31c1b47eb792006ffdfc29c (#82877) i.e. redoes #81850 since the invalid unlock attempts in the child process have been fixed in #82949
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
Otherwise on systems where Arial is not available the system will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
Dylan DPC [Mon, 15 Mar 2021 15:22:58 +0000 (16:22 +0100)]
Rollup merge of #83132 - Aaron1011:fix/incr-cache-dummy, r=estebank
Don't encode file information for span with a dummy location
Fixes #83112
The location information for a dummy span isn't real, so don't encode
it. This brings the incr comp cache code into line with the Span
`StableHash` impl, which doesn't hash the location information for dummy
spans.
Previously, we would attempt to load the 'original' file from a dummy
span - if the file id changed (e.g. due to being moved on disk), we would get an
ICE, since the Span was still valid due to its hash being unchanged.
Dylan DPC [Mon, 15 Mar 2021 15:22:57 +0000 (16:22 +0100)]
Rollup merge of #83127 - Aaron1011:time-macros-impl-warn, r=petrochenkov
Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.
This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.
I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.
When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
Dylan DPC [Mon, 15 Mar 2021 15:22:52 +0000 (16:22 +0100)]
Rollup merge of #83098 - camelid:more-doc-attr-check, r=davidtwco
Find more invalid doc attributes
- Lint on `#[doc(123)]`, `#[doc("hello")]`, etc.
- Lint every attribute; e.g., will now report two warnings for `#[doc(foo, bar)]`
- Add hyphen to "crate level"
- Display paths like `#[doc(foo::bar)]` correctly instead of as an empty string
bors [Mon, 15 Mar 2021 08:49:25 +0000 (08:49 +0000)]
Auto merge of #82999 - cuviper:rustc-rayon-0.3.1, r=Mark-Simulacrum
Update to rustc-rayon 0.3.1
This pulls in rust-lang/rustc-rayon#8 to fix #81425. (h/t `@ammaraskar)`
That revealed weak constraints on `rustc_arena::DropArena`, because its
`DropType` was holding type-erased raw pointers to generic `T`. We can
implement `Send` for `DropType` (under `cfg(parallel_compiler)`) by
requiring all `T: Send` before they're type-erased.
bors [Mon, 15 Mar 2021 06:20:24 +0000 (06:20 +0000)]
Auto merge of #83074 - Aaron1011:new-sort-fix, r=jackh726
Avoid sorting predicates by `DefId`
Fixes issue #82920
Even if an item does not change between compilation sessions, it may end
up with a different `DefId`, since inserting/deleting an item affects
the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash`
in the incremental compilation system, which is stable in the face of
changes to unrelated items.
In particular, the query system will consider the inputs to a query to
be unchanged if any `DefId`s in the inputs have their `DefPathHash`es
unchanged. Queries are pure functions, so the query result should be
unchanged if the query inputs are unchanged.
Unfortunately, it's possible to inadvertantly make a query result
incorrectly change across compilations, by relying on the specific value
of a `DefId`. Specifically, if the query result is a slice that gets
sorted by `DefId`, the precise order will depend on how the `DefId`s got
assigned in a particular compilation session. If some definitions end up
with different `DefId`s (but the same `DefPathHash`es) in a subsequent
compilation session, we will end up re-computing a *different* value for
the query, even though the query system expects the result to unchanged
due to the unchanged inputs.
It turns out that we have been sorting the predicates computed during
`astconv` by their `DefId`. These predicates make their way into the
`super_predicates_that_define_assoc_type`, which ends up getting used to
compute the vtables of trait objects. This, re-ordering these predicates
between compilation sessions can lead to undefined behavior at runtime -
the query system will re-use code built with a *differently ordered*
vtable, resulting in the wrong method being invoked at runtime.
This PR avoids sorting by `DefId` in `astconv`, fixing the
miscompilation. However, it's possible that other instances of this
issue exist - they could also be easily introduced in the future.
To fully fix this issue, we should
1. Turn on `-Z incremental-verify-ich` by default. This will cause the
compiler to ICE whenver an 'unchanged' query result changes between
compilation sessions, instead of causing a miscompilation.
2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it
difficult to introduce ICEs in the first place.
Aaron Hill [Sun, 14 Mar 2021 20:55:59 +0000 (16:55 -0400)]
Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.
This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.
I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.
When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
Aaron Hill [Sun, 14 Mar 2021 23:03:16 +0000 (19:03 -0400)]
Don't encode file information for span with a dummy location
Fixes #83112
The location information for a dummy span isn't real, so don't encode
it. This brings the incr comp cache code into line with the Span
`StableHash` impl, which doesn't hash the location information for dummy
spans.
Previously, we would attempt to load the 'original' file from a dummy
span - if the file id changed (e.g. due to being moved on disk), we would get an
ICE, since the Span was still valid due to its hash being unchanged.
bors [Sun, 14 Mar 2021 04:09:02 +0000 (04:09 +0000)]
Auto merge of #83105 - JohnTitor:rollup-tqpm8pb, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81465 (Add documentation about formatting `Duration` values)
- #82121 (Implement Extend and FromIterator for OsString)
- #82617 (Document `everybody_loops`)
- #82789 (Get with field index from pattern slice instead of directly indexing)
- #82798 (Rename `rustdoc` to `rustdoc::all`)
- #82804 (std: Fix a bug on the wasm32-wasi target opening files)
- #82943 (Demonstrate best practice for feeding stdin of a child processes)
- #83066 (Add `reverse` search alias for Iterator::rev())
- #83070 (Update cargo)
- #83081 (Fix panic message of `assert_failed_inner`)
Yuki Okushi [Sun, 14 Mar 2021 04:07:36 +0000 (13:07 +0900)]
Rollup merge of #83070 - ehuss:update-cargo, r=ehuss
Update cargo
7 commits in 970bc67c3775781b9708c8a36893576b9459c64a..32da9eaa5de5be241cf8096ca6b749a157194f77
2021-03-07 18:09:40 +0000 to 2021-03-13 01:18:40 +0000
- Fix logic for determining prefer-dynamic for a dylib. (rust-lang/cargo#9252)
- Fix issue with filtering exclusive target dependencies. (rust-lang/cargo#9255)
- Update pkgid-spec docs. (rust-lang/cargo#9249)
- Wordsmith the edition documentation a bit more (rust-lang/cargo#9233)
- Package ID specification urls must contain a host (rust-lang/cargo#9188)
- Add documentation for JSON message_path. (rust-lang/cargo#9247)
- Fix filter_platform to run on targets other than x86. (rust-lang/cargo#9246)
Yuki Okushi [Sun, 14 Mar 2021 04:07:34 +0000 (13:07 +0900)]
Rollup merge of #82943 - kornelski:threadstdio, r=joshtriplett
Demonstrate best practice for feeding stdin of a child processes
Documentation change.
It's possible to create a deadlock with stdin/stdout I/O on a single thread:
* the child process may fill its stdout buffer, and have to wait for the parent process to read it,
* but the parent process may be waiting until its stdin write finishes before reading the stdout.
Therefore, the parent process should use separate threads for writing and reading.
These examples are not deadlocking in practice, because they use short strings, but I think it's better to demonstrate code that works even for long writes. The problem is non-obvious and tricky to debug (it seems that even libstd has a similar issue: #45572).
This also demonstrates how to use stdio with threads: it's not obvious that `.take()` can be used to avoid fighting with the borrow checker.
Yuki Okushi [Sun, 14 Mar 2021 04:07:33 +0000 (13:07 +0900)]
Rollup merge of #82804 - alexcrichton:fix-wasi, r=pnkfelix
std: Fix a bug on the wasm32-wasi target opening files
This commit fixes an issue pointed out in #82758 where LTO changed the
behavior of a program. It turns out that LTO was not at fault here, it
simply uncovered an existing bug. The bindings to
`__wasilibc_find_relpath` assumed that the relative portion of the path
returned was always contained within thee input `buf` we passed in. This
isn't actually the case, however, and sometimes the relative portion of
the path may reference a sub-portion of the input string itself.
The fix here is to use the relative path pointer coming out of
`__wasilibc_find_relpath` as the source of truth. The `buf` used for
local storage is discarded in this function and the relative path is
copied out unconditionally. We might be able to get away with some
`Cow`-like business or such to avoid the extra allocation, but for now
this is probably the easiest patch to fix the original issue.