Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
Turns out
- `owning_ref` is unsound due to `Box` aliasing stuff
- `rustc` doesn't need 99% of the `owning_ref` API
- `rustc` can use a far simpler abstraction that is `OwnedSlice`
Tweak debug outputs to make debugging new solver easier
1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs.
For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output).
For canonicalized things, I typically care more about what is *being* canonicalized.
For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not...
2. Add some more debug and instrument calls to functions to add more structure to tracing lines.
r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
submodule detection for proper fix on #96188
This commit resolves an internal FIXME note within the bootstrap by implementing submodule detection. This is accomplished through an iterative process over the `.gitmodules` file.
r? `@albertlarsan68`
Add T-bootstrap label to tools
cc `@rust-lang/bootstrap:`
### Unresolved questions:
- [ ] Do we want to keep the A-testsuite on those?
- [ ] Do we want all of those tools to be ours?
This commit resolves an internal FIXME note within the bootstrap by implementing submodule detection.
This is accomplished through an iterative process over the `.gitmodules` file.
Signed-off-by: ozkanonur <work@onurozkan.dev>
Avoid a few locks
We can use atomics or datastructures tuned for specific access patterns instead of locks. This may be an improvement for parallel rustc, but it's mostly a cleanup making various datastructures only usable in the way they are used right now (append data, never mutate), instead of having a general purpose lock.
Remove the use of `-use-gnu-stack` when BOLTing LLVM
This flag was (counterintuitively) removing the `GNU_STACK` ELF attribute, which caused the optimized `libLLVM.so` file to be flagged as having an executable stack on SELinux.
Removing the flag might cause issues with `strip`. I'm not aware that we're stripping `libLLVM.so` though. Does it happen anywhere?
Fixes: https://github.com/rust-lang/rust/issues/105783
