Yuki Okushi [Fri, 23 Oct 2020 09:26:40 +0000 (18:26 +0900)]
Rollup merge of #78255 - dtolnay:match, r=lcnr
Reduce diagram mess in 'match arms have incompatible types' error
I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span.
This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline.
**Before:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| _________________________-</b>
<b>121 | |</b> Transform::Function(t) => {
<b>| _|_______________________________________-</b>
<b>122 | | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | | |</b> futures::stream::iter(match v {
<b>124 | | |</b> Err(e) => {
<b>... | |</b>
<b>139 | | |</b> .compat();
<b>140 | | |</b> }
<b>| |_|_____________- this is found to be of type `()`</b>
<b>141 | |</b> Transform::Task(t) => t
<b>| _|___________________________________^</b>
<b>142 | | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | | |</b> .forward(output)
<b>144 | | |</b> .map(|_| debug!("Finished"))
<b>145 | | |</b> .compat(),
<b>| |_|_________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>146 | |</b> };
<b>| |_________- `match` arms have incompatible types</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
**After:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| --------------- `match` arms have incompatible types</b>
<b>121 |</b> Transform::Function(t) => {
<b>| _________________________________________-</b>
<b>122 | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | |</b> futures::stream::iter(match v {
<b>124 | |</b> Err(e) => {
<b>... |</b>
<b>139 | |</b> .compat();
<b>140 | |</b> }
<b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b> Transform::Task(t) => t
<b>| _____________________________________^</b>
<b>142 | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | |</b> .forward(output)
<b>144 | |</b> .map(|_| debug!("Finished"))
<b>145 | |</b> .compat(),
<b>| |___________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
Yuki Okushi [Fri, 23 Oct 2020 09:26:32 +0000 (18:26 +0900)]
Rollup merge of #78153 - est31:downloaded_llvm_maybe_sync, r=Mark-Simulacrum
Sync LLVM submodule if it has been initialized
Since having enabled the download-ci-llvm option,
and having rebased on top of #76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
Yuki Okushi [Fri, 23 Oct 2020 09:26:28 +0000 (18:26 +0900)]
Rollup merge of #78098 - camelid:fixup-docs, r=steveklabnik
Clean up and improve some docs
* compiler docs
* Don't format list as part of a code block
* Clean up some other formatting
* rustdoc book
* Update CommonMark spec version to latest (0.28 -> 0.29)
* Clean up some various wording and formatting
Yuki Okushi [Fri, 23 Oct 2020 09:26:26 +0000 (18:26 +0900)]
Rollup merge of #77969 - ryan-scott-dev:bigo-notation-consistency, r=m-ou-se
Doc formating consistency between slice sort and sort_unstable, and big O notation consistency
Updated documentation for slice sorting methods to be consistent between stable and unstable versions, which just ended up being minor formatting differences.
I also went through and updated any doc comments with big O notation to be consistent with #74010 by italicizing them rather than having them in a code block.
Yuki Okushi [Fri, 23 Oct 2020 09:26:24 +0000 (18:26 +0900)]
Rollup merge of #77920 - ayazhafiz:i/mut-ident-spacing, r=jyn514
Avoid extraneous space between visibility kw and ident for statics
Today, given a static like `static mut FOO: usize = 1`, rustdoc would
emit `static mut FOO: usize = 1`, as it emits both the mutability kw
with a space and reserves a space after the mutability kw. This patch
fixes that misformatting.
This patch also adds some tests for emit of other statics, as I could
not find an existing test devoted to statics.
Yuki Okushi [Fri, 23 Oct 2020 09:26:20 +0000 (18:26 +0900)]
Rollup merge of #77890 - gilescope:welformed-json-output-from-libtest, r=KodrAus
Fixing escaping to ensure generation of welformed json.
doc tests' json name have a filename in them. When json test output is asked for on windows currently produces invalid json.
Tracking issue for json test output: #49359
Yuki Okushi [Fri, 23 Oct 2020 09:26:18 +0000 (18:26 +0900)]
Rollup merge of #77488 - varkor:repr128-incomplete_features, r=jonas-schievink
Mark `repr128` as `incomplete_features`
As mentioned in https://github.com/rust-lang/rust/issues/56071 and noticed in https://github.com/rust-lang/rust/issues/77457, `repr(u128)` and `repr(i128)` do not work properly due to lack of LLVM support. We should thus warn users trying to use the feature that they may encounter ICEs when using it.
Yuki Okushi [Fri, 23 Oct 2020 09:26:14 +0000 (18:26 +0900)]
Rollup merge of #77268 - follower:patch-3, r=jyn514
Link to "Contributing to Rust" rather than "Getting Started".
Change to link to "Contributing to Rust" chapter of `rustc` Dev Guide, primarily on the basis that:
* The GitHub "first contribution" Issue "pop-up" says "Be sure to review the [contributing guidelines] and [code of conduct]" and links to this file.
* The "Bug Report" section _seems_ to restrict itself to if "a compiler error message [told] you to come here".
* The previous content of `CONTRIBUTING.md` now lives in the "Contributing to Rust" chapter.
When/if the guide/"Getting Started" section gets revised to not be `rustc`-specific, the choice of linked chapter could be updated.
In the meantime this prevents leading first time contributors into a confusing cul de sac.
_[I wasn't planning to make a PR for this until discussion in #77215 concluded but the discovery that the "first issue" pop-up also links to this document IMO makes it a higher priority to make the link useful sooner rather than later.]_
bors [Thu, 22 Oct 2020 14:40:20 +0000 (14:40 +0000)]
Auto merge of #77720 - matthewjasper:fix-trait-ices, r=nikomatsakis
Fix trait solving ICEs
- Selection candidates that are known to be applicable are preferred
over candidates that are not.
- Don't ICE if a projection/object candidate is no longer applicable
(this can happen due to cycles in normalization)
- Normalize supertraits when finding trait object candidates
bors [Thu, 22 Oct 2020 12:24:55 +0000 (12:24 +0000)]
Auto merge of #77871 - Julian-Wollersberger:less-query-context, r=oli-obk
Make fewer types generic over QueryContext
While trying to refactor `rustc_query_system::query::QueryContext` to make it dyn-safe, I noticed some smaller things:
* QueryConfig doesn't need to be generic over QueryContext
* ~~The `kind` field on QueryJobId is unused~~
* Some unnecessary where clauses
* Many types in `job.rs` where generic over `QueryContext` but only needed `QueryContext::Query`.
If handle_cycle_error() could be refactored to not take `error: CycleError<CTX::Query>`, all those bounds could be removed as well.
Changing `find_cycle_in_stack()` in job.rs to not take a `tcx` argument is the only functional change here. Everything else is just updating type signatures. (aka compile-error driven development ^^)
~~Currently there is a weird bug where memory usage suddenly skyrockets when running UI tests. I'll investigate that tomorrow.
A perf run probably won't make sense before that is fixed.~~
EDIT: `kind` actually is used by `Eq`, and re-adding it fixed the memory issue.
bors [Thu, 22 Oct 2020 01:35:05 +0000 (01:35 +0000)]
Auto merge of #78212 - JohnTitor:rollup-j5r6xuy, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #77420 (Unify const-checking structured errors for `&mut` and `&raw mut`)
- #77554 (Support signed integers and `char` in v0 mangling)
- #77976 (Mark inout asm! operands as used in liveness pass)
- #78009 (Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling)
- #78084 (Greatly improve display for small mobile devices screens)
- #78155 (Fix two small issues in compiler/rustc_lint/src/types.rs)
- #78156 (Fixed build failure of `rustfmt`)
- #78172 (Add test case for #77062)
- #78188 (Add tracking issue number for pin_static_ref)
- #78200 (Add `ControlFlow::is_{break,continue}` methods)
Camelid [Mon, 19 Oct 2020 04:54:10 +0000 (21:54 -0700)]
Clean up and improve some docs
* compiler docs
* Don't format list as part of a code block
* Clean up some other formatting
* rustdoc book
* Update CommonMark spec version to latest (0.28 -> 0.29)
* Clean up some various wording and formatting
Yuki Okushi [Thu, 22 Oct 2020 00:45:35 +0000 (09:45 +0900)]
Rollup merge of #78009 - nielx:fix/CMAKE_SYSTEM_NAME, r=Mark-Simulacrum
Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
Yuki Okushi [Thu, 22 Oct 2020 00:45:33 +0000 (09:45 +0900)]
Rollup merge of #77976 - oliviacrain:issue-77915-fix, r=matthewjasper
Mark inout asm! operands as used in liveness pass
Variables used in `inout` operands in inline assembly (that is, they're used as both input and output to some arbitrary assembly instruction) are being marked as read and written, but are not marked as being used in the RWU table during the liveness pass. This can result in such expressions triggering an unused variable lint warning. This is incorrect behavior- reads without uses are currently only used for compound assignments. We conservatively assume that an `inout` operand is being read and used in the context of the assembly instruction.
Yuki Okushi [Thu, 22 Oct 2020 00:45:31 +0000 (09:45 +0900)]
Rollup merge of #77554 - varkor:mangle-int-char, r=eddyb
Support signed integers and `char` in v0 mangling
Likely we want more tests, to check the output is correct too: however, I wasn't sure what kind of test we needed, so I just added one similar to that added in https://github.com/rust-lang/rust/pull/77452 for now.
bors [Wed, 21 Oct 2020 20:23:26 +0000 (20:23 +0000)]
Auto merge of #78077 - petrochenkov:qvis, r=davidtwco
Calculate visibilities once in resolve
Then use them through a query based on resolver outputs.
Item visibilities were previously calculated in three places - initially in `rustc_resolve`, then in `rustc_privacy` during type privacy checkin, and then in `rustc_metadata` during metadata encoding.
The visibility logic is not entirely trivial, especially for things like constructors or enum variants, and all of it was duplicated.
This PR deduplicates all the visibility calculations, visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`.
(This query existed previously, but only worked for other crates.)
Some special cases (e.g. visibilities for closure types, which are needed for type privacy checking) are not processed in resolve, but deferred and performed directly in the query instead.
Matthew Jasper [Thu, 8 Oct 2020 20:49:36 +0000 (21:49 +0100)]
Fix ICE from projection cycle
Cycles in normalization can cause evaluations to change from Unknown to
Err. This means that some selection that were applicable no longer are.
To avoid this:
* Selection candidates that are known to be applicable are prefered
over candidates that are not.
* We don't ICE if a candidate is no longer applicable.
bors [Wed, 21 Oct 2020 15:03:14 +0000 (15:03 +0000)]
Auto merge of #77250 - Aaron1011:feature/flat-token-collection, r=petrochenkov
Rewrite `collect_tokens` implementations to use a flattened buffer
Instead of trying to collect tokens at each depth, we 'flatten' the
stream as we go allong, pushing open/close delimiters to our buffer
just like regular tokens. One capturing is complete, we reconstruct a
nested `TokenTree::Delimited` structure, producing a normal
`TokenStream`.
The reconstructed `TokenStream` is not created immediately - instead, it is
produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This
closure stores a clone of the original `TokenCursor`, plus a record of the
number of calls to `next()/next_desugared()`. This is sufficient to reconstruct
the tokenstream seen by the callback without storing any additional state. If
the tokenstream is never used (e.g. when a captured `macro_rules!` argument is
never passed to a proc macro), we never actually create a `TokenStream`.
This implementation has a number of advantages over the previous one:
* It is significantly simpler, with no edge cases around capturing the
start/end of a delimited group.
* It can be easily extended to allow replacing tokens an an arbitrary
'depth' by just using `Vec::splice` at the proper position. This is
important for PR #76130, which requires us to track information about
attributes along with tokens.
* The lazy approach to `TokenStream` construction allows us to easily
parse an AST struct, and then decide after the fact whether we need a
`TokenStream`. This will be useful when we start collecting tokens for
`Attribute` - we can discard the `LazyTokenStream` if the parsed
attribute doesn't need tokens (e.g. is a builtin attribute).
The performance impact seems to be neglibile (see
https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a
small slowdown on a few benchmarks, but it only rises above 1% for incremental
builds, where it represents a larger fraction of the much smaller instruction
count. There a ~1% speedup on a few other incremental benchmarks - my guess is
that the speedups and slowdowns will usually cancel out in practice.
Yuki Okushi [Wed, 21 Oct 2020 04:59:43 +0000 (13:59 +0900)]
Rollup merge of #78101 - RalfJung:foreign-static, r=oli-obk
fix static_ptr_ty for foreign statics
Cc https://github.com/rust-lang/rust/issues/74840
This does not fix that issue but fixes a problem in `static_ptr_ty` that we noticed while discussing that issue. I also added and updated a few comments. The one about `internal` locals being ignored does not seem to have been true [even in the commit that introduced it](https://github.com/rust-lang/rust/pull/44700/files#diff-ae2f3c7e2f9744f7ef43e96072b10e98d4e3fe74a3a399a3ad8a810fbe56c520R139).
Yuki Okushi [Wed, 21 Oct 2020 04:59:39 +0000 (13:59 +0900)]
Rollup merge of #78063 - camelid:improve-cannot-multiply-error, r=estebank
Improve wording of "cannot multiply" type error
For example, if you had this code:
fn foo(x: i32, y: f32) -> f32 {
x * y
}
You would get this error:
error[E0277]: cannot multiply `f32` to `i32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
However, that's not usually how people describe multiplication. People
usually describe multiplication like how the division error words it:
error[E0277]: cannot divide `i32` by `f32`
--> src/lib.rs:2:7
|
2 | x / y
| ^ no implementation for `i32 / f32`
|
= help: the trait `Div<f32>` is not implemented for `i32`
So that's what this change does. It changes this:
error[E0277]: cannot multiply `f32` to `i32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
To this:
error[E0277]: cannot multiply `i32` by `f32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
Yuki Okushi [Wed, 21 Oct 2020 04:59:29 +0000 (13:59 +0900)]
Rollup merge of #77726 - fusion-engineering-forks:static-pin, r=dtolnay
Add Pin::static_ref, static_mut.
This adds `Pin::static_ref` and `Pin::static_mut`, which convert a static reference to a pinned static reference.
Static references are effectively already pinned, as what they refer to has to live forever and can never be moved.
---
Context: I want to update the `sys` and `sys_common` mutexes/rwlocks/condvars to use `Pin<&self>` in their functions, instead of only warning in the unsafety comments that they may not be moved. That should make them a little bit less dangerous to use. Putting such an object in a `static` (e.g. through `sys_common::StaticMutex`) fulfills the requirements about never moving it, but right now there's no safe way to get a `Pin<&T>` to a `static`. This solves that.
bors [Tue, 20 Oct 2020 21:27:47 +0000 (21:27 +0000)]
Auto merge of #78162 - GuillaumeGomez:rollup-6a4qiqu, r=GuillaumeGomez
Rollup of 9 pull requests
Successful merges:
- #78046 (Add codegen test for issue #73827)
- #78061 (Optimize const value interning for ZST types)
- #78070 (we can test std and core panic macros together)
- #78076 (Move orphan module-name/mod.rs files into module-name.rs files)
- #78129 (Wrapping intrinsics doc links update.)
- #78133 (Add some MIR-related regression tests)
- #78144 (Don't update `entries` in `TypedArena` if T does not need drop)
- #78145 (Drop unneeded `mut`)
- #78157 (Remove unused type from librustdoc)
Guillaume Gomez [Tue, 20 Oct 2020 19:46:42 +0000 (21:46 +0200)]
Rollup merge of #78145 - LingMan:ast_pretty_mut, r=jonas-schievink
Drop unneeded `mut`
These parameters don't get modified.
Note that `trailing_comment` is pub and gets exported from `rustc_ast_pretty`. Is that considered to be a stable API? If yes, and you want to reserve the right to modify `self` in `trailing_comment` in the future, that hunk would need to be dropped.
Guillaume Gomez [Tue, 20 Oct 2020 19:46:40 +0000 (21:46 +0200)]
Rollup merge of #78144 - bugadani:elements-nodrop, r=oli-obk
Don't update `entries` in `TypedArena` if T does not need drop
As far as I can tell, `entries` is only used when dropping `TypedArenaChunk`s and their contents. It is already ignored there, if T is not `mem::needs_drop`, this PR just skips updating it's value.
You can see `TypedArenaChunk` ignoring the entry count in L71. The reasoning is similar to what you can find in `DroplessArena`.
est31 [Tue, 20 Oct 2020 16:38:54 +0000 (18:38 +0200)]
Sync LLVM submodule if it has been initialized
Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47ccdfa63f8b4b9fb47a9aa92381801d3ff1,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
bors [Tue, 20 Oct 2020 16:59:23 +0000 (16:59 +0000)]
Auto merge of #78151 - tmiasko:disable-match-branch-simplification, r=wesleywiser
Disable MatchBranchSimplification
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
projects / rust.git / log