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 11 pull requests #80355

Closed
wants to merge 30 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

hencrice and others added 30 commits December 13, 2020 04:49
Also handle Tuple and Array separately, which was not explicitly checked.

Fixes rust-lang#79799.
This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done.

Part of issue rust-lang#79417.
Ran the tidy check

Following the diagnostic guide better

Diagnostic generation is now relegated to its own function in the diagnostics module.
Added tests

Fixed the ui test
Rename rustc_middle::lint::LintSource to rustc_middle::lint::LintLevelSource.
This is to clarify the difference between `LevelSource`
and `LintLevelSource`.

Appease x.py fmt.
`foreign_module` and `wasm_import_module` are not needed for linking,
and hence can be removed from CodegenResults.
NatVis files describe how to display types in some Windows debuggers,
such as Visual Studio, WinDbg, and VS Code.

This commit makes several improvements:

* Adds visualizers for Rc<T>, Weak<T>, and Arc<T>.

* Changes [size] to [len], for consistency with the Rust API.
  Visualizers often use [size] to mirror the size() method on C++ STL
  collections.

* Several visualizers used the PVOID and ULONG typedefs. These are part
  of the Windows API; they are not guaranteed to always be defined in a
  pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to
  `unsigned long`.

* Cosmetic change: Removed {} braces around the visualized display
  for `Option` types. They now display simply as `Some(value)` or
  `None`, which reflects what is written in source code.

* The visualizer for `alloc::string::String` makes assumptions about
  the layout of `String` (it casts `String*` to another type), rather
  than using symbolic expressions. This commit changes the visualizer
  so that it simply uses symbolic expressions to access the string
  data and string length.
…, accounting for code block edition modifiers

This is a squash of these commits:
- Highlight edition-specific keywords correctly in code blocks,
accounting for code block edition modifiers
- Fix unit tests
- Revert changes to rustc_span::symbol to prepare for merge of rust-lang#80272
- Use new Symbol::is_reserved API from rust-lang#80272
Also updated the mir-opt test output files.
…Swatinem

Remap instrument-coverage line numbers in doctests

This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done, and rustdoc
still does not output the correct filename when running doctests in a
workspace.

Part of rust-lang#79417 although I dont consider that fixed until both filenames
and columns are mapped correctly.

r? ```@richkadel```

I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
Refactored verbose print into a function

Also handle Tuple and Array separately, which was not explicitly checked.

Fixes rust-lang#79799.
Implemented a compiler diagnostic for move async mistake

Fixes rust-lang#79694

First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)

This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.

Checked code:
```rust
fn main() {
    move async { };
}
```

Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
   Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
 --> src\main.rs:2:10
  |
2 |     move async { };
  |          ^^^^^ expected one of `|` or `||`

error: aborting due to previous error

error: could not compile `move_async_test`
```

New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
   Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
 --> src\main.rs:2:13
  |
2 |     let _ = move async { };
  |             ^^^^^^^^^^
  |
help: try switching the order
  |
2 |     let _ = async move { };
  |             ^^^^^^^^^^

error: aborting due to previous error

error: could not compile `move_async_test`
```

Is there a file/module where these kind of things are tested?
Would love some feedback 😄
Exclude unnecessary info from CodegenResults

`foreign_module` and `wasm_import_module` are not needed for linking, and hence can be removed from CodegenResults.

Fixes rust-lang#77857
…yn514,petrochenkov

Highlight edition-specific keywords correctly in code blocks, accounting for code block edition modifiers

Previously, edition-specific keywords (such as `async` and `await`) were not highlighted in code blocks, regardless of what edition was set. With this PR, this issue is fixed.

Now, the following behavior happens:
- When a code block is explicitly set to edition X, keywords from edition X are highlighted
- When a code block is explicitly set to a version that does not contain those keywords from edition X (e.g. edition Y), keywords from edition X are **not** highlighted
- When a code block has no explicit edition, keywords from the edition passed via `--edition` to rustdoc are highlighted

For example, a project set with `edition = "2015"` in its `Cargo.toml` would not highlight `async`/`await` unless the code block was set to `edition2018`. Additionally, a project set with `edition = "2018"` in its `Cargo.toml` *would* highlight `async`/`await` unless the code block was set to a version that did not contain those keywords (e.g. `edition2015`).

This PR fixes rust-lang#80004.

r? ```@jyn514```
…enkov

Rename rustc_middle::lint::LintSource

Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`.

This enum represents the source of a *lint level*, not a lint. This should improve code readability.

Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
Add installation commands to `x` tool README
…_specifier_hard_error, r=Mark-Simulacrum

Revert missing fragment specifier hard error

Closes rust-lang#76605

Reopens rust-lang#40107

r? ``@Mark-Simulacrum``
Improvements to NatVis support

NatVis files describe how to display types in some Windows debuggers,
such as Visual Studio, WinDbg, and VS Code.

This commit makes several improvements:

* Adds visualizers for Rc<T>, Weak<T>, and Arc<T>.

* Changes [size] to [len], for consistency with the Rust API.
  Visualizers often use [size] to mirror the size() method on C++ STL
  collections.

* Several visualizers used the PVOID and ULONG typedefs. These are part
  of the Windows API; they are not guaranteed to always be defined in a
  pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to
  `unsigned long`.

* Cosmetic change: Removed {} braces around the visualized display
  for `Option` types. They now display simply as `Some(value)` or
  `None`, which reflects what is written in source code.

* The visualizer for `alloc::string::String` makes assumptions about
  the layout of `String` (it casts `String*` to another type), rather
  than using symbolic expressions. This commit changes the visualizer
  so that it simply uses symbolic expressions to access the string
  data and string length.

* The visualizers for `str` and `String` now place the character data
  array under a synthetic `[chars]` node. When expanding a `String`
  node, users rarely want to see an array of characters. This just places
  them behind one expansion node / level.
Include rustdoc in the compiler docs index.

This should help ensure that the index page at https://doc.rust-lang.org/nightly/nightly-rustc/ includes a link to the rustdoc docs as well.

Fixes rust-lang#80307
…=GuillaumeGomez

Updated the match with the matches macro

r?``@GuillaumeGomez``
@rustbot rustbot added the rollup A PR which is a rollup label Dec 24, 2020
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Dec 24, 2020

📌 Commit aa29a28 has been approved by Dylan-DPC

@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 Dec 24, 2020
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Dec 24, 2020

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Dec 24, 2020

📌 Commit aa29a28 has been approved by Dylan-DPC

@bors
Copy link
Contributor

bors commented Dec 24, 2020

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup-hnmjtzn (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup-hnmjtzn --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging src/librustdoc/html/markdown.rs
CONFLICT (content): Merge conflict in src/librustdoc/html/markdown.rs
Auto-merging src/librustdoc/html/highlight.rs
CONFLICT (content): Merge conflict in src/librustdoc/html/highlight.rs
Removing src/doc/rustc/src/lints/listing/deny-by-default.md
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 24, 2020
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-hnmjtzn branch December 24, 2020 18:15
@bors
Copy link
Contributor

bors commented Dec 24, 2020

☔ The latest upstream changes (presumably #79742) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.