| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Unfortunately the `parking_lot` crate enables the `synchapi` feature of the
`winapi` crate which activates a dependency on `libsynchronization.a`. The MinGW
version of `libsynchronization.a` pulls in a dependency
`api-ms-core-synch-l1-2-0.dll` which causes rustc to not work on Windows 7
(tracked in #49438)
The `parking_lot` crate is not currently used in the compiler unless parallel
queries are enabled. This feature is not enabled by default and not used at all
in the beta/stable compilers. As a result the dependency in this commit was
removed and the CI build which checks parallel queries was disabled.
This isn't a great long-term solution but should hopefully be enough of a patch
for beta to buy us some more time to figure this out.
|
|
Remove filetime dep from build_helper
r? @alexcrichton
|
|
|
|
|
|
This includes rust-lang/cargo#5255 which fixed regression in
`cargo rustdoc` command.
|
|
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
|
|
This updates termcolor to pick up BurntSushi/ripgrep#867.
Fixes #49322.
|
|
This commit updates the `ToolBuild` step to stream Cargo's JSON messages, parse
them, and record all libraries built. If we build anything twice (aka Cargo)
it'll most likely happen due to dependencies being recompiled which is caught by
this check.
|
|
|
|
Bump racer and home
This removes 10 dependencies from the build :tada:
|
|
Fixes broken RLS tests/build
|
|
This removes 10 dependencies from the build :tada:
|
|
This should fix regressions in Cargo after swithing to clap:
* If an external subcommand name was close to built-in one, clap
errored (fixed by updating clap version)
* External subcomands didn't received their name as a first arg
|
|
|
|
This notably includes
* https://github.com/rust-lang/cargo/pull/5152
* https://github.com/rust-lang/cargo/pull/5188
The first one switches cargo from docopt to clap (
we also update to the latest calp in this repository),
the second one should help us to unify feature flags
for Cargo itself and RLS, and build Cargo libray only
once.
|
|
|
|
Dedupe rand
|
|
|
|
|
|
It is backed by the new `normalize_projection_ty` query, which uses
canonicalization.
|
|
Should hopefully fix compiling the rls!
|
|
|
|
Required moving all fulldeps tests depending on `rand` to different locations as
now there's multiple `rand` crates that can't be implicitly linked against.
|
|
rustc: Migrate to `termcolor` crate from `term`
This crate moves the compiler's error reporting to using the `termcolor` crate
from crates.io. Previously rustc used a super-old version of the `term` crate
in-tree which is basically unmaintained at this point, but Cargo has been using
`termcolor` for some time now and tools like `rg` are using `termcolor` as well,
so it seems like a good strategy to take!
Note that the `term` crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.
cc #45728
|
|
|
|
This crate moves the compiler's error reporting to using the `termcolor` crate
from crates.io. Previously rustc used a super-old version of the `term` crate
in-tree which is basically unmaintained at this point, but Cargo has been using
`termcolor` for some time now and tools like `rg` are using `termcolor` as well,
so it seems like a good strategy to take!
Note that the `term` crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.
cc #45728
|
|
|
|
It looks like this cuts down on the number of dependencies in env_logger and
notably cuts out a difference between a shared dependency of rls/cargo. My goal
here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo
once, and this is one step towards that!
|
|
|
|
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
|
|
|
|
|
|
These changes were meant to be in
2b18d8fe9dc05415a8e6b7cadf879c7f7ebe020a (rebased from
12a230562ece9b0d29018a436676141054dc53b7), but I messed up the rebase a
bit as the file had been moved.
|
|
|
|
Do not run the default panic hook inside procedural macros.
Fixes #47812
r? @nikomatsakis
|
|
|
|
|
|
Is it really time? Have our months, no, *years* of suffering come to an end? Are we finally able to cast off the pall of Hoedown? The weight which has dragged us down for so long?
-----
So, timeline for those who need to catch up:
* Way back in December 2016, [we decided we wanted to switch out the markdown renderer](https://github.com/rust-lang/rust/issues/38400). However, this was put on hold because the build system at the time made it difficult to pull in dependencies from crates.io.
* A few months later, in March 2017, [the first PR was done, to switch out the renderers entirely](https://github.com/rust-lang/rust/pull/40338). The PR itself was fraught with CI and build system issues, but eventually landed.
* However, not all was well in the Rustdoc world. During the PR and shortly after, we noticed [some differences in the way the two parsers handled some things](https://github.com/rust-lang/rust/issues/40912), and some of these differences were major enough to break the docs for some crates.
* A couple weeks afterward, [Hoedown was put back in](https://github.com/rust-lang/rust/pull/41290), at this point just to catch tests that Pulldown was "spuriously" running. This would at least provide some warning about spurious tests, rather than just breaking spontaneously.
* However, the problems had created enough noise by this point that just a few days after that, [Hoedown was switched back to the default](https://github.com/rust-lang/rust/pull/41431) while we came up with a solution for properly warning about the differences.
* That solution came a few weeks later, [as a series of warnings when the HTML emitted by the two parsers was semantically different](https://github.com/rust-lang/rust/pull/41991). But that came at a cost, as now rustdoc needed proc-macro support (the new crate needed some custom derives farther down its dependency tree), and the build system was not equipped to handle it at the time. It was worked on for three months as the issue stumped more and more people.
* In that time, [bootstrap was completely reworked](https://github.com/rust-lang/rust/pull/43059) to change how it ordered compilation, and [the method by which it built rustdoc would change](https://github.com/rust-lang/rust/pull/43482), as well. This allowed it to only be built after stage1, when proc-macros would be available, allowing the "rendering differences" PR to finally land.
* The warnings were not perfect, and revealed a few [spurious](https://github.com/rust-lang/rust/pull/44368) [differences](https://github.com/rust-lang/rust/pull/45421) between how we handled the renderers.
* Once these were handled, [we flipped the switch to turn on the "rendering difference" warnings all the time](https://github.com/rust-lang/rust/pull/45324), in October 2017. This began the "warning cycle" for this change, and landed in stable in 1.23, on 2018-01-04.
* Once those warnings hit stable, and after a couple weeks of seeing whether we would get any more reports than what we got from sitting on nightly/beta, [we switched the renderers](https://github.com/rust-lang/rust/pull/47398), making Pulldown the default but still offering the option to use Hoedown.
And that brings us to the present. We haven't received more new issues from this in the meantime, and the "switch by default" is now on beta. Our reasoning is that, at this point, anyone who would have been affected by this has run into it already.
|
|
|
|
|
|
|
|
Use time crate in bootstrap dist instead of date
`bootstrap dist` command is trying to run *NIX specific `date` command to get current month and year. This command keep failing when it's called on a Windows command prompt. This patch is making it use time crate.
Closes: #47908
|
|
Update book
This PR does two things:
1. update the book to include https://github.com/rust-lang/book/pull/1088
2. update to mdbook 0.1
Both of these things are big changes, so I want to land them now, well before the next branch, so we can kick the tires.
------------------------------
Locally, I'm seeing some weirdness around the reference and this:
Putting this PR up so others can try and build and see if it reproduces for them.
|
|
|
|
|
|
and improve printing of errors
|
|
|
|
Building on the work of # 45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement # 46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
|
|
|
|
Just a routine update
|
