summary refs log tree commit diff
path: root/src/librustc/session
AgeCommit message (Collapse)AuthorLines
2017-11-20Auto merge of #45905 - alexcrichton:add-wasm-target, r=aturonbors-1/+1
std: Add a new wasm32-unknown-unknown target 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". ### Building yourself First you'll need to configure the build of LLVM and enable this target ``` $ ./configure --target=wasm32-unknown-unknown --set llvm.experimental-targets=WebAssembly ``` Next you'll want to remove any previously compiled LLVM as it needs to be rebuilt with WebAssembly support. You can do that with: ``` $ rm -rf build ``` And then you're good to go! A `./x.py build` should give you a rustc with the appropriate libstd target. ### Test support 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](https://reviews.llvm.org/D39866) to get that working and will take some time. Relatively simple programs all seem to work though! In general I've only tested this with a local fork that makes use of LLVM 5 rather than our current LLVM 4 on master. The LLVM 4 WebAssembly backend AFAIK isn't broken per se but is likely missing bug fixes available on LLVM 5. I'm hoping though that we can decouple the LLVM 5 upgrade and adding this wasm target! ### But the modules generated are huge! 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!
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-1/+1
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!
2017-11-17Auto merge of #46004 - michaelwoerister:cached-mir-wip-3, r=nikomatsakisbors-0/+2
incr.comp.: Implement query result cache and use it to cache type checking tables. This is a spike implementation of caching more than LLVM IR and object files when doing incremental compilation. At the moment, only the `typeck_tables_of` query is cached but MIR and borrow-check will follow shortly. The feature is activated by running with `-Zincremental-queries` in addition to `-Zincremental`, it is not yet active by default. r? @nikomatsakis
2017-11-16incr.comp.: Remove default serialization implementations for things in ↵Michael Woerister-1/+1
rustc::hir::def_id so that we get an ICE instead of silently doing the wrong thing.
2017-11-16Rollup merge of #46005 - GuillaumeGomez:short-unstable, r=nrcGuillaume Gomez-2/+9
Set short-message feature unstable Fixes #45995. r? @nrc
2017-11-15Set short-message feature unstableGuillaume Gomez-2/+9
2017-11-14incr.comp.: Cache TypeckTables and add -Zincremental-queries flag.Michael Woerister-0/+2
2017-11-12deduplicate projection error (E0271) messagesZack M. Davis-2/+4
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain its `Copy` status (the present author's first choice having been the "EXXX" code as a string). The duplicated "type mismatch resolving `{}`" literal is unfortunate, but the `struct_span_err!` macro (which we want to mark that error code as used) is fussy about taking a literal, and the one-time-diagnostics set needs an owned string. This is concerning #33941 and probably #45805!
2017-11-10Make saturating u128 -> f32 casts the default behaviorRobin Kruppe-2/+2
... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts, this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly, and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799
2017-11-08Auto merge of #45867 - michaelwoerister:check-ich-stability, r=nikomatsakisbors-0/+2
incr.comp.: Verify stability of incr. comp. hashes and clean up various other things. The main contribution of this PR is that it adds the `-Z incremental-verify-ich` functionality. Normally, when the red-green tracking system determines that a certain query result has not changed, it does not re-compute the incr. comp. hash (ICH) for that query result because that hash is already known. `-Z incremental-verify-ich` tells the compiler to re-hash the query result and compare the new hash against the cached hash. This is a rather thorough way of - testing hashing implementation stability, - finding missing `[input]` annotations on `DepNodes`, and - finding missing read-edges, since both a missed read and a missing `[input]` annotation can lead to something being marked as green instead of red and thus will have a different hash than it should have. Case in point, implementing this verification logic and activating it for all `src/test/incremental` tests has revealed several such oversights, all of which are fixed in this PR. r? @nikomatsakis
2017-11-08Auto merge of #45205 - rkruppe:saturating-casts, r=eddybbors-0/+3
Saturating casts between integers and floats Introduces a new flag, `-Z saturating-float-casts`, which makes code generation for int->float and float->int casts safe (`undef`-free), implementing [the saturating semantics laid out by](https://github.com/rust-lang/rust/issues/10184#issuecomment-299229143) @jorendorff for float->int casts and overflowing to infinity for `u128::MAX` -> `f32`. Constant evaluation in trans was changed to behave like HIR const eval already did, i.e., saturate for u128->f32 and report an error for problematic float->int casts. Many thanks to @eddyb, whose APFloat port simplified many parts of this patch, and made HIR constant evaluation recognize dangerous float casts as mentioned above. Also thanks to @ActuallyaDeviloper whose branchless implementation served as inspiration for this implementation. cc #10184 #41799 fixes #45134
2017-11-07Saturating casts between integers and floats (both directions).Robin Kruppe-0/+3
This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-11-07Auto merge of #45822 - kennytm:rollup, r=kennytmbors-13/+35
Rollup of 9 pull requests - Successful merges: #45470, #45588, #45682, #45714, #45751, #45764, #45778, #45782, #45784 - Failed merges:
2017-11-07Rollup merge of #45782 - frewsxcv:frewsxcv-shorthands-helpers, r=manishearthkennytm-13/+35
Display all emission types in error msg if user inputs invalid option. before: ``` > rustc --emit foo error: unknown emission type: `foo` ``` after: ``` > rustc --emit foo error: unknown emission type: `foo` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info` ```
2017-11-07Auto merge of #45666 - Amanieu:tls-model, r=alexcrichtonbors-2/+14
Allow overriding the TLS model This PR adds the ability to override the default "global-dynamic" TLS model with a more specific one through a target json option or a command-line option. This allows for better code generation in certain situations. This is similar to the `-ftls-model=` option in GCC and Clang.
2017-11-07incr.comp.: Add -Zincremental-verify-ich, which allows to perform a ↵Michael Woerister-0/+2
consistency check for stored query result fingerprints.
2017-11-06Display all emission types in error msg if user inputs invalid option.Corey Farwell-13/+35
before: ``` > rustc --emit foo error: unknown emission type: `foo` ``` after: ``` > rustc --emit foo error: unknown emission type: `foo` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info` ```
2017-11-06Move tls-model to a -Z option since it is unstableAmanieu d'Antras-6/+6
2017-11-06Auto merge of #45737 - oli-obk:json, r=petrochenkovbors-62/+68
Pretty print json in ui tests I found the json output in one line to not be useful for reviewing r? @petrochenkov
2017-11-03Shorten paths to auxiliary files created by testsVadim Petrochenkov-1/+1
2017-11-03Update config.rsOliver Schneider-2/+2
2017-11-03Don't add a new -Z flag, reuse -Zunstable-optionsOliver Schneider-56/+54
2017-11-03Pretty print json in ui testsOliver Schneider-9/+17
2017-11-03Add support for specifying the TLS modelAmanieu d'Antras-1/+13
2017-11-02Make the difference between lint codes and error codes explicitOliver Schneider-8/+17
2017-10-30Auto merge of #45497 - mikhail-m1:dump-mir-graphviz, r=nikomatsakisbors-0/+4
add graphvis DOT files to dump mir directory r? @nikomatsakis
2017-10-30tweak the descriptionNiko Matsakis-1/+1
"in addition to" sounds better than "additionally to"
2017-10-28Auto merge of #45540 - virgil-palanciuc:master, r=estebankbors-4/+11
Avoid repetition on “use of unstable library feature 'rustc_private'” This PR fixes the error by only emitting it when the span contains a real file (is not inside a macro) - and making sure it's emitted only once per span. The first check was needed because spans-within-macros seem to differ a lot and "fixing" them to the real location is not trivial (and the method that does this is private to another module). It also feels like there always will be an error on import, with the real file name, so not sure there's a point to re-emit the same error at macro use. Fix #44953.
2017-10-28fixed tidy errorVirgil Palanciuc-2/+2
2017-10-28implemented code reviewVirgil Palanciuc-4/+11
2017-10-27Fix tidy error line longer than 100 charsLaurent Arnoud-1/+3
2017-10-27Quit immediately when current directory is invalidLaurent Arnoud-3/+4
Thanks-to: @kennytm
2017-10-26Use expect for current_dir on librustc/session modLaurent Arnoud-1/+3
2017-10-26add graphvis DOT files to dump mir directoryMikhail Modin-0/+4
2017-10-25fix #44953 - The “use of unstable library feature 'rustc_private'” error ↵Virgil Palanciuc-2/+2
is very repetitive
2017-10-25Auto merge of #44636 - GuillaumeGomez:little-error-msg, r=michaelwoeristerbors-13/+23
Add short error message-format Fixes #42653.
2017-10-24Introduce CrateDisambiguator newtype and fix testsIgor Matuszewski-8/+29
2017-10-23Use 128 bit instead of Symbol for crate disambiguatorIgor Matuszewski-7/+10
2017-10-20Add short message-formatGuillaume Gomez-13/+23
2017-10-17Rollup merge of #45097 - nivkner:fixme_fixup2, r=estebankkennytm-2/+0
address more FIXME whose associated issues were marked as closed part of #44366
2017-10-14Auto merge of #45102 - petrochenkov:noar, r=alexcrichtonbors-2/+1
cleanup: rustc doesn't use an external archiver cc https://github.com/rust-lang/rust/pull/45090 r? @alexcrichton
2017-10-13Auto merge of #45032 - alexcrichton:target-cfu, r=michaelwoeristerbors-45/+40
rustc: Allow target-specific default cgus Some targets, like msp430 and nvptx, don't work with multiple codegen units right now for bugs or fundamental reasons. To expose this allow targets to express a default. Closes #45000
2017-10-10Upgrade some comments to doc commentsOliver Schneider-27/+27
2017-10-09rustc: Allow target-specific default cgusAlex Crichton-45/+40
Some targets, like msp430 and nvptx, don't work with multiple codegen units right now for bugs or fundamental reasons. To expose this allow targets to express a default. Closes #45000
2017-10-09cleanup: rustc doesn't use an external archiverVadim Petrochenkov-2/+1
2017-10-09Auto merge of #45075 - alexcrichton:inline-less, r=michaelwoeristerbors-0/+2
rustc: Don't inline in CGUs at -O0 This commit tweaks the behavior of inlining functions into multiple codegen units when rustc is compiling in debug mode. Today rustc will unconditionally treat `#[inline]` functions by translating them into all codegen units that they're needed within, marking the linkage as `internal`. This commit changes the behavior so that in debug mode (compiling at `-O0`) rustc will instead only translate `#[inline]` functions into *one* codegen unit, forcing all other codegen units to reference this one copy. The goal here is to improve debug compile times by reducing the amount of translation that happens on behalf of multiple codegen units. It was discovered in #44941 that increasing the number of codegen units had the adverse side effect of increasing the overal work done by the compiler, and the suspicion here was that the compiler was inlining, translating, and codegen'ing more functions with more codegen units (for example `String` would be basically inlined into all codegen units if used). The strategy in this commit should reduce the cost of `#[inline]` functions to being equivalent to one codegen unit, which is only translating and codegen'ing inline functions once. Collected [data] shows that this does indeed improve the situation from [before] as the overall cpu-clock time increases at a much slower rate and when pinned to one core rustc does not consume significantly more wall clock time than with one codegen unit. One caveat of this commit is that the symbol names for inlined functions that are only translated once needed some slight tweaking. These inline functions could be translated into multiple crates and we need to make sure the symbols don't collideA so the crate name/disambiguator is mixed in to the symbol name hash in these situations. [data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911 [before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384
2017-10-09Auto merge of #45064 - alexcrichton:reduce-codegen-units, r=michaelwoeristerbors-2/+16
rustc: Reduce default CGUs to 16 Rationale explained in the included comment as well as #44941
2017-10-08Auto merge of #45012 - Gankro:noalias, r=arielb1bors-0/+2
Add -Zmutable-noalias flag We disabled noalias on mutable references a long time ago when it was clear that llvm was incorrectly handling this in relation to unwinding edges. Since then, a few things have happened: * llvm has cleaned up a bunch of the issues (I'm told) * we've added a nounwind codegen option As such, I would like to add this -Z flag so that we can evaluate if the codegen bugs still exist, and if this significantly affects the codegen of different projects, with an eye towards permanently re-enabling it (or at least making it a stable option).
2017-10-08Rollup merge of #45090 - rust-lang:petrochenkov-patch-1, r=alexcrichtonkennytm-1/+2
Document that `-C ar=PATH` doesn't do anything Are there any plans to use an external archiver in the future? IIRC, it was used before, but its use was replaced with LLVM's built-in archive management machinery. I can't found a relevant PR though. EDIT: Found it - https://github.com/rust-lang/rust/pull/26926! The `-C` option is stable so it still can't be removed right away even if there are no plans to use it (but maybe it can be deprecated?). Target specifications have a field for archiver as well, which is unused too (these ones are unstable, so I guess it can be removed). r? @alexcrichton
2017-10-07rustc: Don't inline in CGUs at -O0Alex Crichton-0/+2
This commit tweaks the behavior of inlining functions into multiple codegen units when rustc is compiling in debug mode. Today rustc will unconditionally treat `#[inline]` functions by translating them into all codegen units that they're needed within, marking the linkage as `internal`. This commit changes the behavior so that in debug mode (compiling at `-O0`) rustc will instead only translate `#[inline]` functions into *one* codegen unit, forcing all other codegen units to reference this one copy. The goal here is to improve debug compile times by reducing the amount of translation that happens on behalf of multiple codegen units. It was discovered in #44941 that increasing the number of codegen units had the adverse side effect of increasing the overal work done by the compiler, and the suspicion here was that the compiler was inlining, translating, and codegen'ing more functions with more codegen units (for example `String` would be basically inlined into all codegen units if used). The strategy in this commit should reduce the cost of `#[inline]` functions to being equivalent to one codegen unit, which is only translating and codegen'ing inline functions once. Collected [data] shows that this does indeed improve the situation from [before] as the overall cpu-clock time increases at a much slower rate and when pinned to one core rustc does not consume significantly more wall clock time than with one codegen unit. One caveat of this commit is that the symbol names for inlined functions that are only translated once needed some slight tweaking. These inline functions could be translated into multiple crates and we need to make sure the symbols don't collideA so the crate name/disambiguator is mixed in to the symbol name hash in these situations. [data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911 [before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 22:11:56 +0000