Revert "Structurally resolve correctly in check_pat_lit"
This reverts commit 54fb5a48b9. Also adds a couple of tests, and downgrades the existing `-Ztrait-solver=next` test to a known-bug.
Fixes#112993
Move windows-sys arm32 shim to c.rs
This moves the arm32 shim in to c.rs instead of appending to the generated file itself.
This makes it simpler to change these workarounds if/when needed. The downside is we need to exclude a couple of functions from being generated (see the comment). A metadata solution could help here but they'll be easy enough to add back if that happens.
Rollup of 4 pull requests
Successful merges:
- #112918 (display PID of process holding lock)
- #112990 (Add a regression test for #96699)
- #113011 (Add enum for `can_access_statics` boolean)
- #113018 (Fix test for #96258)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix test for #96258#98644 did not properly test enabling the problematic lint as a warning due to improper use of `compile-flags:` (missing `:`). This makes it use `#![warn]` instead, like in the reproducer.
cc #96258
Remove unnecessary `path` attribute
Follow up to #111401. I missed this at the time but it should now be totally unnecessary since the other include was removed.
r? `@workingjubilee`
Expose `compiler-builtins-weak-intrinsics` feature for `-Zbuild-std`
This was added in rust-lang/compiler-builtins#526 to force all compiler-builtins intrinsics to use weak linkage.
rustdoc: Align search results horizontally for easy scanning
The recent PR #110688 added info about an item's kind before its name in
search results. However, because the kind and name are inline with no
alignment, it's now hard to visually scan downward through the search
results, looking at item names. This PR fixes that by horizontally
aligning search results such that there are now two columns of
information.
r? `@GuillaumeGomez`
Before:
```
PS C:\Users\vboxuser\rust> ./x
x.ps1
PS C:\Users\vboxuser\rust>
```
After:
```
PS C:\Users\vboxuser\rust> ./x
x.ps1
C:\Users\vboxuser\rust\x.ps1 : C:\Users\vboxuser\rust\x.ps1: error: did not find python installed
help: consider installing it from https://www.python.org/downloads/windows/
At line:1 char:1
+ ./x
+ ~~~
+ CategoryInfo : NotInstalled: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,x.ps1
```
The existing message from the shell script is already decent and I decided not to change it:
```
$ ./x
Python was not found but can be installed from the Microsoft Store: ms-windows-store://pdp/?productid=9NJ46SX7X90P
```
Fix old python deprecation check in x.py
The warning suppression variable was not checked correctly.
I tested it with python 2.7 and it worked correctly.
bootstrap: Backup `settings.json` to the correct filename
The old code actually replaced `.json` with `.bak` (so, `settings.bak`),
rather than appending `.bak` as claimed (`settings.json.bak`).
`Path::set_extension` can instead be used with dots:
> The new extension may contain dots and will be used in its entirety,
> but only the part after the final dot will be reflected in
> `self.extension`.
r? ``@jyn514``
style-guide: Rewrite let-else section for clarity, without changing formatting
The section as written did not cover all cases, and left some of them
implicit. Rewrite it to systematically cover all cases. Place examples
immediately following the corresponding case.
In the process, reorder to move the simplest cases first: start with
single-line and add progressively more line breaks.
This does not change the meaning of the section at all, and in
particular does not change the defined style for let-else statements.
[-Ztrait-solver=next, mir-typeck] instantiate hidden types in the root universe
Fixes an ICE in the test `member-constraints-in-root-universe`.
Main motivation is to make #112691 pass under the new solver.
r? ``@compiler-errors``
The old code actually replaced `.json` with `.bak` (so, `settings.bak`),
rather than appending `.bak` as claimed (`settings.json.bak`).
`Path::set_extension` can instead be used with dots:
> The new extension may contain dots and will be used in its entirety,
> but only the part after the final dot will be reflected in
> self.extension.
