about summary refs log tree commit diff
path: root/src/librustc/session
AgeCommit message (Collapse)AuthorLines
2019-03-23Fixes #59361Peter Hall-6/+6
2019-03-23Auto merge of #58929 - estebank:elide-object, r=zackmdavisbors-0/+4
Elide object safety errors on non-existent trait function Fix #58734. r? @zackmdavis
2019-03-20Add a -Z time option which prints only passes which runs onceJohn Kåre Alsaker-0/+5
2019-03-16Rename `MetaItem::ident` to `MetaItem::path`Vadim Petrochenkov-1/+1
2019-03-16syntax: Do not accidentally treat multi-segment meta-items as single-segmentVadim Petrochenkov-1/+2
2019-03-15Elide object safety errors on non-existent trait functionEsteban Küber-0/+4
Fix #58734.
2019-03-14Add `-Z allow_features=...` flagTyler Mandry-0/+6
2019-03-14Add support for comma-separated option listsTyler Mandry-0/+13
2019-03-13Use derive macro for HashStableJohn Kåre Alsaker-1/+2
2019-03-10Make the rustc driver and interface demand drivenJohn Kåre Alsaker-24/+30
2019-03-08Rollup merge of #58984 - estebank:multi-treat-err-as-bug, r=oli-obkPietro Albini-5/+14
Teach `-Z treat-err-as-bug` to take a number of errors to emit `-Z treat-err-as-bug` will cause `rustc` to panic after the first error is reported, like previously. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 2 errors have been reported. Fix #58983.
2019-03-07Update treat-err-as-bug help textEsteban Küber-1/+1
2019-03-07Keep current behavior while accepting error countEsteban Küber-2/+11
2019-03-06Fix incorrect defaultEsteban Kuber-1/+1
2019-03-06Make `-Z treat-err-as-bug` take a number of errors to be emittedEsteban Küber-4/+4
`-Z treat-err-as-bug=0` will cause `rustc` to panic after the first error is reported. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 3 errors have been reported.
2019-03-05Allow linking to a proc macro on the target in metadata and still use a host ↵John Kåre Alsaker-0/+3
proc macro to execute them
2019-03-03Remove profiler output and replace with a raw event dumpWesley Wiser-7/+2
Related to #58372
2019-03-03Wrap the self-profiler in an `Arc<Mutex<>>`Wesley Wiser-24/+22
This will allow us to send it across threads and measure things like LLVM time.
2019-03-01Add support for using a jobserver with RayonJohn Kåre Alsaker-27/+3
2019-02-28Introduce rustc_interface and move some methods thereJohn Kåre Alsaker-43/+73
2019-02-14Rollup merge of #58378 - alexcrichton:incremental-lto, r=michaelwoeristerMazdak Farrokhzad-15/+1
rustc: Implement incremental "fat" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-14Rollup merge of #58365 - Zoxc:task-status, r=michaelwoeristerMazdak Farrokhzad-0/+2
Add an option to print the status of incremental tasks / dep nodes after running them r? @michaelwoerister
2019-02-13Rollup merge of #58273 - taiki-e:rename-dependency, r=matthewjasperMazdak Farrokhzad-4/+3
Rename rustc_errors dependency in rust 2018 crates I think this is a better solution than `use rustc_errors as errors` in `lib.rs` and `use crate::errors` in modules. Related: rust-lang/cargo#5653 cc #58099 r? @Centril
2019-02-13Rollup merge of #58057 - michaelwoerister:stabilize-xlto, r=alexcrichtonMazdak Farrokhzad-22/+24
Stabilize linker-plugin based LTO (aka cross-language LTO) This PR stabilizes [linker plugin based LTO](https://github.com/rust-lang/rust/issues/49879), also known as "cross-language LTO" because it allows for doing inlining and other optimizations across language boundaries in mixed Rust/C/C++ projects. As described in the tracking issue, it works by making `rustc` emit LLVM bitcode instead of machine code, the same as `clang` does. A linker with the proper plugin (like LLD) can then run (Thin)LTO across all modules. The feature has been implemented over a number of pull requests and there are various [codegen](https://github.com/rust-lang/rust/blob/master/src/test/codegen/no-dllimport-w-cross-lang-lto.rs) and [run](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-clang)-[make](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs) [tests](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto) that make sure that it keeps working. It also works for building big projects like [Firefox](https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ce2d5ddcea6fbff790503eac406954e469b2f5d). The PR makes the feature available under the `-C linker-plugin-lto` flag. As discussed in the tracking issue it is not cross-language specific and also not LLD specific. `-C linker-plugin-lto` is descriptive of what it does. If someone has a better name, let me know `:)`
2019-02-13Rename rustc_errors dependency in rust 2018 cratesTaiki Endo-4/+3
2019-02-12Stabilize linker-plugin based LTO.Michael Woerister-22/+24
2019-02-12rustc: Implement incremental "fat" LTOAlex Crichton-15/+1
Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-02-11Add an option to print the status of incremental tasks / dep nodes after ↵John Kåre Alsaker-0/+2
running them
2019-02-10rustc: doc commentsAlexander Regueiro-20/+20
2019-02-07Auto merge of #58010 - Zoxc:parallel-passes, r=michaelwoeristerbors-2/+2
Move privacy checking later in the pipeline and make some passes run in parallel r? @michaelwoerister
2019-02-07Rollup merge of #58193 - mark-i-m:rustc-2018, r=Centrilkennytm-32/+32
Move librustc to 2018 r? @Centril Part of #58099 It would be great to get this reviewed quickly to avoid merge conflicts...
2019-02-06Auto merge of #56123 - oli-obk:import_miri_from_future, r=eddybbors-0/+2
Add a forever unstable opt-out of const qualification checks r? @eddyb cc @RalfJung @Centril basically a forever unstable way to screw with const things in horribly unsafe, unsound and incoherent ways. Note that this does *not* affect miri except by maybe violating assumptions that miri makes. But there's no change in how miri evaluates things.
2019-02-05move librustc to 2018Mark Mansi-32/+32
2019-02-01Cleanup unecessary codeAaron Hill-10/+0
2019-02-01Replace --extern-public with --extern-privateAaron Hill-20/+21
2019-02-01Tidy fixesAaron Hill-1/+1
2019-02-01Move --extern-public behind -Z unstable-optionsAaron Hill-17/+22
2019-02-01Track extern_public command-line argumentAaron Hill-5/+5
2019-02-01Clippy fixes, rename stuff to match RFCAaron Hill-1/+1
2019-02-01Always treat 'std' and 'core' as publicAaron Hill-1/+5
2019-02-01Initial implementation workAaron Hill-0/+24
2019-01-31Add a forever unstable opt-out of const qualification checksOliver Scherer-0/+2
2019-01-30Move privacy checking later in the pipeline and make some passes run in parallelJohn Kåre Alsaker-2/+2
2019-01-28Use multiple threads by default. Limits tests to one thread. Do some renaming.John Kåre Alsaker-12/+12
2019-01-26remove `_with_applicability` from suggestion fnsAndy Russell-1/+1
2019-01-26Auto merge of #57726 - Zoxc:combine-early-lints, r=estebankbors-0/+2
Combine all builtin early lints This also adds a -Z no-interleave-lints option to allow benchmarking lints. r? @estebank
2019-01-24Implement optimize(size) and optimize(speed)Simonas Kazlauskas-0/+2
2019-01-19Rollup merge of #57598 - h-michael:unpretty-help, r=oli-obkMazdak Farrokhzad-2/+7
Add missing unpretty option help message There are some missing help messages that is printed `ructc -Zunpretty help` and receiving invalid option. related with #16419, #45721, #21085, #31916
2019-01-19Rollup merge of #57573 - Xanewok:querify-entry-fn, r=ZoxcMazdak Farrokhzad-8/+4
Querify `entry_fn` Analogous to https://github.com/rust-lang/rust/pull/57570 but this will also require few fixups in Miri so I decided to separate that (and it seems [CI doesn't let us break tools anymore](https://github.com/rust-lang/rust/pull/57392#issuecomment-453801540)? Or was that because it was a rollup PR?) r? @nikomatsakis
2019-01-19Rollup merge of #57268 - peterhj:peterhj-optmergefunc, r=nagisaMazdak Farrokhzad-4/+24
Add a target option "merge-functions", and a corresponding -Z flag (works around #57356) This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified. This works around https://github.com/rust-lang/rust/issues/57356. cc @eddyb @japaric @oli-obk @nox @nagisa Also thanks to @denzp and @gnzlbg for discussing this on rust-cuda! ### Motivation Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 [1], and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler `ptxas`). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does. ### Related work The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 [1], and also to enable the use of function aliases within MergeFunctions [2] [3]. MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash [4], which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below. clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default. ### Examples/more details Consider an example Rust lib using `extern "ptx-kernel"` functions: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore.rs. If we try to compile this with nightly rustc, we get the following compiler error: LLVM ERROR: Module has aliases, which NVPTX does not support. This error happens because: (1) functions `foo` and `bar` have the same body, so are candidates to be merged by MergeFunctions; and (2) rustc configures MergeFunctions to generate function aliases using the "mergefunc-use-aliases" LLVM option [2] [3], but the NVPTX backend does not support those aliases. Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with `ptxas` (I'm on the CUDA 9.2 toolchain), we get an assembler error: ptxas nocore-mergefunc-nousealiases-bad.ptx, line 38; error : Illegal call target, device function expected ptxas fatal : Ptx assembly aborted due to errors What's happening is that MergeFunctions rewrites the `bar` function to call `foo`. However, directly calling an `extern "ptx-kernel"` function from another `extern "ptx-kernel"` is wrong. If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx [1] https://github.com/rust-lang/rust/blob/a36b960df626cbb8bea74f01243318b73f0bd201/src/librustc_codegen_ssa/back/write.rs#L155 [2] https://github.com/rust-lang/rust/blob/a36b960df626cbb8bea74f01243318b73f0bd201/src/librustc_codegen_llvm/llvm_util.rs#L64 [3] https://github.com/rust-lang/rust/pull/56358 [4] https://github.com/rust-lang/rust/pull/49479
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 23:36:49 +0000