Spelling compiler
This is per https://github.com/rust-lang/rust/pull/110392#issuecomment-1510193656
I'm going to delay performing a squash because I really don't expect people to be perfectly happy w/ my changes, I really am a human and I really do make mistakes.
r? Nilstrieb
I'm going to be flying this evening, but I should be able to squash / respond to reviews w/in a day or two.
I tried to be careful about dropping changes to `tests`, afaict only two files had changes that were likely related to the changes for a given commit (this is where not having eagerly squashed should have given me an advantage), but, that said, picking things apart can be error prone.
ci: add a runner for vanilla LLVM 16
Like #107044, this will let us track compatibility with LLVM 16 going
forward, especially after we eventually upgrade our own to the next.
This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with
that change in #106085.
Rollup of 7 pull requests
Successful merges:
- #109981 (Set commit information environment variables when building tools)
- #110348 (Add list of supported disambiguators and suffixes for intra-doc links in the rustdoc book)
- #110409 (Don't use `serde_json` to serialize a simple JSON object)
- #110442 (Avoid including dry run steps in the build metrics)
- #110450 (rustdoc: Fix invalid handling of nested items with `--document-private-items`)
- #110461 (Use `Item::expect_*` and `ImplItem::expect_*` more)
- #110465 (Assure everyone that `has_type_flags` is fast)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Fix invalid handling of nested items with `--document-private-items`
Fixes#110422.
The problem is that only impl block and re-exported `macro_rules!` items are "visible" as nested items. This PR adds the missing checks to handle this correctly.
cc `@compiler-errors`
r? `@notriddle`
Avoid including dry run steps in the build metrics
Including steps executed during the dry run will result in a duplication of all the steps in the build metrics, which just adds noise.
Don't use `serde_json` to serialize a simple JSON object
This avoids `rustc_data_structures` depending on `serde_json` which allows it to be compiled much earlier, unlocking most of rustc.
This used to not matter, but after #110407 we're not blocked on fluent anymore, which means that it's now a blocking edge.
This saves a few more seconds.
cc ````@Zoxc```` who added it recently
Add list of supported disambiguators and suffixes for intra-doc links in the rustdoc book
This information is otherwise only provided in case an error occurs, which isn't great.
r? ```@notriddle```
Set commit information environment variables when building tools
This fixes#107094.
~I'm trying to add a regression test for this issue.~
**Update**: I've added a test and a new test header `needs-git-hash` which makes sure it doesn't run when commit hashes are ignored (`bootstrap`'s `ignore-git` option).
Implement StableHasher::write_u128 via write_u64
In https://github.com/rust-lang/rust/pull/110367#issuecomment-1510114777 the cachegrind diffs indicate that nearly all the regression is from this:
```
22,892,558 ???:<rustc_data_structures::sip128::SipHasher128>::slice_write_process_buffer
-9,502,262 ???:<rustc_data_structures::sip128::SipHasher128>::short_write_process_buffer::<8>
```
Which happens because the diff for that perf run swaps a `Hash::hash` of a `u64` to a `u128`. But `slice_write_process_buffer` is a `#[cold]` function, and is for handling hashes of arbitrary-length byte arrays.
Using the much more optimizer-friendly `u64` path twice to hash a `u128` provides a nice perf boost in some benchmarks.
Tagged pointers, now with strict provenance!
This is a big refactor of tagged pointers in rustc, with three main goals:
1. Porting the code to the strict provenance
2. Cleanup the code
3. Document the code (and safety invariants) better
This PR has grown quite a bit (almost a complete rewrite at this point...), so I'm not sure what's the best way to review this, but reviewing commit-by-commit should be fine.
r? `@Nilstrieb`
Bypass the varint path when encoding InitMask
The data in a `InitMask` is stored as `u64` but it is a large bitmask (not numbers) so varint encoding doesn't make sense.
tests: adapt for LLVM change 5b386b864c7619897c51a1da97d78f1cf6f3eff6
The above-mentioned change modified the output of thread-local.rs by changing some variable names. Rather than assume things get put in %0, we capture the variable so the test passes in both the old and new version.
Check freeze with right param-env in `deduced_param_attrs`
We're checking if a trait (`Freeze`) holds in a polymorphic function, but not using that function's own (reveal-all) param-env. This causes us to try to eagerly normalize a specializable projection type that has no default value, which causes an ICE.
Fixes#110171
Various minor Idx-related tweaks
Nothing particularly exciting here, but a couple of things I noticed as I was looking for more index conversions to simplify.
cc https://github.com/rust-lang/compiler-team/issues/606
r? `@WaffleLapkin`
Correct default value for default-linker-libraries
This setting is false by default according to rustc code here: https://github.com/rust-lang/rust/blob/master/compiler/rustc_session/src/options.rs#L1236
I tested on a project and confirmed the behavior described. First, with no value, the `-nodefaultlibs` linker flag is present. Setting this to false has no effect, as well. The linker flag still appears. Setting it to true removes the linker flag as expected.
The above-mentioned change modified the output of thread-local.rs by
changing some variable names. Rather than assume things get put in %0,
we capture the variable so the test passes in both the old and new
version.
Remove some suspicious cast truncations
These truncations were added a long time ago, and as best I can tell without a perf justification. And with rust-lang/rust#110410 it has become perf-neutral to not truncate anymore. We worked hard for all these bits, let's use them.
Rollup of 7 pull requests
Successful merges:
- #110038 (Erase regions when confirming transmutability candidate)
- #110341 (rustdoc: stop passing a title to `replaceState` second argument)
- #110388 (Add a message for if an overflow occurs in `core::intrinsics::is_nonoverlapping`.)
- #110404 (fix clippy::toplevel_ref_arg and ::manual_map)
- #110421 (Spelling librustdoc)
- #110423 (Spelling srcdoc)
- #110433 (Windows: map a few more error codes to ErrorKind)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Windows: map a few more error codes to ErrorKind
NotFound errors:
* `ERROR_INVALID_DRIVE`: The system cannot find the drive specified
* `ERROR_BAD_NETPATH`: The network path was not found
* `ERROR_BAD_NET_NAME`: The network name cannot be found.
InvalidFilename:
* `ERROR_BAD_PATHNAME`: The specified path is invalid.
Source: [System Error Codes (0-499)](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)
Spelling librustdoc
This is split from https://github.com/rust-lang/rust/pull/110392
There's one change to src/tools/rustdoc-gui/tester.js which feels like a reasonable thing to piggy-back here.
rustdoc: stop passing a title to `replaceState` second argument
As described on [MDN's replaceState page], this parameter is not currently used, and the empty string is "safe against future changes to the method."
[MDN's replaceState page]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState
Alloc `hir::Lit` in an arena to remove the destructor from `Expr`
This allows allocating `Expr`s into a dropless arena, which is useful for using length prefixed thing slices in HIR, since these can only be allocated in the dropless arena and not in a typed arena.
Permit MIR inlining without #[inline]
I noticed that there are at least a handful of portable-simd functions that have no `#[inline]` but compile to an assign + return.
I locally benchmarked inlining thresholds between 0 and 50 in increments of 5, and 50 seems to be the best. Interesting. That didn't include check builds though, ~maybe perf will have something to say about that~.
Perf has little useful to say about this. We generally regress all the check builds, as best as I can tell, due to a number of small codegen changes in a particular hot function in the compiler. Probably this is because we've nudged the inlining outcomes all over, and uses of `#[inline(always)]`/`#[inline(never)]` might need to be adjusted.
