| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
|
|
This hack has long since outlived its usefulness; the transition to
trans passing around full substitutions is basically done. Instead of
`ErasedRegions`, just supply substitutions with a suitable number of
`'static` entries, and invoke `erase_regions` when needed (the latter of
which we already do).
|
|
|
|
|
|
|
|
|
|
This is roughly the same as my previous PR that created a dependency graph, but that:
1. The dependency graph is only optionally constructed, though this doesn't seem to make much of a difference in terms of overhead (see measurements below).
2. The dependency graph is simpler (I combined a lot of nodes).
3. The dependency graph debugging facilities are much better: you can now use `RUST_DEP_GRAPH_FILTER` to filter the dep graph to just the nodes you are interested in, which is super help.
4. The tests are somewhat more elaborate, including a few known bugs I need to fix in a second pass.
This is potentially a `[breaking-change]` for plugin authors. If you are poking about in tcx state or something like that, you probably want to add `let _ignore = tcx.dep_graph.in_ignore();`, which will cause your reads/writes to be ignored and not affect the dep-graph.
After this, or perhaps as an add-on to this PR in some cases, what I would like to do is the following:
- [x] Write-up a little guide to how to use this system, the debugging options available, and what the possible failure modes are.
- [ ] Introduce read-only and perhaps the `Meta` node
- [x] Replace "memoization tasks" with node from the map itself
- [ ] Fix the shortcomings, obviously! Notably, the HIR map needs to register reads, and there is some state that is not yet tracked. (Maybe as a separate PR.)
- [x] Refactor the dep-graph code so that the actual maintenance of the dep-graph occurs in a parallel thread, and the main thread simply throws things into a shared channel (probably a fixed-size channel). There is no reason for dep-graph construction to be on the main thread. (Maybe as a separate PR.)
Regarding performance: adding this tracking does add some overhead, approximately 2% in my measurements (I was comparing the build times for rustdoc). Interestingly, enabling or disabling tracking doesn't seem to do very much. I want to poke at this some more and gather a bit more data -- in some tests I've seen that 2% go away, but on others it comes back. It's not entirely clear to me if that 2% is truly due to constructing the dep-graph at all.
The next big step after this is write some code to dump the dep-graph to disk and reload it.
r? @michaelwoerister
|
|
|
|
|
|
tests & rustdoc still broken
|
|
rustdoc still broken
|
|
|
|
|
|
[breaking change]
|
|
|
|
|
|
|
|
|
|
|
|
rlib sizes:
1445222 liballoc_jemalloc-bb943c5a.rlib
10664 liballoc_system-bb943c5a.rlib
143592 libarena-bb943c5a.rlib
3639102 libcollections-bb943c5a.rlib
16316910 libcore-bb943c5a.rlib
214154 libflate-bb943c5a.rlib
231440 libfmt_macros-bb943c5a.rlib
536976 libgetopts-bb943c5a.rlib
209672 libgraphviz-bb943c5a.rlib
408008 liblibc-bb943c5a.rlib
189610 liblog-bb943c5a.rlib
662184 librand-bb943c5a.rlib
605112 librbml-bb943c5a.rlib
1397820 librustc_back-bb943c5a.rlib
38383772 librustc-bb943c5a.rlib
12842 librustc_bitflags-bb943c5a.rlib
2297822 librustc_borrowck-bb943c5a.rlib
571064 librustc_data_structures-bb943c5a.rlib
9356542 librustc_driver-bb943c5a.rlib
9477226 librustc_front-bb943c5a.rlib
1605698 librustc_lint-bb943c5a.rlib
77111720 librustc_llvm-bb943c5a.rlib
4783848 librustc_mir-bb943c5a.rlib
3534256 librustc_platform_intrinsics-bb943c5a.rlib
593038 librustc_privacy-bb943c5a.rlib
3122202 librustc_resolve-bb943c5a.rlib
14185212 librustc_trans-bb943c5a.rlib
11940328 librustc_typeck-bb943c5a.rlib
1634264 librustc_unicode-bb943c5a.rlib
15564160 librustdoc-bb943c5a.rlib
8153964 libstd-bb943c5a.rlib
30589338 libsyntax-bb943c5a.rlib
897110 libterm-bb943c5a.rlib
1360662 libtest-bb943c5a.rlib
|
|
paths, and construct paths for all definitions. Also, stop rewriting
DefIds for closures, and instead just load the closure data from
the original def-id, which may be in another crate.
|
|
they are being used as an opaque "position identifier"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
closure types.
|
|
|
|
consts.
|
|
into MethodTraitItem.
|
|
|
|
|
|
|
|
Many of the modifications putting in `Box::new` calls also include a
pointer to Issue 22405, which tracks going back to `box <expr>` if
possible in the future.
(Still tried to use `Box<_>` where it sufficed; thus some tests still
have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.)
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
|
|
|
|
This matches contemporary Rust style.
|
|
|
|
|
|
memory usage significantly and opens opportunities for more parallel compilation.
|