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).
Fixes#79714.
r? `@nikomatsakis`
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
r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/67465
Exclude unnecessary info from CodegenResults
`foreign_module` and `wasm_import_module` are not needed for linking, and hence can be removed from CodegenResults.
Fixes#77857
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 😄
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.
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`.
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`
rustc_span: Provide a reserved identifier check for a specific edition
while keeping edition evaluation lazy because it may be expensive.
Needed for https://github.com/rust-lang/rust/pull/80226.
Add module-level docs to rustc_middle::ty
I thought it would be nice to point out `Ty` and `TyCtxt` on the module page, and link out to the [rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/ty.html).
docs: Edit rustc_middle::ty::query::on_disk_cache
Expand abbreviations for "incremental compliation".
Also added the word "to" to the description of CacheEncoder.
Reduce memory consumption by sharing the previous dependency graph's
edges with the current graph when it is known to be valid to do so. It
is known to be valid whenever we mark a node green because all of its
dependencies were green. It is *not* known to be valid when we mark a
node green because we re-executed its query and its result was the same
as in the previous compilation session. In that case, the dependency set
might have changed (we don't try to determine whether or not it changed
and whether or not we can share).
Reduce memory consumption by taking advantage of red/green algorithm
properties to share the previous dependency graph's node data with the
current graph instead of storing node data redundantly. Red nodes can
share the `DepNode`, and green nodes can share the `DepNode` and
`Fingerprint`. Edges will be shared when possible in a later change.
Clarify constructor splitting in exhaustiveness checking
I reworked the explanation of the algorithm completely to make it properly account for the various extensions we've added. This includes constructor splitting, which was previously not clearly included in the algorithm. This makes wildcards less magical; I added some detailed examples; and this distinguishes clearly between constructors that only make sense in patterns (like ranges) and those that make sense for values (like `Some`). This reformulation had been floating around in my mind for a while, and I'm quite happy with how it turned out. Let me know how you feel about it.
I also factored out all three cases of splitting (wildcards, ranges and slices) into dedicated structs to encapsulate the complicated bits.
I measured no perf impact but I don't trust my local measurements for refactors since https://github.com/rust-lang/rust/pull/79284.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
rustc_query_system: explicitly register reused dep nodes
Register nodes that we've reused from the previous session explicitly
with `OnDiskCache`. Previously, we relied on this happening as a side
effect of accessing the nodes in the `PreviousDepGraph`. For the sake of
performance and avoiding unintended side effects, register explictily.
