- 04 4月, 2018 1 次提交
-
-
由 Mark Simulacrum 提交于
In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
-
- 24 3月, 2018 1 次提交
-
-
由 Simon Sapin 提交于
Fixes #49215
-
- 23 3月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of adding custom sections to wasm artifacts in rustc. The intention here is to expose the ability of the wasm binary format to contain custom sections with arbitrary user-defined data. Currently neither our version of LLVM nor LLD supports this so the implementation is currently custom to rustc itself. The implementation here is to attach a `#[wasm_custom_section = "foo"]` attribute to any `const` which has a type like `[u8; N]`. Other types of constants aren't supported yet but may be added one day! This should hopefully be enough to get off the ground with *some* custom section support. The current semantics are that any constant tagged with `#[wasm_custom_section]` section will be *appended* to the corresponding section in the final output wasm artifact (and this affects dependencies linked in as well, not just the final crate). This means that whatever is interpreting the contents must be able to interpret binary-concatenated sections (or each constant needs to be in its own custom section). To test this change the existing `run-make` test suite was moved to a `run-make-fulldeps` folder and a new `run-make` test suite was added which applies to all targets by default. This test suite currently only has one test which only runs for the wasm target (using a node.js script to use `WebAssembly` in JS to parse the wasm output).
-
- 18 3月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit tweaks where timing and step information is printed out as part of the build, ensuring that we do it as close to the location where work happens as possible. In rustbuild various functions may perform long blocking work as dependencies are assembled, so if we print out timing information early on we may accidentally time more than just the step we were intending to time!
-
- 17 3月, 2018 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 09 3月, 2018 2 次提交
-
-
由 Alex Crichton 提交于
For LLD integration the path to `llvm-config` needed to change to inside the build directory itself (for whatever reason) but the build directory is different on MSBuild than it is on `ninja` for MSVC builds, so the path to `llvm-config.exe` was actually wrong and not working! This commit removes the `Build::llvm_config` function in favor of the source of truth, the `Llvm` build step itself. The build step was then updated to find the right build directory for MSBuild as well as `ninja` for where `llvm-config.exe` is located. Closes #48749
-
由 Mark Simulacrum 提交于
All uses are replaced with not accessing run.target/run.host, and instead directly using run.builder.build.build.
-
- 06 3月, 2018 1 次提交
-
-
由 Mark Mansi 提交于
-
- 04 3月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
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
-
- 24 2月, 2018 1 次提交
-
-
由 kennytm 提交于
-
- 23 2月, 2018 1 次提交
-
-
由 kennytm 提交于
The *.md at the root directory in src/doc are no longer tested, but this should be fine since all files there are deprecated.
-
- 18 2月, 2018 1 次提交
-
-
由 Matthias Krüger 提交于
-
- 17 2月, 2018 1 次提交
-
-
由 Guillaume Gomez 提交于
-
- 12 2月, 2018 1 次提交
-
-
由 Mark Simulacrum 提交于
Previously, a Step would be able to tell on its own when it was invoked "by-default" (that is, `./x.py test` was called instead of `./x.py test some/path`). This commit replaces that functionality, invoking each Step with each of the paths it has specified as "should be invoked by." For example, if a step calls `path("src/tools/cargo")` and `path("src/doc/cargo")` then it's make_run will be called twice, with "src/tools/cargo" and "src/doc/cargo." This makes it so that default handling logic is in builder, instead of spread across various Steps. However, this meant that some Step specifications needed to be updated, since for example `rustdoc` can be built by `./x.py build src/librustdoc` or `./x.py build src/tools/rustdoc`. A `PathSet` abstraction is added that handles this: now, each Step can not only list `path(...)` but also `paths(&[a, b, ...])` which will make it so that we don't invoke it with each of the individual paths, instead invoking it with the first path in the list (though this shouldn't be depended on). Future work likely consists of implementing a better/easier way for a given Step to work with "any" crate in-tree, especially those that want to run tests, build, or check crates in the std, test, or rustc crate trees. Currently this is rather painful to do as most of the logic is duplicated across should_run and make_run. It seems likely this can be abstracted away into builder somehow.
-
- 10 2月, 2018 1 次提交
-
-
由 Matthias Krüger 提交于
-
- 08 2月, 2018 3 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 04 2月, 2018 1 次提交
-
-
由 John Kåre Alsaker 提交于
-
- 31 1月, 2018 1 次提交
-
-
由 Diggory Blake 提交于
-
- 28 1月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
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.
-
- 24 1月, 2018 1 次提交
-
-
由 Mark Simulacrum 提交于
-
- 19 1月, 2018 1 次提交
-
-
由 Santiago Pastorino 提交于
-
- 17 1月, 2018 1 次提交
-
-
由 Michael Woerister 提交于
-
- 14 1月, 2018 1 次提交
-
-
由 Guillaume Gomez 提交于
-
- 13 1月, 2018 3 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 12 1月, 2018 1 次提交
-
-
由 O01eg 提交于
-
- 04 1月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
These no longer work now that Cargo changes the cwd of rustc while it's running. Instead use an absolute path that's set by rustbuild.
-
- 27 12月, 2017 2 次提交
-
-
由 kennytm 提交于
-
- 12 12月, 2017 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 06 12月, 2017 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 03 12月, 2017 1 次提交
-
-
由 kennytm 提交于
-
- 29 11月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
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.
-
- 20 11月, 2017 1 次提交
-
-
由 Alex Crichton 提交于
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
-
- 15 11月, 2017 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 20 10月, 2017 1 次提交
-
-
由 Mark Simulacrum 提交于
This makes it mandatory for other steps to have to handle the potential failure instead of failing in an odd way later down the road.
-
- 16 10月, 2017 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-