Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 17 pull requests #78270

Merged
merged 46 commits into from
Oct 23, 2020
Merged

Rollup of 17 pull requests #78270

merged 46 commits into from
Oct 23, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

follower and others added 30 commits September 28, 2020 04:05
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.

When/if the guide/"Getting Started" section gets revised to not be `rustc`-specific the linked section can be changed.

In the meantime this prevents leading first time contributors into a confusing cul de sac.
Signed-off-by: wcampbell <wcampbell1995@gmail.com>
Signed-off-by: wcampbell <wcampbell1995@gmail.com>
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.
Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47c,
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.
* 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
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 rust-lang#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.]_

Related issues:

 * rust-lang#77215

 * rust-lang/rustc-dev-guide#775 (comment)
…nzero-to-nonzero, r=dtolnay

Implement TryFrom between NonZero types.

This will instantly be stable, as trait implementations for stable types and traits can not be `#[unstable]`.

Closes rust-lang#77258.

@rustbot modify labels: +T-libs
… r=jonas-schievink

Mark `repr128` as `incomplete_features`

As mentioned in rust-lang#56071 and noticed in rust-lang#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.

Closes rust-lang#77457.
…m-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: rust-lang#49359
…, r=m-ou-se

Cleanup network tests

Some cleanup for network related tests
…n514

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.
…tency, 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 rust-lang#74010 by italicizing them rather than having them in a code block.
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
…t, r=petrochenkov

Make inline const work in range patterns

Fixes rust-lang#78108 which is a follow up of rust-lang#77124

r? @petrochenkov
…=Mark-Simulacrum

Sync LLVM submodule if it has been initialized

Since having enabled the download-ci-llvm option,
and having rebased on top of rust-lang#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.
Update cargo

3 commits in 79b397d72c557eb6444a2ba0dc00a211a226a35a..dd83ae55c871d94f060524656abab62ec40b4c40
2020-10-15 14:41:21 +0000 to 2020-10-20 19:31:26 +0000
- Support glob patterns for package/target selection (rust-lang/cargo#8752)
- Update env_logger requirement from 0.7.0 to 0.8.1 (rust-lang/cargo#8795)
- Fix man page links inside `option` blocks. (rust-lang/cargo#8793)
…ure, r=nikomatsakis

Make closures inherit the parent function's target features

r? @ghost
Closes rust-lang#73631
Explain where the closure return type was inferred

Fixes rust-lang#78193
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>--&gt;</b> src/topology/builder.rs:141:35
    <b>|</b>
<b>120 |</b>             let transform = match transform {
    <b>|    _________________________-</b>
<b>121 |   |</b>             Transform::Function(t) =&gt; {
    <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) =&gt; {
<b>...   | |</b>
<b>139 | | |</b>                 .compat();
<b>140 | | |</b>             }
    <b>| |_|_____________- this is found to be of type `()`</b>
<b>141 |   |</b>             Transform::Task(t) =&gt; 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&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

**After:**

<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
   <b>--&gt;</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) =&gt; {
    <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) =&gt; {
<b>...   |</b>
<b>139 | |</b>                   .compat();
<b>140 | |</b>               }
    <b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b>                 Transform::Task(t) =&gt; 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&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

FYI @Hoverbear
…r=lcnr

Add some inference-related regression tests about incorrect diagnostics

Closes rust-lang#71732
Closes rust-lang#72616
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=5
@rustbot modify labels: rollup

@rustbot rustbot added the rollup A PR which is a rollup label Oct 23, 2020
@bors
Copy link
Contributor

bors commented Oct 23, 2020

📌 Commit b5d2ff0 has been approved by JohnTitor

@bors
Copy link
Contributor

bors commented Oct 23, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 23, 2020
@JohnTitor
Copy link
Member Author

Oh, we have another rollup, which is older, then @bors p=6

@bors
Copy link
Contributor

bors commented Oct 23, 2020

⌛ Testing commit b5d2ff0 with merge 07a63e6...

@bors
Copy link
Contributor

bors commented Oct 23, 2020

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 07a63e6 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 23, 2020
@bors bors merged commit 07a63e6 into rust-lang:master Oct 23, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 23, 2020
@JohnTitor JohnTitor deleted the rollup-bldrjh5 branch October 23, 2020 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.