chore: Remove repeated words (extension of #124924)
When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.
Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
Directly implement native exception raise methods in miri
This implements the `_Unwind_RaiseException` function used on pretty much every unix system for starting unwinding. This allows removing the miri special case from libpanic_unwind for unix.
Windows still needs `miri_start_unwind` as SEH unwinding isn't supported by miri. Unlike DWARF unwinding, SEH preserves all stack frames until right after the do_catch function has executed. Because of this panic_unwind stack allocates the exception object. Miri can't currently model unwinding without destroying stack frames and as such will report a use-after-free of the exception object.
Windows still needs the old custom ABI as SEH unwinding isn't supported
by miri. Unlike DWARF unwinding it preserves all stack frames until
right after the do_catch function has executed. Because of this
panic_unwind stack allocates the exception object. Miri can't currently
model unwinding without destroying stack frames and as such will report
a use-after-free of the exception object.
Rollup of 7 pull requests
Successful merges:
- #123709 (Update documentation related to the recent cmd.exe fix)
- #124304 (revise the interpretation of ReadDir for HermitOS)
- #124708 (Actually use the `#[do_not_recommend]` attribute if present)
- #125252 (Add `#[inline]` to float `Debug` fallback used by `cfg(no_fp_fmt_parse)`)
- #125261 (crashes: add more)
- #125270 (Followup fixes from #123344)
- #125275 (Migrate `run-make/rustdoc-scrape-examples-test` to new `rmake.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
Actually use the `#[do_not_recommend]` attribute if present
This change tweaks the error message generation to actually use the `#[do_not_recommend]` attribute if present by just skipping the marked trait impl in favour of the parent impl. It also adds a compile test for this behaviour. Without this change the test would output the following error:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
Note how that mentions `&str: Expression` before and now mentions `&str: AsExpression<Integer>` instead which is much more helpful for users.
Open points for further changes before stabilization:
* We likely want to move the attribute to the `#[diagnostic]` namespace to relax the guarantees given?
* How does it interact with the new trait solver?
r? `@estebank`
revise the interpretation of ReadDir for HermitOS
HermitOS supports getdents64. As under Linux, the dirent64 entry `d_off` is not longer used, because its definition is not clear. Instead of `d_off` the entry `d_reclen` is used to determine the end of the dirent64 entry.
In addition, take up `@workingjubilee` suggestion from the discussions in rust-lang/rust#115984 to increase the readability.
Hermit is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Update documentation related to the recent cmd.exe fix
Fix some grammar nits, change `bat` (extension) -> `batch` (file), and make line wrapping more consistent.
CI: fix toolstate publishing
Toolstate publishing after something broke was not working (discovered [here](https://github.com/rust-lang/rust/pull/124050#issuecomment-2111292015)). The toolstate env. vars should only be needed for the publishing step, so I moved them there.
The toolstate script is also being checked in `mingw-check` on PR and auto CI, but it doesn't really seem to do anything, and it shouldn't require the token.
This change tweaks the error message generation to actually use the
`#[do_not_recommend]` attribute if present by just skipping the marked
trait impl in favour of the parent impl. It also adds a compile test for
this behaviour. Without this change the test would output the following
error:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
Note how that mentions `&str: Expression` before and now mentions `&str:
AsExpression<Integer>` instead which is much more helpful for users.
Open points for further changes before stabilization:
* We likely want to move the attribute to the `#[diagnostic]` namespace
to relax the guarantees given?
* How does it interact with the new trait solver?
Fix#124275: Implemented Default for `Arc<str>`
With added implementations.
```
GOOD Arc<CStr>
BROKEN Arc<OsStr> // removed
GOOD Rc<str>
GOOD Rc<CStr>
BROKEN Rc<OsStr> // removed
GOOD Rc<[T]>
GOOD Arc<[T]>
```
For discussion of https://github.com/rust-lang/rust/pull/124367#issuecomment-2091940137.
Key pain points currently:
> I've had a guess at the best locations/feature attrs for them but they might not be correct.
> However I'm unclear how to get the OsStr impl to compile, which file should they go in to avoid the error below? Is it possible, perhaps with some special std rust lib magic?
Joshua Wong