This struct was only wrapping `TyCtxt` in order to implement traits that
were removed by RUST-152636.
This commit also slightly simplifies the signature of `execute_job_incr`, by
having it call `tcx.dep_graph.data()` internally.
Big query system cleanups
Recent PRs have moved a lot of code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, where this code now has access to `TyCtxt`, e.g. rust-lang/rust#152419, rust-lang/rust#152516. As a result, a lot of abstraction and indirection that existed to work around this limitation is no longer necessary. This PR removes a lot of it.
r? @Zalathar
It was just a dummy implementation to workarround the fact that thin
local lto is the default in rustc. By adding a thin_lto_supported thin
local lto can be automatically disabled for cg_gcc, removing the need
for this dummy implementation. This makes improvements to the LTO
handling on the cg_ssa side a lot easier.
Most of the files within the `dep_graph` module can be moved wholesale
into `rustc_middle`. But two of them (`mod.rs` and `dep_node.rs`) have
the same name as existing files in `rustc_middle`, so for those I just
copied the contents into the existing files.
The commit also moves `QueryContext` and `incremental_verify_ich*`
because they are tightly intertwined with the dep graph code. And a
couple of error structs moved as well.
The latter is a new module.
As well as the code motion, some other changes were required.
- `QueryJobId` methods became free functions so they could move while
`QueryJobId` itself stayed put. This was so `QueryMap` and
`QueryJobInfo` could be moved.
- Some visibilities in `rustc_query_system` required changing.
- `collect_active_jobs_from_all_queries` is no longer required in `trait
QueryContext`.
Check stalled coroutine obligations eagerly
Fixesrust-lang/rust#151322Fixesrust-lang/rust#151323Fixesrust-lang/rust#137916Fixesrust-lang/rust#138274
The problem is that stalled coroutine obligations can't be satisifed so that they cause normalization to fail in `mir_borrowck`.
Thus, we failed to register any opaque to storage in the next solver.
I fix it by checking these obligations earlier in `mir_borrowck`.
r? @lcnr
Remove some unnecessary `try`-related type annotations
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think they should be left alone.
skip codegen for intrinsics with big fallback bodies if backend does not need them
This hopefully fixes the perf regression from https://github.com/rust-lang/rust/pull/148478. I only added the intrinsics with big fallback bodies to the list; it doesn't seem worth the effort of going through the entire list.
Fixes https://github.com/rust-lang/rust/issues/149945
Cc @scottmcm @bjorn3
link modifier `export-symbols`: export all global symbols from selected uptream c static libraries
In order to be able to export symbols from a specified upstream C static library, I redesigned a solution that, compared to a previous PR rust-lang/rust#150335 I submitted, will not have any extra symbols leaking out.
The following points should be noted:
- This attribute will select and import the `Global` symbols of the first matching library it finds.
- Developers should ensure that there are no libraries with the same name.
- This modifier is only compatible with `static` linking kind
- By default, upstream C static libraries will not export their `Global` symbols regardless of whether `LTO` optimization is enabled. However, after enabling this attribute, if the upstream C static library has `LTO` optimization enabled, the compiler will issue an error to inform the developer that the linked C library is invalid.
The test code is the same as the PR rust-lang/rust#150335.
Here are the results:
1. `cargo +include-libs rustc --release -- -L. -lstatic:+export-symbols=c_add`
(or you can use `#[link(name = "c_add", kind= "static", modifier = "+export-symbols")]` in the file)
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
0000000000014f60 T c_add
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
0000000000014f70 T c_sub
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000014ee0 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_DeleteException@GCC_3.0
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
3. `cargo +nightly rustc --release -- -L ./`
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000011e10 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w gettid@GLIBC_2.30
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
r? @bjorn3
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think seeing the type would be better.
checksum-freshness: Fix invalid checksum calculation for binary files
Admittedly this is not the cleanest way to achieve this, but SourceMap is quite intertwined with source files being represented as Strings.
Tracking issue: https://github.com/rust-lang/cargo/issues/14136Closes: rust-lang/rust#151090
Remove `Deref`/`DerefMut` impl for `Providers`.
It's described as a "backwards compatibility hack to keep the diff small". Removing it requires only a modest amount of churn, and the resulting code is clearer without the invisible derefs.
r? @oli-obk
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
Destabilise `target-spec-json`
Per rust-lang/compiler-team#944:
> Per https://github.com/rust-lang/rust/issues/71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std).
>
> Current build-std RFCs (https://github.com/rust-lang/rfcs/pull/3873, https://github.com/rust-lang/rfcs/pull/3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc.
>
> De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.
