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.
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.
Checked code:
```rust
fn main() {
move async { };
}
```
Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
--> src\main.rs:2:10
|
2 | move async { };
| ^^^^^ expected one of `|` or `||`
error: aborting due to previous error
error: could not compile `move_async_test`
```
New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
--> src\main.rs:2:13
|
2 | let _ = move async { };
| ^^^^^^^^^^
|
help: try switching the order
|
2 | let _ = async move { };
| ^^^^^^^^^^
error: aborting due to previous error
error: could not compile `move_async_test`
```
Is there a file/module where these kind of things are tested?
Would love some feedback 😄
Stabilize `core::slice::fill`
Tracking issue https://github.com/rust-lang/rust/issues/70758
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!
r? `@m-ou-se`
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.
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.
r? `@Mark-Simulacrum`
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.
r? `@jyn514`
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.
r? `@jyn514`
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`.
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`
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.
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`
