This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
Add a new test directory called 'rustdoc' where all files inside are documented
and run against the `htmldocck` script to have assertions about the output.
Until I can figure out the correct way to configure jemalloc for Bitrig, this patch will correctly disable it. All other build targets remain unchanged.
MacOS X does not ship with Java installed by default. Instead it
includes binary stubs that upon execution pop up a message suggesting
the installation of the JDK.
Since `javac` is only used when `antlr4` is available, it is possible
to work around the popup by only probing for `javac` if `antlr4` has
been successfully detected (in which case the JDK is probably already
installed on the system).
Fixes#23138.
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want them.
(Crates behind the facade are not documented at all)
[breaking-change]
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want compiler docs during development.
Crates behind the facade are only documented on nightly/dev builds (where they
can be used).
[breaking-change]
Closes#23772Closes#21297
LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.
Executing `configure` seems to create the following error due to how the script [parses Pandoc's version](https://github.com/rust-lang/rust/blob/master/configure#L705):
```text
./configure: line 705: [: pandoc: integer expression expected
./configure: line 705: [: 1.12.4.2: integer expression expected
```
This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.
the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).
use an alternate construction in order to keep the semantic.
When trying to build against a newer, local LLVM version it might be
preferable to have a flag to disable the LLVM version check instead of
having to modify the configure script.
Fixes#21998
the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).
use an alternate construction in order to keep the semantic.
This adds a new lexer/parser combo for the entire Rust language can be generated with with flex and bison, taken from my project at https://github.com/bleibig/rust-grammar. There is also a testing script that runs the generated parser with all *.rs files in the repository (except for tests in compile-fail or ones that marked as "ignore-test" or "ignore-lexer-test"). If you have flex and bison installed, you can run these tests using the new "check-grammar" make target.
This does not depend on or interact with the existing testing code in the grammar, which only provides and tests a lexer specification.
OS X users should take note that the version of bison that comes with the Xcode toolchain (2.3) is too old to work with this grammar, they need to download and install version 3.0 or later.
The parser builds up an S-expression-based AST, which can be displayed by giving the "-v" argument to parser-lalr (normally it only gives output on error). It is only a rough approximation of what is parsed and doesn't capture every detail and nuance of the program.
Hopefully this should be sufficient for issue #2234, or at least a good starting point.
