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

Support lists and stylings in more places for rustc --explain #126994

Merged
merged 1 commit into from
Jul 23, 2024

Conversation

Alexendoo
Copy link
Member

Adds support for *foo*, stylings not immediately following whitespace e.g. (`Foo`) and lists starting with whitespace:

* previously supported
 * now also supported

These are fairly common in the existing error docs, some before/after examples:

E0460

image
image

E0059

image
image

@rustbot
Copy link
Collaborator

rustbot commented Jun 26, 2024

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 26, 2024
Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Couple small suggestions

Comment on lines -270 to -271
/// Find first line that isn't empty or doesn't start with whitespace, that will
/// be our contents
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to update rather than remove?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meant to remove it since the function name is clear, the previous comment confused me a bit

Comment on lines 109 to 118
_ if let Some(strong @ (b"**" | b"__")) = loop_buf.get(..2) => {
parse_simple_pat(loop_buf, strong, strong, Po::None, MdTree::Strong)
}
(_, Newline | Whitespace) if loop_buf.starts_with(STG) => {
parse_simple_pat(loop_buf, STG, STG, Po::None, MdTree::Strong)
_ if let Some(emph @ (b"*" | b"_")) = loop_buf.get(..1) => {
parse_simple_pat(loop_buf, emph, emph, Po::None, MdTree::Emphasis)
}
(_, Newline | Whitespace) if loop_buf.starts_with(STK) => {
_ if loop_buf.starts_with(STK) => {
parse_simple_pat(loop_buf, STK, STK, Po::None, MdTree::Strikethrough)
}
(_, Newline | Whitespace) if loop_buf.starts_with(ANC_S) => {
_ if loop_buf.starts_with(ANC_S) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment, code, and */**/~~ changes look correct, but _/__ and <...> anchors need the preceding whitespace so snake case doesn't turn into italics (gh agrees with commonmark here):

  • foo*bar* foobar
  • foo**bar** foobar
  • foo_bar_ foo_bar_
  • foo__bar__ foo__bar__
  • foo~~bar~ foobar
  • foo`bar` foobar
  • foo<www.docs.rs> foo<www.docs.rs>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My impression was it's going for concise over correct hence the hand rolled markdown parser, there's a bunch of other stuff like (_foo_) should italicise but not _foo _bar or foo* bar*. As far as I can tell these do not occur in the error code docs though, so the question is how much do we want to support?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it was intended to be pretty simple and just hopefully never receive bad markdown 😆.

Adding Boundary to Prev and then setting it with something like x.is_ascii_punctuation() && ~[b'_', b'*', b'~].contains(&x) might be slightly more accurate to match Newline | Whitespace | Boundary. No need for you to do that here though, I'll probably play around with it a bit in a followup.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A punctuation boundary sounds good, should I still make the #126994 (comment) change or leave it to you when you implement that?

If it ever will support nested formatting then just x.is_ascii_punctuation() is closer I think, since ___foo__ bar_ is valid as foo bar

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, I'll follow up if you prefer not to make the chance here :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made the change since you would've had to unmerge the */_ arms either way

@tgross35
Copy link
Contributor

There's also a stdout test in markdown/tests/input.md if you want to verify the result (should work with --bless)

@compiler-errors
Copy link
Member

@rustbot author still waiting on @tgross35's feedback afaict

@rustbot rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 9, 2024
@Alexendoo
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 23, 2024
@tgross35
Copy link
Contributor

tgross35 commented Jul 23, 2024

Sorry, this one slipped my mind. LGTM now though, thanks for the change and for the tests!

r? @tgross35
@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jul 23, 2024

📌 Commit 5824ab1 has been approved by tgross35

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 23, 2024
@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 Jul 23, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 23, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#125886 (Migrate run make issue 15460)
 - rust-lang#126898 (Migrate `run-make/link-framework` to `rmake.rs`)
 - rust-lang#126994 (Support lists and stylings in more places for `rustc --explain`)
 - rust-lang#127990 (Migrate `lto-linkage-used-attr`, `no-duplicate-libs` and `pgo-gen-no-imp-symbols` `run-make` tests to rmake)
 - rust-lang#128060 (Fix inclusion of `wasm-component-ld` in dist artifacts)
 - rust-lang#128082 (Note closure captures when reporting cast to fn ptr failed)
 - rust-lang#128098 (make it possible to disable download-rustc if it's incompatible)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8e206c0 into rust-lang:master Jul 23, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Jul 23, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 23, 2024
Rollup merge of rust-lang#126994 - Alexendoo:explain-markdown, r=tgross35

Support lists and stylings in more places for `rustc --explain`

Adds support for `*foo*`, stylings not immediately following whitespace e.g. ``(`Foo`)`` and lists starting with whitespace:

```md
* previously supported
```
```md
 * now also supported
 ```

These are fairly common in the existing error docs, some before/after examples:

### E0460

![image](https://github.com/rust-lang/rust/assets/1830331/4d0dc5dd-b71f-48b1-97ae-9f7199e952ed)
![image](https://github.com/rust-lang/rust/assets/1830331/4bbcb1e4-99ba-4d0d-b338-fe19d96a5eb1)

### E0059

![image](https://github.com/rust-lang/rust/assets/1830331/8457f69a-3126-4777-aa4a-953f7b29f59b)
![image](https://github.com/rust-lang/rust/assets/1830331/ac2189f8-512e-4b3b-886d-6c4a619d17f2)
@Alexendoo Alexendoo deleted the explain-markdown branch July 23, 2024 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants