Joshua Nelson [Wed, 30 Dec 2020 04:16:40 +0000 (23:16 -0500)]
Add `#[track_caller]` to `bug!` and `register_renamed`
Before:
```
thread 'rustc' panicked at 'compiler/rustc_lint/src/context.rs:267:18: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:34:26
```
After:
```
thread 'rustc' panicked at 'src/librustdoc/core.rs:455:24: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:35:26
```
The reason I added it to `register_renamed` too is that any panic in
that function will be the caller's fault.
bors [Sun, 27 Dec 2020 09:55:51 +0000 (09:55 +0000)]
Auto merge of #79642 - ijackson:default-theme-stab, r=jyn514
rustdoc: stabilise --default-theme command line option
As discussed in #77213, this seems like it has bedded in and can be safely and usefully made stable.
(rustdoc already has other stable options that interact quite intimately with the rustdoc-supplied CSS, and also an option for supplying entirely different CSS, so exposing the theme names this way seems a very minor step.)
There is also a commit to do some minor grammar fixes to the help message.
bors [Sun, 27 Dec 2020 07:05:56 +0000 (07:05 +0000)]
Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination, r=varkor
stabilize `#![feature(min_const_generics)]` in 1.51
*A new Kind*
*A Sort long Prophesized*
*Once Fragile, now Eternal*
blocked on #79073.
# Stabilization report
This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878), a subset of `#![feature(const_generics)]` (tracking issue #44580), based on rust-lang/rfcs#2000.
The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta, 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta, 2021-03-25 => stable).
This report is a collaborative effort of `@varkor,` `@shepmaster` and `@lcnr.`
## Summary
It is currently possible to parameterize functions, type aliases, types, traits and implementations by types and lifetimes.
With `#![feature(min_const_generics)]`, it becomes possible, in addition, to parameterize these by constants.
This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics, `min_const_generics` is limited to parameterization by integers, and constants of type `char` or `bool`.
We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples.
Generic const arguments, for now, are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either:
1. const expressions that do not depend on any generic parameters, e.g. `{ foo() + 1 }`, where `foo` is a `const fn`
1. standalone const parameters, e.g. `{N}`
impl<const N: usize> Foo<N> for Bar<u8, N> {
fn method<const M: usize>(&mut self, arr: [[u8; M]; N]) {
for (elem, s) in self.inner.iter_mut().zip(arr.iter()) {
for &x in s {
*elem &= x;
}
}
}
}
fn function<const N: u16>() -> u16 {
// Const parameters can be used freely inside of functions.
(N + 1) / 2 * N
}
fn main() {
let mut bar = Bar { inner: [0xff; 3] };
// This infers the value of `M` from the type of the function argument.
bar.method([[0b11_00, 0b01_00], [0b00_11, 0b00_01], [0b11_00, 0b00_11]]);
assert_eq!(bar.inner, [0b01_00, 0b00_01, 0b00_00]);
// You can also explicitly specify the value of `N`.
assert_eq!(function::<17>(), 153);
}
```
## Motivation
Rust has the built-in array type, which is parametric over a constant. Without const generics, this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example, this meant that, for a long time, the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics.
Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values, rather than by types. For example, using const generics, many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters, improving compilation time as well as code readability and diagnostics.
The subset described by `min_const_generics` is self-contained, but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore, it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved.
## In-depth feature description
### Declaring const parameters
*Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently, const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace.
`Type` must be one of `u8`, `u16`, `u32`, `u64`, `u128`, `usize`, `i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `char` and `bool`. This restriction is implemented in two places:
1. during name resolution, where we forbid generic parameters
1. during well-formedness checking, where we only allow the types listed above
Unlike type and lifetime parameters, const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed:
```rust
struct Foo<const N: usize>;
enum Bar<const M: usize> { A, B }
```
### Const arguments
Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter, most expressions must be contained within a block, with two exceptions:
1. literals and single-segment path expressions
1. array lengths
This syntactic restriction is necessary to avoid ambiguity, or requiring infinite lookahead when parsing an expression as a generic argument.
In the cases where a generic argument could be resolved as either a type or const argument, we always interpret it as a type. This causes the following test to fail:
To circumvent this, the user may wrap the const parameter with braces, at which point it is unambiguously accepted.
```rust
type N = u32;
struct Foo<const N: usize>;
fn bar<const N: usize>() -> Foo<{ N }> { todo!() } // ok
```
Operations depending on generic parameters are **not** allowed, which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]`, which is not yet being stabilised.
Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]`, we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details.
Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized, we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error, this is theoretically a breaking change, as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed, causing the following snippet to break:
```rust
fn late_bound<'a>() {
let _ = [0; {
let _: &'a (); // ICE ==> ERR
3
}];
}
fn early_bound<'a>() where &'a (): Sized {
let _ = [0; {
let _: &'a (); // ok ==> ERR
3
}];
}
```
### Using const parameters
Const parameters can be used almost everywhere ordinary constants are allowed, except that they may not be used in the construction of consts, statics, functions, or types inside a function body and are subject to the generic argument restrictions mentioned above.
Expressions containing const parameters are eligible for promotion:
See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known, or `Kp` where the value is not known, where:
- `[type]` is any integral type, `bool`, or `char`.
- `[value]` is the unsigned hex value for integers, preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`.
### Exhaustiveness checking
We do not check the exhaustiveness of impls, meaning that the following example does **not** compile:
```rust
struct Foo<const B: bool>;
trait Bar {}
impl Bar for Foo<true> {}
impl Bar for Foo<false> {}
fn needs_bar(_: impl Bar) {}
fn generic<const B: bool>() {
let v = Foo::<B>;
needs_bar(v);
}
```
### Type inference
The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays, which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825.
### Equality of constants
`#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter.
### Associated constants
Associated constants can use const parameters without restriction, see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details.
## Future work
As this is a limited subset of rust-lang/rfcs#2000, there are quite a few extensions we will be looking into next.
### Lazy normalization of constants
Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics`, and unblocks operations on const parameters.
### Relaxing ordering requirements between const and type parameters
We currently restrict the order of generic parameters so that types must come before consts. We could relax this, as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time.
Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters.
### Allowing more parameter types
We would like to support const parameters of more types, especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo<T, const N: T>` will be a lot harder and is unlikely to be implemented in the near future.
### Default values of const parameters
We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384).
### Generic const operations
With `#![feature(min_const_generics)]`, only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However, supporting generic const operations, such as `N + 1` or `std::mem::size_of::<T>()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`.
## Implementation history
Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here!
bors [Sun, 27 Dec 2020 04:14:20 +0000 (04:14 +0000)]
Auto merge of #80400 - adlerd:hashclone, r=Mark-Simulacrum
Use `clone_from` from `hashbrown::{HashMap,HashSet}`.
This change updates the `std` hash collections to use `hashbrown`'s `clone_from`, which was itself added in #70052. Deriving `Clone` does not add a `clone_from` impl and uses the trait default, which calls `clone`.
bors [Sun, 27 Dec 2020 01:21:40 +0000 (01:21 +0000)]
Auto merge of #80395 - ehuss:lint-docs-warn-missing, r=Mark-Simulacrum
lint-docs: Warn on missing lint when documenting.
In #79522, I missed converting one of the errors to a warning, in the situation where a lint is missing. This was unearthed by the renaming of overlapping-patterns (#78242). This will still be validated during the test phase.
bors [Sat, 26 Dec 2020 00:11:30 +0000 (00:11 +0000)]
Auto merge of #80246 - matthewjasper:projection-cycle-caching, r=Mark-Simulacrum
Prevent caching normalization results with a cycle
When normalizing a projection which results in a cycle, we would cache the result of `project_type` without the nested obligations (because they're not needed for inference). This would result in the nested obligations only being handled once in fulfill, which would avoid the cycle error. `get_paranoid_cache_value_obligation` used to add an obligation that resulted in a cycle in this case previously, but was removed by #73905.
This PR makes the projection cache not cache the value of a projection if it was ever normalized in a cycle (except in a snapshot that's rolled back).
bors [Fri, 25 Dec 2020 18:25:48 +0000 (18:25 +0000)]
Auto merge of #80235 - RalfJung:validate-promoteds, r=oli-obk
validate promoteds
Turn on const-value validation for promoteds. This is made possible now that https://github.com/rust-lang/rust/issues/67534 is resolved.
I don't think this is a breaking change. We don't promote any unsafe operation any more (since https://github.com/rust-lang/rust/pull/77526 landed). We *do* promote `const fn` calls under some circumstances (in `const`/`static` initializers), but union field access and similar operations are not allowed in `const fn`. So now is a perfect time to add this check. :D
bors [Fri, 25 Dec 2020 11:16:53 +0000 (11:16 +0000)]
Auto merge of #80226 - ThePuzzlemaker:issue-80004-fix, r=jyn514,petrochenkov
Highlight edition-specific keywords correctly in code blocks, accounting for code block edition modifiers
Previously, edition-specific keywords (such as `async` and `await`) were not highlighted in code blocks, regardless of what edition was set. With this PR, this issue is fixed.
Now, the following behavior happens:
- When a code block is explicitly set to edition X, keywords from edition X are highlighted
- When a code block is explicitly set to a version that does not contain those keywords from edition X (e.g. edition Y), keywords from edition X are **not** highlighted
- When a code block has no explicit edition, keywords from the edition passed via `--edition` to rustdoc are highlighted
For example, a project set with `edition = "2015"` in its `Cargo.toml` would not highlight `async`/`await` unless the code block was set to `edition2018`. Additionally, a project set with `edition = "2018"` in its `Cargo.toml` *would* highlight `async`/`await` unless the code block was set to a version that did not contain those keywords (e.g. `edition2015`).
bors [Fri, 25 Dec 2020 05:23:24 +0000 (05:23 +0000)]
Auto merge of #80364 - Dylan-DPC:rollup-0y96okz, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #79213 (Stabilize `core::slice::fill`)
- #79999 (Refactored verbose print into a function)
- #80160 (Implemented a compiler diagnostic for move async mistake)
- #80274 (Rename rustc_middle::lint::LintSource)
- #80280 (Add installation commands to `x` tool README)
- #80319 (Fix elided lifetimes shown as `'_` on async functions)
- #80327 (Updated the match with the matches macro)
- #80330 (Fix typo in simplify_try.rs)
- #80340 (Don't unnecessarily override attrs for Module)
- #80342 (Fix typo)
- #80352 (BTreeMap: make test cases more explicit on failure)
Dylan DPC [Fri, 25 Dec 2020 02:39:36 +0000 (03:39 +0100)]
Rollup merge of #80274 - pierwill:lintlevelsource, r=petrochenkov
Rename rustc_middle::lint::LintSource
Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`.
This enum represents the source of a *lint level*, not a lint. This should improve code readability.
Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
Dylan DPC [Fri, 25 Dec 2020 02:39:35 +0000 (03:39 +0100)]
Rollup merge of #80160 - diondokter:move_async_fix, r=davidtwco
Implemented a compiler diagnostic for move async mistake
Fixes #79694
First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)
This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.
Stabilizes the `core::slice::fill` API in Rust 1.50, adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/, and it seems like the right time to propose stabilization. Thanks!
bors [Fri, 25 Dec 2020 02:37:08 +0000 (02:37 +0000)]
Auto merge of #79762 - Swatinem:remap-doctest-coverage, r=Swatinem
Remap instrument-coverage line numbers in doctests
This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done, and rustdoc
still does not output the correct filename when running doctests in a
workspace.
Part of #79417 although I dont consider that fixed until both filenames
and columns are mapped correctly.
r? `@richkadel`
I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
bors [Thu, 24 Dec 2020 21:49:15 +0000 (21:49 +0000)]
Auto merge of #79347 - ssomers:btree_split_pointer_provenance, r=Mark-Simulacrum
BTreeMap: respect pointer provenance rules in split_off
The test cases for `split_off` reported a few more violations (now that they support -Zmiri-track-raw-pointers). The functions `shift_kv` and `shift_edges` do not fix anything, I think, but if `move_kv` and `move_edges` exist, they deserve to live too.
ThePuzzlemaker [Sun, 20 Dec 2020 07:34:33 +0000 (01:34 -0600)]
rustdoc: Highlight edition-specific keywords correctly in code blocks, accounting for code block edition modifiers
This is a squash of these commits:
- Highlight edition-specific keywords correctly in code blocks,
accounting for code block edition modifiers
- Fix unit tests
- Revert changes to rustc_span::symbol to prepare for merge of #80272
- Use new Symbol::is_reserved API from #80272
- Remove unused import added by accident when merging
bors [Thu, 24 Dec 2020 15:22:28 +0000 (15:22 +0000)]
Auto merge of #79742 - GuillaumeGomez:move-tooltips-messages-out-of-html, r=Nemo157
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
bors [Thu, 24 Dec 2020 11:30:24 +0000 (11:30 +0000)]
Auto merge of #80295 - GuillaumeGomez:beautify-rework, r=petrochenkov
Rework beautify_doc_string so that it returns a Symbol instead of a String
This commit comes from https://github.com/rust-lang/rust/pull/80261, the goal here is to inspect the impact on performance of this change on its own.
The idea of rewriting `beautify_doc_string` is to not go through `String` if we don't need to update the doc comment to be able to keep the original `Symbol` and also to have better performance.
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 [Wed, 23 Dec 2020 21:43:28 +0000 (21:43 +0000)]
Auto merge of #79521 - ssomers:btree_cleanup_2, r=Mark-Simulacrum
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.
Eric Huss [Wed, 23 Dec 2020 20:18:15 +0000 (12:18 -0800)]
Add libz-sys to rustc-workspace-hack.
https://github.com/alexcrichton/curl-rust/pull/351 changed
curl-rust to no longer enable the default features of libz-sys.
Because rustfmt includes rustc-workspace-hack with the
rustc-workspace-hack/all-static feature (sometimes), it ends up building
libz-sys without the default features. This causes a duplicate
with other packages (like rls) which enable the default
features.
bors [Wed, 23 Dec 2020 18:50:01 +0000 (18:50 +0000)]
Auto merge of #79788 - pietroalbini:bootstrap-tarball, r=Mark-Simulacrum
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:
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):
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.
bors [Wed, 23 Dec 2020 15:57:13 +0000 (15:57 +0000)]
Auto merge of #80328 - flip1995:clippyup, r=Mark-Simulacrum
Clippy: Revert change from last sync
r? `@Manishearth`
cc `@ebroto`
Note that the commit e898015 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 [Wed, 23 Dec 2020 12:54:56 +0000 (12:54 +0000)]
Auto merge of #80262 - Mark-Simulacrum:pgo-rustc, r=pietroalbini
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)
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 [Wed, 23 Dec 2020 06:39:15 +0000 (06:39 +0000)]
Auto merge of #80099 - jyn514:visibility-on-demand, r=GuillaumeGomez
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 [Wed, 23 Dec 2020 03:35:32 +0000 (03:35 +0000)]
Auto merge of #80095 - jyn514:stability-on-demand, r=GuillaumeGomez
[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.
projects / rust.git / log