Doing so can cause us to duplicate navigation targets for the same ranges which breaks convenience features of some editors where go to def can trigger find all references
I'm joking, but now that the def map is the only thing that uses the item tree, we can remove a lot of things from it that aren't needed for the def map.
Item tree IDs are very unstable (adding an item of a kind invalidates all following items of the same kind). Instead use ast ids, which, since the previous commit, are pretty stable.
Instead of simple numbering, we hash important bits, like the name of the item.
This will allow for much better incrementality, e.g. when you add an item. Currently, this invalidates the IDs of all following items, which invalidates pretty much everything.
Avoid a gratuitous 10s wait in a stress test
`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites, is a stress test of the `recv_timeout` function. This test processes and ignores timeouts, and just ensures that every sent value gets received. As such, the exact length of the timeouts is not critical, only that the timeout and sleep durations ensure that at least one timeout occurred.
The current tests have 100 iterations, half of which sleep for 200ms, causing the test to take 10s. This represents around 2/3rds of the *total* runtime of the `library/std` testsuite, and is the only standard library test that takes more than a second.
Reduce this to 50 iterations where half of them sleep for 10ms, causing the test to take 0.25s.
Add a check that at least one timeout occurred.
CI: rfl: move job forward to Linux v6.16-rc1
Another hopefully routine upgrade to Linux v6.16-rc1, just released.
r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
Do not checkout GCC submodule for the tidy job
This is not a fully general solution, but the GCC submodule checkout is so slow that I think it's worth it to special-case it. This brings down the time required to checkout submodules from ~1.5 minute to ~0.5 minute.
Remap compiler vs non-compiler sources differently (bootstrap side)
See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083).
The path remapping and unremapping for compiler sources (distributed via `rustc-dev` dist component) is broken because bootstrap currently remaps all sources unconditionally (if remapping is enabled) to the `/rustc/{hash}` form. However, the `rustc-dev` dist component (compiler sources) and `rust-src` dist component (library sources) unpacks differently:
- `rust-src` unpacks sources to a path like `$sysroot/lib/rustlib/src/rust`, whereas
- `rustc-dev` unpacks sources to a path like `$sysroot/lib/rustlib/rustc-src/rust`[^note],
meaning that the compiler need to unremap them differently. But the same remapping means that the compiler has no way to distinguish between compiler and non-compiler (esp. standard library) sources. To remedy this, this PR adopts the approach of:
- remapping compiler sources (corresponding to `rustc-dev` dist component) with `/rustc-dev/{hash}` (this is `RemapScheme::Compiler`), and
- remapping non-compiler sources (corresponding to `rust-src` dist component or other non-compiler sources) with `/rustc/{hash}` (this is `RemapScheme::NonCompiler`).
A different remapping allows the compiler to reverse the remapping differently.
This PR implements the bootstrap side. A follow-up compiler-side change is needed to implement the unremapping change to address the reported issue completely.
This PR introduces another env var `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` that is made available to the compiler when building compiler sources to know what the remap scheme for `rustc-dev` (`RemapScheme::Compiler`) is. Compiler sources are built with the compiler remapping scheme.
As far as I know, this change should not introduce new regressions, because the compiler source unremapping (through `rustc-dev`) is already broken.
[^note]: (Notice the `src` vs `rustc-src` difference.)
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites,
is a stress test of the `recv_timeout` function. This test processes and
ignores timeouts, and just ensures that every sent value gets received.
As such, the exact length of the timeouts is not critical, only that
the timeout and sleep durations ensure that at least one timeout
occurred.
The current tests have 100 iterations, half of which sleep for 200ms,
causing the test to take 10s. This represents around 2/3rds of the
*total* runtime of the `library/std` testsuite.
Reduce this to 50 iterations where half of them sleep for 10ms, causing
the test to take 0.25s.
Add a check that at least one timeout occurred.
Do not free disk space in the `mingw-check-tidy` job
It's not needed an it slows down the job considerably. It took ~2 minutes out of the total 8-9 minutes of running `mingw-check-tidy`.
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
