Playgrounds rejects valid Rust (due to input processing?)

[thedataking]

This code is expected to work but generates a compiler error due to a comment:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=45b03c2e33ff3b6c20af40794c505c92

   Compiling playground v0.0.1 (/playground)
error: this file contains an un-closed delimiter
 --> src/main.rs:1:1854
  |
1 | pub fn main() {
    let reserved_names: [&str; 103] = [
        "as",
        "break",
        "const",
(snip)

If rust-playground tries to put all the code on a single line, that's likely the problem. Thanks for building and maintaining such a useful tool; much appreciated!

[shepmaster]

If rust-playground tries to put all the code on a single line

You can easily test your hypothesis with a smaller program — what are the results of such a test?

[shepmaster]

This code is expected to work

You could also easily test that this code works outside of the playground — what are the results of such a test?

[jonas-schievink]

Minified example:

fn main() {
    &[
        // this breaks playgrounds
    ];
}

It does indeed work outside the playground (ignoring the type inference error).

[shepmaster]

Minified example:

https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=cb2cc80f64396c29152195d66e67565c

This does not fail with the same error originally reported; can you clarify exactly how you are reproducing the problem?

[thedataking]

This fails with the same error and works for me locally:

pub fn main() {
    let r: [&str; 0] = [ // works locally; errors in playgrounds
    ];   
}

[lqd]

Ha, this shows the content is not the whole problem, and unfortunately pasting it in/from github "fixes it", as I think the issue is in the EOL delimiters. Here's a repro for me of that last one, but constructed from the initial link.

I think the playground doesn't see the mac \r in the code as end of lines.