This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes#46819
If a PR intends to update a tool but its test has failed, abort the merge
regardless of current channel. This should help the tool maintainers if the
update turns out to be failing due to changes in latest master.
[auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation
This PR consists of 3 commits.
1. (Steps 4–6) The `toolstate.json` output previously collected is now pushed to the https://github.com/rust-lang-nursery/rust-toolstate repository.
2. (Step 7) Revert commit ab018c7, thus removing all traces of `BuildExpectation` and `toolstate.toml`.
3. (Step 8) Adjust CONTRIBUTION.md for the new procedure.
These are the last steps of #45861. After this PR, the toolstate will be automatically computed and published to https://rust-lang-nursery.github.io/rust-toolstate/. There is no need to manage toolstate.toml again.
Closes#45861.
Validate miri against the HIR const evaluator
r? @eddyb
cc @alexcrichton @arielb1 @RalfJung
The interesting parts are the last few functions in `librustc_const_eval/eval.rs`
* We warn if miri produces an error while HIR const eval does not.
* We warn if miri produces a value that does not match the value produced by HIR const eval
* if miri succeeds and HIR const eval fails, nothing is emitted, but we still return the HIR error
* if both error, nothing is emitted and the HIR const eval error is returned
So there are no actual changes, except that miri is forced to produce the same values as the old const eval.
* This does **not** touch the const evaluator in trans at all. That will come in a future PR.
* This does **not** cause any code to compile that didn't compile before. That will also come in the future
It would be great if someone could start a crater run if travis passes
Revert #46360, re-enable macOS dist images.
This PR reverts #46360, which disabled all macOS dist images to workaround travis-ci/travis-ci#8821.
This PR should be merged as soon as the Travis bug has been fixed.
Closes#46357.
cc @rust-lang/infra
Deploy builds both with asserts enabled and asserts disabled to CI.
This also removes uploads to the 'try' bucket, and instead dumps
everything into the two rustc-builds and rustc-builds-alt buckets. This
makes lives easier, as there is only one location for a given "type" of
build, and since we have the git commit hash in the filenames, this is
fine; we won't run into uploads of the same commit.
cc @aidanhs -- this will break crater's logic for downloading `try#xxx` commits since the try bucket won't be uploaded into
r? @alexcrichton
This also removes uploads to the 'try' bucket, and instead dumps
everything into the two rustc-builds and rustc-builds-alt buckets. This
makes lives easier, as there is only one location for a given "type" of
build, and since we have the git commit hash in the filenames, this is
fine; we won't run into uploads of the same commit.
This commit allocates a builder to running wasm32 tests on Travis. Not all test
suites pass right now so this is starting out with just the run-pass and the
libcore test suites. This'll hopefully give us a pretty broad set of coverage
for integration in rustc itself as well as a somewhat broad coverage of the llvm
backend itself through integration/unit tests.
Looks like Travis [has announced][blog] that our current `xcode8.2` image is
being deprecated and the recommended Xcode 7 image is `xcode7.3`. This updates
us to these ahead of time to make sure we can shake out any bugs, if any.
[blog]: https://blog.travis-ci.com/2017-10-16-a-new-default-os-x-image-is-coming
ci: Upload/download from a new S3 bucket
Moving buckets from us-east-1 to us-west-1 because us-west-1 is where
rust-central-station itself runs and in general is where we have all our other
buckets.
ci: Disable rustc debug assertions on OSX
This commit disables debug assertions for OSX in an effort to improve cycle time
on OSX. It looks like #44610 didn't shave off quite as much time as desired so
let's see how much this helps.
This commit disables debug assertions for OSX in an effort to improve cycle time
on OSX. It looks like #44610 didn't shave off quite as much time as desired so
let's see how much this helps.
Make use of Travis's conditional jobs.
Conditional jobs: https://docs.travis-ci.com/user/conditional-builds-stages-jobs/#Conditional-Jobs.
Jobs not matching the condition will not be scheduled at all. This allows us to get rid of `$ALLOW_PR`/`$ALLOW_TRY`/`$SKIP_BUILD` in `.travis.yml`, and perfectly prevent spurious PR failures due to flaky macOS machines.
travis: Move sccache to the us-west-1 region
Most of the other rust-lang buckets are in us-west-1 and I think the original
bucket was just accidentally created in the us-east-1 region. Let's consolidate
by moving it to the same location as the rest of our buckets.
Moving buckets from us-east-1 to us-west-1 because us-west-1 is where
rust-central-station itself runs and in general is where we have all our other
buckets.
Our OSX builders are routinely and significantly over hour 2 hour "soft limit"
for testing PRs. I *think* that a big portion of this time comes from the fact
that LLVM and debug assertions are enabled. In an effort to speed up these
builders and reduce cycle time this commit disables LLVM assertions on OSX for
all builders.
My thinking is that we'll let this bake for a bit after merged to see what the
effect is on timing on Travis. If it doesn't actually help much we can turn them
back on, and if it doesn't help enough we can disable Rust debug assertions as
well.
Most of the other rust-lang buckets are in us-west-1 and I think the original
bucket was just accidentally created in the us-east-1 region. Let's consolidate
by moving it to the same location as the rest of our buckets.
Fix sanitizer tests on buggy kernels
Travis recently pushed an update to the Linux environments, namely the kernels
that we're running on. This in turn caused some of the sanitizer tests we run to
fail. We also apparently weren't the first to hit these failures! Detailed in
google/sanitizers#837 these tests were failing due to a specific commit in the
kernel which has since been backed out, but for now work around the buggy kernel
that's deployed on Travis and eventually we should be able to remove these
flags.
Travis recently pushed an update to the Linux environments, namely the kernels
that we're running on. This in turn caused some of the sanitizer tests we run to
fail. We also apparently weren't the first to hit these failures! Detailed in
google/sanitizers#837 these tests were failing due to a specific commit in the
kernel which has since been backed out, but for now work around the buggy kernel
that's deployed on Travis and eventually we should be able to remove these
flags.
Alex Crichton