Add debug info for macOS CI actions
This adds some debugging information to the CI logs about the macOS runners to potentially help diagnose performance issues. I think this is unlikely to help, since I think the most likely issue is over-provisioning, but I figured it might be a worthy shot in the dark. The macos-12 runners definitely have issues with SIP randomly being enabled, but I have not seen evidence of that for macos-13.
bootstrap: exclude link_jobs from `check_ci_llvm!` checks
This option is largely there to help people to manage the memory usage on their systems during the LLVM build. The linking phase is as usual are the heaviest part of the build and if in an unlucky conincidence the circumstances align to kick off N_CORES links at the same time, not even hundreds of GiB of memory may suffice. It makes a lot of sense for developers to set&forget this option unconditionally based on how buff their development device is.
Not to mention, this option does not, in any way, affect the generated code (at least as far as I know.) It really doesn’t matter what option the CI build LLVM used here and/or if it matches with the user’s configuration.
Finally, 0 actual link jobs implied by `download-ci-llvm` is guaranteed to stay within the limits that are reasonable to set with this option.
Stop mentioning internal lang items in no_std binary errors
When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the `internal_features` lint telling you that you shouldn't use them! But you need a no_std binary! What now?
No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like `main`) and you're good to go. Would be nice if the compiler told you that, right?
This makes it so that it does do that.
I don't _love_ the new messages yet, but they're decent I think. They can probably be improved, please suggest improvements.
Cleanup things in and around `Diagnostic`
These changes all arose when I was looking closely at how to simplify `DiagCtxtInner::emit_diagnostic`.
r? `@compiler-errors`
Use version-sorting for all sorting
Add a description of a version-sorting algorithm. (This algorithm does
not precisely match `strverscmp`; it's intentionally simpler in its
handling of leading zeroes, and produces a result easier for humans to
easily understand and do by hand.)
Change all references to sorting to use version-sorting.
Change all references to "ASCIIbetically" to instead say "sort
non-lowercase before lowercase".
`is_force_warn` is only possible for diagnostics with `Level::Warning`,
but it is currently stored in `Diagnostic::code`, which every diagnostic
has.
This commit:
- removes the boolean `DiagnosticId::Lint::is_force_warn` field;
- adds a `ForceWarning` variant to `Level`.
Benefits:
- The common `Level::Warning` case now has no arguments, replacing
lots of `Warning(None)` occurrences.
- `rustc_session::lint::Level` and `rustc_errors::Level` are more
similar, both having `ForceWarning` and `Warning`.
When writing a no_std binary, you'll be greeted with nonsensical errors
mentioning lang items like eh_personality and start. That's pretty bad
because it makes you think that you need to define them somewhere! But
oh no, now you're getting the `internal_features` lint telling you that
you shouldn't use them! But you need a no_std binary! What now?
No problem! Writing a no_std binary is super easy. Just use panic=abort
and supply your own platform specific entrypoint symbol (like `main`)
and you're good to go. Would be nice if the compiler told you that,
right?
This makes it so that it does do that.
Diagnostic API fixes
Some improvements to diagnostic APIs: improve some naming, use shortcuts in more places, and add a couple of missing methods.
r? `@compiler-errors`
This option is largely there to help people to manage the memory usage
on their systems during the LLVM build. The linking phase is as usual
are the heaviest part of the build and if in an unlucky conincidence the
circumstances align to kick off N_CORES links at the same time, not even
hundreds of GiB of memory may suffice. It makes a lot of sense for
developers to set&forget this option unconditionally.
Not to mention, this option does not, in any way, affect the generated
code (at least as far as I know.) It really doesn’t matter what
option the CI build LLVM used here and/or if it matches with the user’s
configuration.
Finally, 0 actual link jobs implied by `download-ci-llvm` is guaranteed
to stay within the limits that are reasonable to set with this option.
Rollup of 4 pull requests
Successful merges:
- #106893 (Explain base expression for struct update syntax)
- #119769 (rustdoc: offset generic args of cross-crate trait object types when cleaning)
- #119772 (Fix an ICE that occurs after an error has already been reported)
- #119782 (rint intrinsics: caution against actually trying to check for floating-point exceptions)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: offset generic args of cross-crate trait object types when cleaning
Fixes#119529.
This PR contains several refactorings apart from the bug fix.
Best reviewed commit by commit.
r? GuillaumeGomez
This lets us avoid the use of `DiagnosticBuilder::into_diagnostic` in
miri, when then means that `DiagnosticBuilder::into_diagnostic` can
become private, being now only used by `stash` and `buffer`.
In #119606 I added them and used a `_mv` suffix, but that wasn't great.
A `with_` prefix has three different existing uses.
- Constructors, e.g. `Vec::with_capacity`.
- Wrappers that provide an environment to execute some code, e.g.
`with_session_globals`.
- Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`.
The third case is exactly what we want, so this commit changes
`DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`.
Thanks to @compiler-errors for the suggestion.
- `struct_foo` + `emit` -> `foo`
- `create_foo` + `emit` -> `emit_foo`
I have made recent commits in other PRs that have removed some of these
shortcuts for combinations with few uses, e.g.
`struct_span_err_with_code`. But for the remaining combinations that
have high levels of use, we might as well use them wherever possible.
Because it takes an error code after the span. This avoids the confusing
overlap with the `DiagCtxt::struct_span_err` method, which doesn't take
an error code.
The new names are consistent with the other rustc_middle cleaning functions.
Regarding the local variable `ty_args`, it's used throughout the function and
personally speaking its name isn't very legible, I trip up on it.
rustdoc-search: reuse individual types in function signatures
Because `search.js` never mutates the function signature after loading it,
they can be safely and easily reused across functions.
This change doesn't change the format of the search index.
It only changes `search.js`.
Profiler output: https://notriddle.com/rustdoc-html-demo-9/fn-signature-opti2/index.html
<table><tr><th>benchmark<th>before<th>after
<tr><th>arti<td>
```
user: 002.228 s
sys: 000.315 s
wall: 001.663 s
child_RSS_high: 315668 KiB
group_mem_high: 285948 KiB
```
<td>
```
user: 001.805 s
sys: 000.231 s
wall: 001.398 s
child_RSS_high: 235864 KiB
group_mem_high: 203056 KiB
```
<tr><th>cortex-m<td>
```
user: 000.143 s
sys: 000.035 s
wall: 000.140 s
child_RSS_high: 59168 KiB
group_mem_high: 23000 KiB
```
<td>
```
user: 000.138 s
sys: 000.031 s
wall: 000.133 s
child_RSS_high: 58944 KiB
group_mem_high: 22220 KiB
```
<tr><th>sqlx<td>
```
user: 000.792 s
sys: 000.115 s
wall: 000.536 s
child_RSS_high: 156716 KiB
group_mem_high: 122948 KiB
```
<td>
```
user: 000.824 s
sys: 000.084 s
wall: 000.535 s
child_RSS_high: 136668 KiB
group_mem_high: 101792 KiB
```
<tr><th>stm32f4<td>
```
user: 006.665 s
sys: 003.533 s
wall: 008.624 s
child_RSS_high: 1037660 KiB
group_mem_high: 1022516 KiB
```
<td>
```
user: 005.997 s
sys: 003.185 s
wall: 007.987 s
child_RSS_high: 832068 KiB
group_mem_high: 810908 KiB
```
<tr><th>stm32f4xx-hal<td>
```
user: 000.317 s
sys: 000.051 s
wall: 000.203 s
child_RSS_high: 77060 KiB
group_mem_high: 41776 KiB
```
<td>
```
user: 000.287 s
sys: 000.046 s
wall: 000.180 s
child_RSS_high: 75216 KiB
group_mem_high: 39200 KiB
```
<tr><th>ripgrep<td>
```
user: 000.463 s
sys: 000.063 s
wall: 000.295 s
child_RSS_high: 101288 KiB
group_mem_high: 66364 KiB
```
<td>
```
user: 000.472 s
sys: 000.036 s
wall: 000.247 s
child_RSS_high: 82708 KiB
group_mem_high: 47056 KiB
```
</tr></table>
Rework and improve the unstable documentation of check-cfg
This PR rework and improve the unstable documentation of the check-cfg feature.
The goal is to have a simpler to understand documentation with examples that are more practical and less theoretical. As well as making the documentation more explicit about the whereabouts of the feature.
`@rustbot` label +T-compiler +F-check-cfg
Support async recursive calls (as long as they have indirection)
Before #101692, we stored coroutine witness types directly inside of the coroutine. That means that a coroutine could not contain itself (as a witness field) without creating a cycle in the type representation of the coroutine, which we detected with the `OpaqueTypeExpander`, which is used to detect cycles when expanding opaque types after that are inferred to contain themselves.
After `-Zdrop-tracking-mir` was stabilized, we no longer store these generator witness fields directly, but instead behind a def-id based query. That means there is no technical obstacle in the compiler preventing coroutines from containing themselves per se, other than the fact that for a coroutine to have a non-infinite layout, it must contain itself wrapped in a layer of allocation indirection (like a `Box`).
This means that it should be valid for this code to work:
```
async fn async_fibonacci(i: u32) -> u32 {
if i == 0 || i == 1 {
i
} else {
Box::pin(async_fibonacci(i - 1)).await
+ Box::pin(async_fibonacci(i - 2)).await
}
}
```
Whereas previously, you'd need to coerce the future to `Pin<Box<dyn Future<Output = ...>>` before `await`ing it, to prevent the async's desugared coroutine from containing itself across as await point.
This PR does two things:
1. Only report an error if an opaque expansion cycle is detected *not* through coroutine witness fields.
* Instead, if we find an opaque cycle through coroutine witness fields, we compute the layout of the coroutine. If that results in a cycle error, we report it as a recursive async fn.
4. Reworks the way we report layout errors having to do with coroutines, to make up for the diagnostic regressions introduced by (1.). We actually do even better now, pointing out the call sites of the recursion!
mir-opt and custom target fixes
From https://github.com/rust-lang/rust/issues/115642#issuecomment-1879589022
> > Could you please test the last two commits from https://github.com/onur-ozkan/rust/commits/panic-abort-mir-opt when you have the time? The first commit should resolve the error of using the nightly flag with a stable compiler, and the second one should resolve the custom target issue.
> I tested with the two commits and the errors of using nightly flag and custom target specs were not seen.
Testing was completed for the test suites like ui, run-pass-valgrind, coverage, mir-opt, codegen, assembly, incremental.
Fixes#115642
coverage: Anonymize line numbers in branch views
Extracted from #118305, as this is now the only part of that PR that needs to touch compiletest.
---
Coverage tests run the `llvm-cov` tool to generate a coverage report for a test program, and then compare the report against a known-good snapshot.
We use the `anonymize_coverage_line_numbers` function to replace line numbers in coverage reports with `LL`, so that they are less sensitive to lines being added or removed. This PR augments the existing code by making it also support the slightly different line number syntax used when reporting branch regions.
Currently the compiler never emits branch regions, so there is no way to write a coverage test that makes use of this new capability. Instead, I've added a unit test that checks against some sample reports taken from #118305. That unit test can be removed when some form of branch coverage support gets merged, and real branch coverage tests are added to the coverage test suite.
(I have also manually tested this change as part of my draft branch-coverage PR.)
Map is implemented as a pointer to a mutable object.
Rustdoc never mutates function signatures after constructing them,
but the JS engine doesn't know that.
To save a bunch of memory, use a single immutable map
for every decoded type object with no bindings or generics.
Consuming `emit`
This PR makes `DiagnosticBuilder::emit` consuming, i.e. take `self` instead of `&mut self`. This is good because it doesn't make sense to emit a diagnostic twice.
This requires some changes to `DiagnosticBuilder` method changing -- every existing non-consuming chaining method gets a new consuming partner with a `_mv` suffix -- but permits a host of beneficial follow-up changes: more concise code through more chaining, removal of redundant diagnostic construction API methods, and removal of machinery to track the possibility of a diagnostic being emitted multiple times.
r? `@compiler-errors`
