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`
Various changes to the `rustc_span` docs, including the following:
- Additions to top-level docs
- Edits to the source_map module docs
- Edits to documentation for `Span` and `SpanData`
- Added intra-docs links
- Documentation for Levenshtein distances
- Fixed missing punctuation
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
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`).
This PR fixes#80004.
r? `@jyn514`
Lazy compilation has the potential to significantly improve the startup
time of a program. While functions have to be codegened when called, it
is expected that a significant amount of all code is only required when
an error occurs or only when the program is used in certain ways.
The basic approach is to first codegen a shim for each function. This
shim calls the `__cg_clif_jit` function of cg_clif with a pointer to the
`Instance` corresponding to the function for which it is a shim.
`__cg_clif_jit` function then codegens this function and uses the hot
code swapping support of SimpleJIT to redirect future calls to the
function to the real version. Finally it calls the newly codegened
function.
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 😄
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`
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
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`
