Fast path for processing some obligations in the new solver
Fast path applies to:
- Dyn compatibility predicates
- Region and type outlives predicates
- Trivially sized predicates
Emit a warning if the doctest `main` function will not be run
Fixes#140310.
I think we could try to go much further like adding a "link" (ie UI annotations) on the `main` function in the doctest. However that will require some more computation, not sure if it's worth it or not. Can still be done in a follow-up if we want it.
For now, this PR does two things:
1. Pass the `DiagCtxt` to the doctest parser to emit the warning.
2. Correctly generate the `Span` to where the doctest is starting (I hope the way I did it isn't too bad either...).
cc `@fmease`
r? `@notriddle`
Match on lang item kind instead of using an if/else chain
Similar to how the new solver does this. Just noticed while I was adding a new entry to the chain 😆
collect doc alias as tips during resolution
Close#124273
Collect the symbol in the doc alias attributes and provide a tip when a match is found.
r? `@estebank`
[win][ci] Update LLVM toolchain used to build LLVM to 20
While trying to get the aarch64-msvc build working correctly (#140136), I needed to update the version of LLVM used to build LLVM in Windows CI runners to 20 (as this has improved support for Arm64 and Arm64EC on Windows).
This catches Windows up to Linux which was updated to 20 by #137189
try-job: `x86_64-apple-*`
try-job: `aarch64-apple`
try-job: `x86_64-msvc-*`
try-job: `i686-msvc-*`
try-job: `x86_64-mingw-*`
use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
Add TRACING_ENABLED to Machine and add enter_trace_span!()
This PR adds the necessary infrastructure to make it possible to do tracing calls from within `rustc_const_eval` when running Miri, while making sure they don't impact the performance of normal compiler execution. This is done by adding a `const` boolean to `Machine`, false by default, but that will be set to true in Miri only. The tracing macro `enter_trace_span!()` checks if it is true before doing anything, and since the value of a `const` is known at compile time, if it it false it the whole tracing call should be optimized out.
I will soon open further PRs to add tracing macro calls similar to this one, so that afterwards it will be possible to learn more about Miri's time spent in the various interpretation steps:
```rs
let _guard = enter_trace_span!(M, "eval_statement", "{:?}", stmt);
```
r? `@RalfJung`
Rollup of 7 pull requests
Successful merges:
- #139419 (Error on recursive opaque ty in HIR typeck)
- #141236 (Resolved issue with mismatched types triggering ICE in certain scenarios)
- #141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
- #141269 (rustc-dev-guide subtree update)
- #141275 (`gather_locals`: only visit guard pattern guards when checking the guard)
- #141279 (`lower_to_hir` cleanups)
- #141285 (Add tick to `RePlaceholder` debug output)
r? `@ghost`
`@rustbot` modify labels: rollup
`gather_locals`: only visit guard pattern guards when checking the guard
When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and local declarations in the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once".
Tracking issue for guard patterns: #129967
update llvm-tools logic for `dist` and `install` steps
First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect.
Fixes#140913
[win][CI] Convert paths to Windows format before adding to PATH
While trying to get the `aarch64-msvc` build working correctly (#140136), I noticed that the `PATH` observed during the Rust steps of the build on Windows builds had some entries still in MinGW format, which means that Windows would not be able to use them correctly:
From <https://github.com/rust-lang/rust/actions/runs/14606167901/job/40975555680#step:28:192> note the path for `ninja` and `sccache`.
```
PATH = Some(C:\a\rust\rust\src\ci\citool\../../../build/citool\debug\deps;C:\a\rust\rust\src\ci\citool\../../../build/citool\debug;C:\Users\runneradmin\.rustup\toolchains\stable-aarch64-pc-windows-msvc\lib\rustlib\aarch64-pc-windows-msvc\lib;C:\Program Files\Git\clangarm64/bin;C:\Program Files\Git\usr\bin;C:\Users\runneradmin\bin;/c/a/rust/rust/ninja;/c/a/rust/rust/sccache;C:\Users\runneradmin/.cargo/bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS\;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\3.3.1\x64;C:\mingw64\bin;C:\Program Files\dotnet;C:\Program Files\MySQL\MySQL Server 8.0\bin;C:\Program Files (x86)\R\R-4.4.2\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\SeleniumWebDrivers\EdgeDriver\;C:\SeleniumWebDrivers\ChromeDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.21.13\arm64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.0.7\x64\bin;C:\Program Files\OpenSSL\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.442-6\x64\bin;C:\Program Files (x86)\ImageMagick-7.1.1-Q16-HDRI;C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\ProgramData\Chocolatey\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files\Microsoft SQL Server\160\DTS\Binn\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.9.9\bin;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files\Git\clangarm64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps)
```
The fix for this is to use `cygpath` to convert from the Cygwin format back to native Windows format before adding to the `PATH`.
---
try-job: dist-aarch64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-msvc-1
try-job: i686-msvc-2
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
try-job: dist-i686-mingw
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test
PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor.
Adding this flag caused issues with LLD, as it doesn't recognize it.
Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning.
Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134>
This PR supersedes #140977
r? ```@jieyouxu```
Remove #![feature(let_chains)] from library and src/librustdoc
PR https://github.com/rust-lang/rust/pull/132833 has stabilized the `let_chains` feature. This PR removes the last occurences from the library, the compiler, and librustdoc (also because #140887 missed the conditional in one of the crates as it was behind the "rustc" feature).
We keep `core` as exercise for the future as updating it is non-trivial (see PR thread).
Add per page TOC in the `rustc` book
This PR adds per page Table of Content (TOC) in the `rustc` book (to be extended in the future to our other books).
The goal is to easy the navigation inside the page by providing quick overview of the page content and our position inside that page.
That functionality is unfortunately not available natively in `mdbook`, which prompted community members to create [mdBook-pagetoc](https://github.com/JorelAli/mdBook-pagetoc/) (which this PR is heavily inspired by). It's "only" a JS file (to handle the TOC) and a CSS file (to handle the margin, colors, screen size, ...), there is no "post-processor" needed (in mdbook sense).
Live preview at: http://urgau.rf.gd/book
r? ```@jieyouxu```
move expensive layout sanity check to debug assertions
It is [hard to fix](https://github.com/rust-lang/rust/issues/141006#issuecomment-2883415000) the slowness in the uninhabitedness computation for very big types but we can fix the very specific case of them being called during the layout sanity checks, as described in #140944.
So this PR moves this uninhabitedness check to the other expensive layout sanity checks that are ran under `debug_assertions`.
It makes building the `lemmy_api_routes` crate's self-profile `layout_of` query go from
```
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
| Item | Self time | % of total time | Time | Item count | Incremental result hashing time |
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
| layout_of | 63.02s | 41.895 | 244.26s | 123703 | 50.30ms |
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
```
on master (2m17s total), to
```
| layout_of | 330.21ms | 0.372 | 26.90s | 123703 | 53.19ms |
```
with this PR (1m15s total).
(Note that the [perf run results](https://github.com/rust-lang/rust/pull/141039#issuecomment-2884688756) below look a bit better than [an earlier run](https://perf.rust-lang.org/compare.html?start=4eca99a18eab3d4e28ed1ce3ee620d442955a470&end=c4a00993f8ee02c7565e7be652608817ea2fb97d&stat=instructions:u) I did in another PR. There may be some positive noise there, or post-merge results could differ a bit)
Since we discussed this today, r? `@compiler-errors` — and cc `@lcnr` and `@RalfJung.`
Merge mir query analysis invocations
r? `@ghost`
same thing as https://github.com/rust-lang/rust/pull/140854 just a different set of queries
Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec<QueryResult> lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
Initial implementation of `core_float_math`
Since [1], `compiler-builtins` makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in `core`, so begin this process here.
It is not possible to provide inherent methods in both `core` and `std`
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.
For `f16` and `f128`, everything is unstable so we can move the inherent
methods.
The following are included to start:
* floor
* ceil
* round
* round_ties_even
* trunc
* fract
* mul_add
* div_euclid
* rem_euclid
* powi
* sqrt
* abs_sub
* cbrt
These mirror the set of functions that we have in `compiler-builtins`
since [1], with the exception of `powi` that has been there longer.
Details for each of the changes is in the commit messages.
Tracking issue: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
try-job: aarch64-gnu
tru-job: armhf-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
Revert "Fix linking statics on Arm64EC #140176"
This reverts PR #140176.
Unfortunately, this will reopen https://github.com/rust-lang/rust/issues/138541 (re-breaking the `arm64ec-pc-windows-msvc` target).
Unfortunately, multiple people are [reporting linker warnings related to `__rust_no_alloc_shim_is_unstable`](https://github.com/rust-lang/rust/pull/140176#issuecomment-2879715554) after this change in `x86_64-pc-windows-msvc` as well. The solution isn't quite clear yet, let's revert to avoid the linker warnings on the Tier 1 MSVC target for now[^timing], and try a reland with a determined solution for `__rust_no_alloc_shim_is_unstable`.
Judging from [people reporting that they are observing this also when bootstrapping w/ stage0 rustc](https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433), we may have to cut a new beta and then repoint stage0 against that newer beta?
cc `@dpaoliello` `@wesleywiser`
r? `@wesleywiser` (or compiler)
[^timing]: Note that it's still RustWeek this week, so most team members are N/A.
trait_sel: deep reject `match_normalize_trait_ref`
Spotted during an in-person review of #137944 at RustWeek: `match_normalize_trait_ref` could be using `DeepRejectCtxt` to exit early as an optimisation for projection candidates, like is done with param candidates.
r? `@lcnr`
cc `@oli-obk`
Invoke a query only when it doesn't return immediately anyway
This should cause less query key caching and less dep graph data, hopefully resulting in some perf improvements
bors
Matthias Krüger
Tshepang Mbambo
许杰友 Jieyou Xu (Joe)
Stan Manilov
nora
The rustc-dev-guide Cronjob Bot
León Orell Valerian Liehr
Mahmoud Mazouz
Jieyou Xu