- 24 12月, 2020 28 次提交
-
-
由 bors 提交于
Added better error message for shared borrow treated as unique for purposes of lifetimes Part of Issue #76630 r? `@jyn514`
-
由 bors 提交于
update rustfmt to v1.4.30 Contains fixes for a few reported bugs on current nightly (1.4.29) Notes in: https://github.com/rust-lang/rustfmt/releases/tag/v1.4.30
-
由 bors 提交于
rustc_query_system: reduce dependency graph memory usage This change implements, at a high level, two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node, we know whether that node is new (not in the previous graph) or not, and if not, the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph, so for that piece of node data, we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint`, so we can avoid duplicating that too. Finally, we distinguish between "light" and "dark" green nodes, where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph, because we know that their set of dependencies is the same (technically, light green and red nodes can have the same dependencies too, but we don't try to figure out whether or not that's the case). Also, some effort is made to pack data tightly, and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation, as in the `SerializedDepGraph`, that is, in a single vector, rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is, at minimum, 40 bytes, and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges, then 32 bytes are used for edges, and the overhead is 8 bytes. But most of the time, the overhead is higher. In contrast, using a single vector to store all edges, and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector, whereas before, we could just take ownership over them. However, we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.
-
由 bors 提交于
BTreeMap: relax the explicit borrow rule to make code shorter and safer Expressions like `.reborrow_mut().into_len_mut()` are annoyingly long, and kind of dangerous for the reason `reborrow_mut()` is unsafe. By relaxing the single rule, we no longer have to make an exception for functions with a `borrow` name and functions like `as_leaf_mut`. This is largely restoring the declaration style of the btree::node API about a year ago, but with more explanation and consistency. r? `@Mark-Simulacrum`
-
由 bors 提交于
Refactor dist tarballs generation Before this PR, each tarball we ship as part of a release was generated by manually creating the directory structure and invoking `rust-installer generate`. This means each tarball was slightly different, adding new ones meant copy-pasting the code generating another tarball and removing the useless parts, and more importantly refactoring how tarballs are generated is extremely time-consuming. This PR introduces a new abstraction in rustbuild, `Tarball`. The `Tarball` struct provides a trivial API to generate simple tarballs, and can get out of the way when more complex tarballs have to generate. For example, the whole code to generate the `build-manifest` tarball is now the following: ```rust let tarball = Tarball::new(builder, "build-manifest", &self.target.triple); tarball.add_file(&build_manifest, "bin", 0o755); tarball.generate() ``` One notable change between the old tarballs and the new ones is that the "overlay" (README.md, COPYRIGHT, LICENSE-APACHE and LICENSE-MIT) is now available in every produced tarball, while before each tarball inconsistently had or didn't have those files. Tarballs that need a different overlay have a way to change which files to include (with the `set_overlay` method): ```rust let mut tarball = Tarball::new(builder, "rustfmt", &target.triple); tarball.set_overlay(OverlayKind::Rustfmt); tarball.add_file(rustfmt, "bin", 0o755); tarball.add_file(cargofmt, "bin", 0o755); tarball.add_legal_and_readme_to("share/doc/rustfmt"); Some(tarball.generate()) ``` The PR should be reviewed commit-by-commit, as each commit migrated a separate tarball to use `Tarball`. During development i made sure every tarball can still be generated, and for the most compex tarballs I manually ensured the list of files between the old and new tarballs did not have unexpected changes. r? `@Mark-Simulacrum`
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
由 Pietro Albini 提交于
-
- 23 12月, 2020 12 次提交
-
-
由 bors 提交于
Clippy: Revert change from last sync r? `@Manishearth` cc `@ebroto` Note that the commit e8980155 doesn't exist like this in the Clippy repo. I didn't want to do a full sync, because this would've included at least one new lint, which I wanted to avoid a week before beta is branched. This just reverts one commit from the last sync.
-
由 bors 提交于
Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling, including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment, implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary, but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore, cargo (and its dependencies), and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial, but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI, though, so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least, giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR, up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially, in the future, on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others)
-
由 flip1995 提交于
-
由 Philipp Krones 提交于
-
由 bors 提交于
Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find, and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand, very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes, but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.
-
由 bors 提交于
Remove `DefPath` from `Visibility` and calculate it on demand Depends on #80090 and should not be merged before. Helps with https://github.com/rust-lang/rust/issues/79103 and https://github.com/rust-lang/rust/issues/76382. cc https://github.com/rust-lang/rust/pull/80014#issuecomment-746810284 - `@nnethercote` I figured it out! It was simpler than I expected :) This brings the size of `clean::Visibility` down from 40 bytes to 8. Note that this does *not* remove `clean::Visibility`, even though it's now basically the same as `ty::Visibility`, because the `Invsible` variant means something different from `Inherited` and I thought it would be be confusing to merge the two. See the new comments on `impl Clean for ty::Visibility` for details.
-
由 bors 提交于
[rustdoc] Calculate stability, const_stability, and deprecation on-demand Previously, they would always be calculated ahead of time, which bloated the size of `clean::Item`. Builds on https://github.com/rust-lang/rust/pull/80090 and should not be merged before. Helps with https://github.com/rust-lang/rust/issues/79103 and https://github.com/rust-lang/rust/issues/76382. cc https://github.com/rust-lang/rust/pull/80014#issuecomment-746810284 This brings `Item` down to 568 bytes, down from 616.
-
由 bors 提交于
Rollup of 17 pull requests Successful merges: - #80136 (Add test for issue #74824) - #80203 (Edit rustc_middle::lint::LintSource docs) - #80204 (docs: Edit rustc_middle::ty::query::on_disk_cache) - #80219 (Fix labels for 'Library Tracking Issue' template) - #80222 (Fix rustc-std-workspace-core documentation) - #80223 (docs: Fix outdated crate reference) - #80225 (Add module-level docs to rustc_middle::ty) - #80241 (Fix typo) - #80248 (Remove `I-prioritize` from Zulip topic) - #80266 (Remove redundant test) - #80272 (rustc_span: Provide a reserved identifier check for a specific edition) - #80285 (Update books) - #80286 (docs: Edit rustc_middle::middle::privacy) - #80297 (Add some intra-doc links to compiler docs) - #80298 (Improve the code quality by using matches macro) - #80299 (Turn helper method into a closure) - #80302 (docs: Update rustc_middle::middle::region::ScopeTree) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Guillaume Gomez 提交于
docs: Update rustc_middle::middle::region::ScopeTree Correct return type in docs for [`yield_in_source`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/middle/region/struct.ScopeTree.html#method.yield_in_scope) method. Closes #80287.
-
由 Guillaume Gomez 提交于
Turn helper method into a closure `replace_prefix` is currently implemented as a method but has no real relation to the struct it is implemented on. Turn it into a closure and move it into the only method from which it is called. `@rustbot` modify labels +C-cleanup +T-compiler r? `@lcnr`
-
由 Guillaume Gomez 提交于
Improve the code quality by using matches macro Improved the code quality by using matches macro r? `@GuillaumeGomez`
-
由 Guillaume Gomez 提交于
Add some intra-doc links to compiler docs r? `@pierwill`
-