mdbook has a lot of optional dependencies that we don't want, so instead
of using it directly, we re-build rustbook to use mdbook as a library.
For convenience' sake, we keep the same CLI interface as mdbook; the
only difference is that it only accepts build and test subcommands,
rather than the full range.
The length of a URL is usually not under our control, and Markdown
provides no way to split a URL in the middle. Therefore, comment
lines consisting _solely_ of a URL (possibly with a Markdown link
label in front) should be exempt from the line-length restriction.
Inline hyperlink destinations ( `[foo](http://...)` notation ) are
_not_ exempt, because it is my arrogant opinion that long lines of
that type make the source text illegible.
The patch adds dependencies on the `regex` and `lazy_static` crates
to the tidy utility. This _appears_ to Just Work, but if you would
rather not have that dependency I am willing to provide a hand-written
parser instead.
add solaris rustbuild support
Add Solaris as recognized ostype
Add cputype recognition for Solaris
Fixes#39729
A future pull request will discriminate between the commercial release and older opensource derivatives to account for divergence, for now, this is compatible with both.
[MIR] SwitchInt Everywhere
Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general).
Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)):
^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation.
```
AFTER:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.50 secs
Finished release [optimized] target(s) in 31.42 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 439.56 secs
Finished release [optimized] target(s) in 435.15 secs
CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident
CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident
SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident
SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident
BEFORE:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.84 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 451.17 secs
CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident
CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident
SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident
SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident
```
cc @nikomatsakis @eddyb
macros: fix inert attributes from `proc_macro_derives` with `#![feature(proc_macro)]`
This PR refactors collection of `proc_macro_derive` invocations to fix#39347.
After this PR, the input to a `#[proc_macro_derive]` function no longer sees `#[derive]`s on the underlying item. For example, consider:
```rust
extern crate my_derives;
use my_derives::{Trait, Trait2};
#[derive(Copy, Clone)]
#[derive(Trait)]
#[derive(Trait2)]
struct S;
```
Today, the input to the `Trait` derive is `#[derive(Copy, Clone, Trait2)] struct S;`, and the input to the `Trait2` derive is `#[derive(Copy, Clone)] struct S;`. More generally, a `proc_macro_derive` sees all builtin derives, as well as all `proc_macro_derive`s listed *after* the one being invoked.
After this PR, both `Trait` and `Trait2` will see `struct S;`.
This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice.
r? @nrc
rustdoc: Show attributes on all item types
Currently attributes are only shown for structs, unions and enums but
they should be shown for all items. For example it is useful to know if a
function is `#[no_mangle]`.
improve error message when two-arg assert_eq! receives a trailing comma
Previously, `assert_eq!(left, right,)` (respectively, `assert_ne!(left,
right,)`; note the trailing comma) would result in a confusing "requires
at least a format string argument" error. In reality, a format string is
optional, but the trailing comma puts us into the "match a token tree of
zero or more tokens" branch of the macro (in order to support the
optional format string), and passing the empty token tree into
`format_args!` results in the confusing error. If instead we match a
token tree of one or more tokens, we get a much more sensible
"unexpected end of macro invocation" error.
While we're here, fix up a stray space before a comma in the match
guards.
Resolves#39369.
-----
**Before:**
```
$ rustc scratch.rs
error: requires at least a format string argument
--> scratch.rs:2:5
|
2 | assert_eq!(1, 2,);
| ^^^^^^^^^^^^^^^^^^
|
= note: this error originates in a macro outside of the current crate
error: aborting due to previous error
```
**After:**
```
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc scratch.rs
error: unexpected end of macro invocation
--> scratch.rs:2:20
|
2 | assert_eq!(1, 2,);
| ^
```
This commit adds three new builders, one OSX, one Linux, and one MSVC, which
will produce "nightlies" with LLVM assertions disabled. Currently all nightly
releases have LLVM assertions enabled to catch bugs before they reach the
beta/stable channels. The beta/stable channels, however, do not have LLVM
assertions enabled.
Unfortunately though projects like Servo are stuck on nightlies for the near
future at least and are also suffering very long compile times. The purpose of
this commit is to provide artifacts to these projects which are not distributed
through normal channels (e.g. rustup) but are provided for developers to use
locally if need be.
Logistically these builds will all be uploaded to `rustc-builds-alt` instead of
the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay
there forever (until cleaned out if necessary) and there are no plans to
integrate this with rustup and/or the official release process.
treat setting the number of test-threads to 0 as an error
It is currently possible to call `cargo test -- --test-threads=0` which will cause cargo to hang until aborted. This change will fix that and will report an appropriate error to the user.
[LLVM 4.0] Fix CreateCompileUnit
This is largely identical to @dylanmckay's [patch](https://github.com/dylanmckay), except that it doesn't try to use `file_metadata()`. I don't think that is necessary because we don't want the compile unit to be added to `debug_context.created_files`, though I'd like confirmation from someone who knows for sure. If that is needed, I can modify `file_metadata_()` so that it can be used from `compile_unit_metadata()`.
