rustdoc: three tick code blocks confuse language choice with testing options

[pnkfelix]

In other non-Rust contexts, when writing a code block, I have become used to using the (optional) first word after the initial three ticks to indicate the language of the code block. See for example the syntax example taken from octopress:

``` [language] [title] [url] [link text] [linenos:false] [start:#] [mark:#,#-#]
code snippet
```

However, rustdoc has a different interpretation for the (again optional) first word after the initial three ticks: it is used for an directive regarding how to handle the given code when interpreted as a test. Potential values for the directive include: "ignore", "should_fail", "no_run"

It would be better if we came up with some way to indicate these meta-data directives in a manner that was still compatible with using the language directives as indicated in the octopress system.

At the very least, we could treat any code block that has a string that is not one of the builtin rustdoc directives (like the three listed above) nor the string "rust" should be implicitly treated as ignore. Then the author will retain the option of including the language name, and it will just get skipped by rustdoc when testing rust code blocks.

(Other options include: find some other channel to use to communicate this information besides the initial three ticks. A simple one would be instead following the final three ticks, though admittedly that may be too subtle.)

[huonw]

Sundown (and by extension Rustdoc) supports multiple attributes, like

``` {.rust .ignore}
...
```

They actually get added as part of the class attribute of the rendered HTML codeblock (and rustdoc happens to (ab)use them for detecting testable things). However, it seems this syntax is not sufficient for full octopress attributes.

[steveklabnik]

At this point, I think that changing this behavior would need an RFC. It's effectively a feature request for Rustdoc, and would cause pretty huge churn amongst all the work that we're doing.

I'm going to close this, but @pnkfelix , if you stil lcare about this and would like me to move it to the RFCs repo, just let me know.