stabilize #[panic_handler]
closes#44489
### Update(2018-09-07)
This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946
Documentation PRs:
- Reference. https://github.com/rust-lang-nursery/reference/pull/362
- Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75
---
`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.
(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054
Some unresolved questions from #44489:
> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".
The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.
> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?
I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?
---
Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.
cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
I think it might be used in some other things, but I'm not fluent enough
at sifting through the rust compiler's source code to find every use of
a specific keyword.
This leaves the question of how to document the `extern` keyword, what
with how much overlap it has with `crate`, but that's used with ABI
stuff so that should be fine.
Update Cargo.lock
This also includes major version bumps for the rand crate used by core, std, and alloc tests, among other crates (regex, etc.) used elsewhere. Since these are all internal there should be no user-visible changes.
r? @alexcrichton
Allow to check if sync::Once is already initialized
Hi!
I propose to expose a way to check if a `Once` instance is initialized.
I need it in `once_cell`. `OnceCell` is effetively a pair of `(Once, UnsafeCell<Option<T>>)`, which can set the `T` only once. Because I can't check if `Once` is initialized, I am forced to add an indirection and check the value of ptr instead:
8127a81976/src/lib.rs (L423-L429)8127a81976/src/lib.rs (L457-L461)
The `parking_lot`'s version of `Once` exposes the state as an enum: https://docs.rs/parking_lot/0.6.3/parking_lot/struct.Once.html#method.state.
I suggest, for now, just to add a simple `bool` function: this fits my use-case perfectly, exposes less implementation details, and is forward-compatible with more fine-grained state checking.
Turns out writing docs on keywords that are used in multiple different
places in entirely different contexts gets a little harder. I put a
footnote on `*const` syntax just to make sure you can find it if need
be, but it might need more detail.
The whole keyword docs thing is pretty new in Rust's history and needs
some work before it's a shining gem. Here's hoping I can provide that.
I basically shoved in a bunch of the most important information from the
reference and the book, along with leaving links to both at the end. I
don't think keyword docs need to have complete detail, just all the
broad strokes, so if someone's confused about a usage of a keyword they
can look at the std documentation for that keyword.
Reduce number of syscalls in `rand`
This skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
Add Error::source method per RFC 2504.
This implements part of RFC 2504.
* Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable.
* Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in #52994, which we haven't finalized).
* Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other).
@rfcbot fcp merge
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
fix a typo: taget_env -> target_env
This typo was introduced in https://github.com/rust-lang/rust/pull/47334. A couple tests bitrotted as a result, so we fix those too, and move them to a more sensible place.
Is there some lint we could turn on that would've caught this? It's a drag that cfg typos can silently pass through the compiler.
document the platform-specific behavior of Command::current_dir
See also https://github.com/rust-lang/rust/issues/37868.
Here's my initial wording:
> Note that if the program path is relative (e.g. `"./script.sh"`), the interaction between that path and `current_dir` varies across platforms. Windows currently ignores `current_dir` when locating the program, but Unix-like systems interpret the program path relative to `current_dir`. These implementation details aren't considered stable, and it's recommended to call `canonicalize` to get an absolute program path instead of using relative paths and `current_dir` together.
I'd like to get feedback on:
- _Should_ we consider those details stable? It might be disruptive to change them, regardless of what I can get away with claiming in docs :)
- Is `canonicalize` an appropriate recommendation? As discussed in #37868 above, there are reasons it's not called automatically in the `Command` implementation.
Warn on anon params in 2015 edition
cc #41686https://github.com/rust-lang/rfcs/pull/2522
cc @Centril @nikomatsakis
TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.
EDIT: It seems I already did the last two in #48309
move the Pin API into its own module for centralized documentation
This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.
r? @RalfJung
