Remove a large amount of leb128-coded integers
This removes ~41%[^1] of the leb128-encoded integers serialized during libcore compilation by changing enum tags to opportunistically use `u8` where feasible instead of the leb128 coding via `usize`.
This should have effectively zero impact on metadata file sizes, since almost all or all enum tags fit into the 7 bits available in leb128 for single-byte encodings. Perf results indicate this is basically neutral across the board except for an improvement in bootstrap time.
[^1]: More than half the remaining integers still fit into <= 128, so the leb128 coding still makes sense. 32% are zero, and 46% are <= 4.
bump bootstrap dependencies
This PR removes hard-coded patch versions, updates bootstrap's dependency stack to recent versions (some of the versions were released 3-4 years ago), and removes a few dependencies from bootstrap.
Removed dependencies:
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.
Reorder early post-inlining passes.
`RemoveZsts`, `RemoveUnneededDrops` and `UninhabitedEnumBranching` only depend on types, so they should be executed together early after MIR inlining introduces those types.
This does not change the end-result, but this makes the pipeline a bit more consistent.
Rollup of 11 pull requests
Successful merges:
- #115046 (Use version-sorting for all sorting)
- #118915 (Add some comments, add `can_define_opaque_ty` check to `try_normalize_ty_recur`)
- #119006 (Fix is_global special address handling)
- #119637 (Pass LLVM error message back to pass wrapper.)
- #119715 (Exhaustiveness: abort on type error)
- #119763 (Cleanup things in and around `Diagnostic`)
- #119788 (change function name in comments)
- #119790 (Fix all_trait* methods to return all traits available in StableMIR)
- #119803 (Silence some follow-up errors [1/x])
- #119804 (Stabilize mutex_unpoison feature)
- #119832 (Meta: Add project const traits to triagebot config)
r? `@ghost`
`@rustbot` modify labels: rollup
Silence some follow-up errors [1/x]
this is one piece of the requested cleanups from https://github.com/rust-lang/rust/pull/117449
When we use `-> impl SomeTrait<_>` as a return type, we are both using the "infer return type suggestion" code path, and the infer opaque type code path within the same function. That can lead to confusing diagnostics, so silence all opaque type diagnostics in that case.
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`
Pass LLVM error message back to pass wrapper.
When rustc fails to load a plugin, it should provide more detailed error message. Before this PR, rustc prints:
```
error: failed to run LLVM passes: Failed to load pass pluginPLUGIN_NAME.so
```
This PR passes LLVM errors back to rustc. After this PR, rustc prints:
```
error: failed to run LLVM passes: Could not load library 'PLUGIN_NAME.so': PLUGIN_NAME.so: undefined symbol: _ZN4llvm9DebugFlagE
```
This PR only contains usability improvements and does not change any functionality. Thus, no new unit test is implemented.
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".
Exhaustiveness: use an `Option` instead of allocating fictitious patterns
In the process of exhaustiveness checking, `Matrix` stores a 2D array of patterns. Those are subpatterns of the patterns we were provided as input, _except_ sometimes we allocate some extra wildcard patterns to fill a hole during specialization.
Morally though, we could store `Option<&'p DeconstructedPat>` in the matrix, where `None` signifies a wildcard. That way we'd only have "real" patterns in the matrix and we wouldn't need the arena to allocate these wildcards. This is what this PR does.
This is part of me splitting up https://github.com/rust-lang/rust/pull/119581 for ease of review.
r? `@compiler-errors`
Of the error levels satisfying `is_error`, `Level::Error` is the only
one that can be a lint, so there's no need to check for it.
(And even if it wasn't, it would make more sense to include
non-`Error`-but-`is_error` lints under `lint_err_count` than under
`err_count`.)
There are four functions that adjust error and warning counts:
- `stash_diagnostic` (increment)
- `steal_diagnostic` (decrement)
- `emit_stashed_diagnostics) (decrement)
- `emit_diagnostic` (increment)
The first three all behave similarly, and only update `warn_count` for
forced warnings. But the last one updates `warn_count` for both forced
and non-forced warnings.
Seems like a bug. How should it be fixed? Well, `warn_count` is only
used in one place: `DiagCtxtInner::drop`, where it's part of the
condition relating to the printing of `good_path_delayed_bugs`. The
intention of that condition seems to be "have any errors been printed?"
so this commit replaces `warn_count` with `has_printed`, which is set
when printing occurs. This is simpler than all the ahead-of-time
incrementing and decrementing.
`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
