about summary refs log tree commit diff
path: root/src/librustc/session
AgeCommit message (Collapse)AuthorLines
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
2017-10-08address more FIXME whose associated issues were marked as closedNiv Kaminer-2/+0
update FIXME(#6298) to point to open issue 15020 update FIXME(#6268) to point to RFC 811 update FIXME(#10520) to point to RFC 1751 remove FIXME for emscripten issue 4563 and include target in `test_estimate_scaling_factor` remove FIXME(#18207) since node_id isn't used for `ref` pattern analysis remove FIXME(#6308) since DST was implemented in #12938 remove FIXME(#2658) since it was decided to not reorganize module remove FIXME(#20590) since it was decided to stay conservative with projection types remove FIXME(#20297) since it was decided that solving the issue is unnecessary remove FIXME(#27086) since closures do correspond to structs now remove FIXME(#13846) and enable `function_sections` for windows remove mention of #22079 in FIXME(#22079) since this is a general FIXME remove FIXME(#5074) since the restriction on borrow were lifted
2017-10-07Document that `-C ar=PATH` doesn't do anythingVadim Petrochenkov-1/+2
2017-10-07rustc: Implement ThinLTOAlex Crichton-14/+6
This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. "Thin" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is, we won't load upstream rlibs, but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode, like full LTO today, we'll optimize all upstream dependencies in "thin" mode. Unlike today, however, this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from, but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy, but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO, as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation, where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!
2017-10-06rustc: Reduce default CGUs to 16Alex Crichton-2/+16
Rationale explained in the included comment as well as #44941
2017-10-05Auto merge of #44940 - philipc:remap-path, r=michaelwoeristerbors-3/+1
Don't use remapped path when loading modules and include files Fixes bug reported in https://github.com/rust-lang/rust/issues/41555#issuecomment-327866056. cc @michaelwoerister
2017-10-03Add -Zmutable-noalias flagAlexis Beingessner-0/+2
2017-09-30rustc: Enable LTO and multiple codegen unitsAlex Crichton-18/+0
This commit is a refactoring of the LTO backend in Rust to support compilations with multiple codegen units. The immediate result of this PR is to remove the artificial error emitted by rustc about `-C lto -C codegen-units-8`, but longer term this is intended to lay the groundwork for LTO with incremental compilation and ultimately be the underpinning of ThinLTO support. The problem here that needed solving is that when rustc is producing multiple codegen units in one compilation LTO needs to merge them all together. Previously only upstream dependencies were merged and it was inherently relied on that there was only one local codegen unit. Supporting this involved refactoring the optimization backend architecture for rustc, namely splitting the `optimize_and_codegen` function into `optimize` and `codegen`. After an LLVM module has been optimized it may be blocked and queued up for LTO, and only after LTO are modules code generated. Non-LTO compilations should look the same as they do today backend-wise, we'll spin up a thread for each codegen unit and optimize/codegen in that thread. LTO compilations will, however, send the LLVM module back to the coordinator thread once optimizations have finished. When all LLVM modules have finished optimizing the coordinator will invoke the LTO backend, producing a further list of LLVM modules. Currently this is always a list of one LLVM module. The coordinator then spawns further work to run LTO and code generation passes over each module. In the course of this refactoring a number of other pieces were refactored: * Management of the bytecode encoding in rlibs was centralized into one module instead of being scattered across LTO and linking. * Some internal refactorings on the link stage of the compiler was done to work directly from `CompiledModule` structures instead of lists of paths. * The trans time-graph output was tweaked a little to include a name on each bar and inflate the size of the bars a little
2017-09-30Don't use remapped path when loading modules and include filesPhilip Craig-3/+1
2017-09-29Auto merge of #44853 - alexcrichton:debug-codegen-units, r=michaelwoeristerbors-28/+69
rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode, typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit, gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things, using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above, but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This, however, doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized, but stay tuned if you're interested in that aspect!
2017-09-28Update to the `cc` crateAlex Crichton-14/+14
This is the name the `gcc` crate has moved to
2017-09-26rustc: Default 32 codegen units at O0Alex Crichton-28/+69
This commit changes the default of rustc to use 32 codegen units when compiling in debug mode, typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit, gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things, using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above, but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This, however, doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized, but stay tuned if you're interested in that aspect!
2017-09-23incr.comp.: Remove support for loading metadata fingerprints.Michael Woerister-1/+1
2017-09-23Rollup merge of #44717 - ↵Corey Farwell-1/+2
pnkfelix:debugflags-borrowckmir-implies-emitendregions, r=arielb1 Make `-Z borrowck-mir` imply that `EndRegion`'s should be emitted. Before this change, the `-Z borrowck-mir` flag is useless if you do not also pass `-Z emit-end-regions`. So, in the same spirit as f2892ad281cb11421ebae741d698e0af14d3ecf6, make `-Z borrowck-mir` also emit `EndRegion` statements. (This will hopefully avoid some initial speed bumps for new-comers helping out with NLL.)
2017-09-21Auto merge of #44627 - zackmdavis:the_capgate_perogative, r=nrcbors-3/+7
`--cap-lints allow` switches off `can_emit_warnings` This boolean field on the error `Handler` is toggled to silence warnings when `-A warnings` is passed. (This is actually a separate mechanism from the global lint level—whether there's some redundancy to be factored away here is an important question, but not one we concern ourselves with in this commit.) But the same rationale applies for `--cap-lints allow`. In particular, this makes the "soft" feature-gate warning introduced in 8492ad24 (which is not a lint, but just calls `struct_span_warn`) not pollute the builds of dependent crates. Thanks to @kennytm for pointing out the potential of `can_emit_warnings` for this purpose. Resolves #44213.
2017-09-20Make `-Z borrowck-mir` imply that `EndRegion`'s should be emitted.Felix S. Klock II-1/+2
2017-09-19Fix a typo in rustc help menuBob Sun-1/+1
Change from native-static-deps to native-static-libs.
2017-09-18Rollup merge of #44548 - oyvindln:rustc_help_fix, r=arielb1Alex Crichton-3/+3
Add proper help line for `-C inline threshold` Looks like someone accidentally some words when adding this. This also remove a period on a different help line for consistency, as no options have a period.
2017-09-18incr.comp.: Fix rebase fallout.Michael Woerister-0/+33
2017-09-16`--cap-lints allow` switches off `can_emit_warnings`Zack M. Davis-3/+7
This boolean field on the error `Handler` is toggled to silence warnings when `-A warnings` is passed. (This is actually a separate mechanism from the global lint level—whether there's some redundancy to be factored away here is an important question, but not one we concern ourselves with in this commit.) But the same rationale applies for `--cap-lints allow`. In particular, this makes the "soft" feature-gate warning introduced in 8492ad24 (which is not a lint, but just calls `struct_span_warn`) not pollute the builds of dependent crates. Thanks to @kennytm for pointing out the potential of `can_emit_warnings` for this purpose. Resolves #44213.
2017-09-14rustc: Remove `Session::dep_graph`Alex Crichton-21/+34
This commit removes the `dep_graph` field from the `Session` type according to issue #44390. Most of the fallout here was relatively straightforward and the `prepare_session_directory` function was rejiggered a bit to reuse the results in the later-called `load_dep_graph` function. Closes #44390
2017-09-13Remove the other period and start with lowercase for more consistencyoyvindln-2/+2
2017-09-13Add proper help line for inline thresholdoyvindln-2/+2
Also remove a period on a different help line for consistency
2017-09-12Remove the `cstore` reference from Session in order to prepare encapsulating ↵Michael Woerister-22/+9
CrateStore access in tcx.
2017-09-11rustc: replace usize with u64 and ConstUsize.Eduard-Mihai Burtescu-5/+5
2017-09-05Emit `EndRegion` statements when given `-Z mir-emit-validate=N` (for N > 0).Felix S. Klock II-0/+4
This way the miri test suite does not have to be updated to explcitly request `-Z emit-end-regions`.
2017-09-05Skip EndRegion emission by default. Use `-Z emit-end-regions` to reenable it.Felix S. Klock II-0/+2
The main intent is to fix cases where EndRegion emission is believed to be causing excess peak memory pressure. It may also be a welcome change to people inspecting the MIR output who find the EndRegions to be a distraction.
2017-09-04Auto merge of #43067 - pornel:libdeps, r=nrcbors-1/+3
Compact display of static lib dependencies Fixes #33173 Instead of displaying one dependency per line, I've changed the format to display them all in one line. As a bonus they're in format of linker flags (`-lfoo`), so the output can be copy&pasted if one is actually going to link as suggested.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-04 06:28:14 +0000