Document `unreachable!` custom panic message
The `unreachable!` docs previously did not mention that there was a second form, `unreachable!("message")` that could be used to specify a custom panic message,
The docs now mention this feature in the same wording as currently used for `unimplemented!`:
https://doc.rust-lang.org/core/macro.unimplemented.html#panics
Add more comments to explain the code to generate the search index
Fixes#90766.
I tried to put comments when the code wasn't easy to understand at first sight and added more documentation on the recursive function. Please tell me if I misused the terminology or if comments can be improved or added into other places.
r? `@notriddle`
Shorten Span of unused macro lints
The span has been reduced to the actual ident of the macro, instead of linting the
*whole* macro.
Closes#90745
r? ``@estebank``
Optimize pattern matching
These commits speed up the `match-stress-enum` benchmark, which is very artificial, but the changes are simple enough that it's probably worth doing.
r? `@Nadrieril`
As discussed here
https://github.com/rust-lang/rust/pull/88300#issuecomment-936097710
I felt this was the best place to put this (rather than next to
ExitStatusExt). After all, it's a property of the ExitStatus type on
Unix.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
As discussed here
https://github.com/rust-lang/rust/pull/88300#issuecomment-936085371
exit is (conventionally) a library function, with _exit being the
actual system call.
I have checked the other references and they say "if the process
terminated by calling `exti`". I think despite the slight
imprecision (strictly, it should read iff ... `_exit`), this is
clearer. Anyone who knows about the distinction between `exit` and
`_exit` will not be confused.
`_exit` is the correct traditional name for the system call, despite
Linux calling it `exit_group` or `exit`:
https://www.freebsd.org/cgi/man.cgi?query=_exit&sektion=2&n=1
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
The `unreachable!` docs previously did not mention that there was a second
form, `unreachable!("message")` that could be used to specify a custom panic
message,
The docs now mention this in the same style as currently used for `unimplemented!`:
https://doc.rust-lang.org/core/macro.unimplemented.html#panics
Fix assertion failures in `OwnedHandle` with `windows_subsystem`.
As discussed in #88576, raw handle values in Windows can be null, such
as in `windows_subsystem` mode, or when consoles are detached from a
process. So, don't use `NonNull` to hold them, don't assert that they're
not null, and remove `OwnedHandle`'s `repr(transparent)`. Introduce a
new `HandleOrNull` type, similar to `HandleOrInvalid`, to cover the FFI
use case.
r? `@joshtriplett`
Added the --temps-dir option
Fixes#10971.
The new `--temps-dir` option puts intermediate files in a user-specified directory. This provides a fix for the issue where parallel invocations of rustc would overwrite each other's intermediate files.
No files are kept in the intermediate directory unless `-C save-temps=yes`.
If additional files are specifically requested using `--emit asm,llvm-bc,llvm-ir,obj,metadata,link,dep-info,mir`, these will be put in the output directory rather than the intermediate directory.
This is a backward-compatible change, i.e. if `--temps-dir` is not specified, the behavior is the same as before.
adjust documented inline-asm register constraints
This change more clearly specifies how `reg` and `reg_thumb` work with ARM, Thumb2, and Thumb1 code.
Based upon the [llvm documentation](https://llvm.org/docs/LangRef.html#supported-constraint-code-list) for register constraint codes.
To be clear, this just updates the docs to match what already happens with rustc/llvm.
No change in the compiler is required to make it match this new documentation.
Only use `clone3` when needed for pidfd
In #89522 we learned that `clone3` is interacting poorly with Gentoo's
`sandbox` tool. We only need that for the unstable pidfd extensions, so
otherwise avoid that and use a normal `fork`.
This is a re-application of beta #89924, now that we're aware that we need
more than just a temporary release fix. I also reverted 12fbabd27f, as
that was just fallout from using `clone3` instead of `fork`.
r? `@Mark-Simulacrum`
cc `@joshtriplett`
Remove potential useless data for search index
I uncovered this case when working on https://github.com/rust-lang/rust/pull/90726 to debug https://github.com/rust-lang/rust/pull/90385.
Explanations: if we have a full generic, we check if it has generics then we do the following:
* If it has only one generic, we remove one nested level in order to not keep the "parent" generic (since it has empty name, it's useless after all).
* Otherwise we add it alongside its generics.
However, I didn't handle the case where a generic had no generics. Meaning that we were adding items with empty names in the search index. So basically useless data in the search index.
r? `@camelid`
Use computed visibility in rustdoc
This PR changes `librustdoc` to use computed visibility instead of syntactic visibility. It was initially part of #88019, but was separated due to concerns that it might cause a regression somewhere we couldn't predict.
r? `@jyn514`
cc `@cjgillot` `@petrochenkov`
Update llvm submodule
This includes debug info generation fix, that fixes#90301.
Also includes WASM backend related fix for https://bugs.llvm.org/show_bug.cgi?id=52352
(I haven't found a corresponding Rust bug).