Add hooks for Miri panic unwinding
This commits adds in some additional hooks to allow Miri to properly
handle panic unwinding. None of this should have any impact on CTFE mode
This supports https://github.com/rust-lang/miri/pull/693
remove vestigial comments referring to defunct numeric trait hierarchy
I've been poking around the numeric trait hierarchy and also some of the actual numeric type implementations.
This is a small change but a matter of effective communication. I looked for other related references and saw none.
invalid_value lint: use diagnostic items
This adjusts the invalid_value lint to use diagnostic items.
@Centril @oli-obk For some reason, this fails to recognize `transmute` -- somehow the diagnostic item is not found. Any idea why?
r? @Centril
Cc https://github.com/rust-lang/rust/issues/66075
Rollup of 6 pull requests
Successful merges:
- #65949 (Move promotion into its own pass)
- #65994 (Point at where clauses where the associated item was restricted)
- #66050 (Fix C aggregate-passing ABI on powerpc)
- #66134 (Point at formatting descriptor string when it is invalid)
- #66172 (Stabilize @file command line arguments)
- #66226 (add link to unstable book for asm! macro)
Failed merges:
r? @ghost
Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`
Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.
All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics.
Example:
```rust
use std::mem::MaybeUninit;
let input = b"Foo";
let f = u8::to_ascii_uppercase;
let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
vec = input.iter().map(f).collect::<Vec<u8>>();
&vec
};
assert_eq!(output, b"FOO");
```
Have tidy ensure that we document all `unsafe` blocks in libcore
cc @rust-lang/libs
I documented a few and added ignore flags on the other files. We can incrementally document the files, but won't regress any files this way.
Add future incompatibility lint for `array.into_iter()`
This is for #65819. This lint warns when calling `into_iter` on an array directly. That's because today the method call resolves to `<&[T] as IntoIterator>::into_iter` but that would change when adding `IntoIterator` impls for arrays. This problem is discussed in detail in #65819.
We still haven't decided how to proceed exactly, but it seems like adding a lint is a good idea regardless?
Also: this is the first time I implement a lint, so there are probably a lot of things I can improve. I used a different strategy than @scottmcm describes [here](https://github.com/rust-lang/rust/pull/65819#issuecomment-548667847) since I already started implementing this before they commented.
### TODO
- [x] Decide if we want this lint -> apparently [we want](https://github.com/rust-lang/rust/pull/65819#issuecomment-548964818)
- [x] Open a lint-tracking-issue and add the correct issue number in the code -> https://github.com/rust-lang/rust/issues/66145
Fixed PhantomData markers in Arc and Rc
Include owned internal structs in `PhantomData` markers in `Arc` (`PhantomData<T>` => `PhantomData<ArcInner<T>>`) and `Rc` (`PhantomData<T>` => `PhantomData<RcBox<T>>`).
improve from_raw_parts docs
Triggered by https://github.com/rust-lang/rfcs/pull/2806. Hopefully this helps clarify that joining slices across allocations is not possible in Rust currently.
r? @Centril
Improve uninit/zeroed lint
* Also warn when creating a raw pointer with a NULL vtable.
* Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
gate rustc_on_unimplemented under rustc_attrs
Move `rustc_on_implemented` from the `on_implemented` gate to `rustc_attrs` as it is internal.
Closes#29628
r? @varkor
As we might want to add `IntoIterator` impls for arrays in the future,
and since that introduces a breaking change, this lint warns and
suggests using `iter()` instead (which is shorter and more explicit).
caller_location: point to macro invocation sites, like file!/line!, and use in core::panic!.
The main change here is to `core::panic!`, trying to fix this remaining regression: https://github.com/rust-lang/rust/pull/65927#issuecomment-547625147
However, in order for `caller_location` to be usable from macros the same way `file!()`/`line!()` are, it needs to have the same behavior (of extracting the macro invocation site `Span` and using that).
Arguably we would've had to do this at some point anyway, if we want to use `#[track_caller]` to replace the `file!()`/`line!()` uses from macros, but I'm not sure the RFC mentions this at all.
r? @petrochenkov cc @anp @nnethercote
Improve MaybeUninit::get_{ref,mut} documentation
As mentioned in https://github.com/rust-lang/rust/issues/63568#issuecomment-544106668, `MaybeUninit`'s `get_{ref,mut}` documentation is lacking, so this PR attempts to fix that.
That being said, and as @RalfJung mentions in that thread,
> In particular, we should clarify that all the UB rules for these methods equally apply when calling the raw ptr methods and creating a reference manually.
these other docs also need to be improved, which I can do in this PR ~~(hence the `[WIP]`)~~.
Finally, since all these documentations are related to clearly establishing when dealing with uninitialized memory which patterns are known to be sound and which patterns are currently UB (that is, until, if ever, the rules around references to unintialized integers get relaxed, this documentation will treat them as UB, and advise against such patterns (_e.g._, it is not possible to use uninitialized buffers with the `Read` API)), I think that adding even more examples to the main documentation of `MaybeUninit` inherent definition wouldn't hurt either.
___
- [Rendered](http://dreamy-ritchie-99d637.netlify.com/core/mem/union.maybeuninit#method.get_ref)
doc(str): show example of chars().count() under len()
the docs are great at explaining that .len() isn't like in other
languages but stops short of explaining how to get the character length.
Improved std::iter::Chain documentation
Replaces `strings two iterators` by `links two iterators` in `std::iter::Chain` documentation.
I didn't find any meaning of `strings` which can be evaluated as `links` or `joins`.
I don't think that `std::iter:Chain` works as a stringer or plays billiards. (https://www.lexico.com/en/definition/string).
