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

Panic caused by Markdown in latest nightly #40918

Closed
SergioBenitez opened this issue Mar 30, 2017 · 11 comments
Closed

Panic caused by Markdown in latest nightly #40918

SergioBenitez opened this issue Mar 30, 2017 · 11 comments
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@SergioBenitez
Copy link
Contributor

rustc is panicking on markdown that previously parsed. This appears to be caused by the transition from hoedown to pulldown-cmark (#40912, #40338):

---- src/request/form/from_form_value.rs - request::form::from_form_value::FromFormValue (line 59) stdout ----
	error: unknown start of token: `
 --> <anon>:2:42
  |
2 | A value is validated successfully if the `from_str` method for the given
  |                                          ^

thread 'rustc' panicked at 'Box<Any>', /checkout/src/libsyntax/parse/lexer/mod.rs:81
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'rustc' panicked at 'couldn't compile the test', /checkout/src/librustdoc/test.rs:270

The markdown being referenced in the error looks like this:

/// Rocket implements `FromFormValue` for many standard library types. Their
/// behavior is documented here.
///
///   * **f32, f64, isize, i8, i16, i32, i64, usize, u8, u16, u32, u64**
///
///   **IpAddr, Ipv4Addr, Ipv6Addr, SocketAddrV4, SocketAddrV6, SocketAddr**
///
///     A value is validated successfully if the `from_str` method for the given
///     type returns successfully. Otherwise, the raw form value is returned as
///     the `Err` value.

cc @steveklabnik @GuillaumeGomez

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Mar 30, 2017

The problem is that this block:

/// A value is validated successfully if the from_str method for the given
/// type returns successfully. Otherwise, the raw form value is returned as
/// the Err value.

Is considered as code. I wonder what would be a good solution for this (because that's how correct markdown considers this)...

@SergioBenitez
Copy link
Contributor Author

I don't think it should be...should it? It wasn't prior to this: https://api.rocket.rs/rocket/request/trait.FromFormValue.html#provided-implementations

@GuillaumeGomez
Copy link
Member

Yes but before, hoedown wasn't really markdown compliant. You can see by yourself how your code is interpreted by the markdown here.

@steveklabnik steveklabnik added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools labels Mar 30, 2017
@steveklabnik
Copy link
Member

(not giving this all the tags because it's linked in to the tracking issue

@steveklabnik
Copy link
Member

steveklabnik commented Mar 30, 2017

rustc is panicking on markdown that previously parsed.

To be clear, this is a test failure, not an ICE, correct?

thread 'rustc' panicked at 'couldn't compile the test', /checkout/src/librustdoc/test.rs:270

that is, this is a test failure.

@GuillaumeGomez
Copy link
Member

To be clear, this is a test failure, not an ICE, correct?

Yes.

@steveklabnik
Copy link
Member

Right. So this is more of expected breakages caused by a bugfix.

@SergioBenitez are you running off rustc master? I wasn't even aware this was in nightly yet, I thought it missed the cutoff. As I mentioned in the other issue, I was planning on publicizing this tomorrow.

@SergioBenitez
Copy link
Contributor Author

SergioBenitez commented Mar 30, 2017

@steveklabnik Looks like this made it into today's nightly.

Okay, so after discussing this a bit on IRC and playing with the commonmark.js script, the issue stems from a difference in how hoedown and pulldown-cmark interpret text to be inside of a list item:

Leading text:

  * List Item Heading

  This is considered to be part of the list item in `hoedown` but not `pulldown-cmark`.

    This is still inside the list item in `hoedown` but is a new code block in `pulldown-cmark`.

As shown above, text that hoedown treated as being inside of a list item is now treated by pulldown-cmark to be a code block. rustdoc tries to compile each code block as Rust code, and since this is clearly not Rust, compilation fails, and we see the panic! from the failed compilation.

While this isn't a bug in rustc, it is a breaking change. I'd suggest that a crater run is done to catch any more of these and potentially notify the authors. Alternatively, some of these peculiarities can be "forward-ported" to the new parser.

@steveklabnik
Copy link
Member

Huh. Well, better make that post for sure, I guess. (The nightly)

Crater wouldn't catch this, it doesn't run tests.

@nagisa
Copy link
Member

nagisa commented Mar 30, 2017

///   * **f32, f64, isize, i8, i16, i32, i64, usize, u8, u16, u32, u64**
///
///     **IpAddr, Ipv4Addr, Ipv6Addr, SocketAddrV4, SocketAddrV6, SocketAddr**
///
///     A value is validated successfully if the `from_str` method for the given
///     type returns successfully. Otherwise, the raw form value is returned as
///     the `Err` value.

Should work. The prior behaviour seems like a bug to me even considering the original markdown, and I think this is not easily fixable without making the markdown parser non-compliant.

@steveklabnik
Copy link
Member

I'm giving this one a close since it's expected behavior. Thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants