delete [allow(unused_unsafe)] from issue #74838
While looking into issue #111288 I noticed the following `#[allow(...)]` with a `FIXME` asking for it to be removed. Deleting the `#[allow(...)]` does not seem to break anything, it seems like the lint has been updated for unsafe blocks in macros?
Fix size_hint for EncodeUtf16
More realistic upper and lower bounds, and handle the case where the iterator is located within a surrogate pair.
Resolves#113897
Update the tracking issue for `const_cstr_from_ptr`
Tracking issue #101719 was for `const_cstr_methods`, #113219 is a new issue specific for `const_cstr_from_ptr`.
(I believe #101719 could also be closed)
```@rustbot``` label +T-libs-api +A-docs
remove the unstable `core::sync::atomic::ATOMIC_*_INIT` constants
Tracking issue: #99069
It would be weird to ever stabilise these as they are already deprecated.
Enable coinduction support for Safe Transmute
This patch adds the `#[rustc_coinductive]` annotation to `BikeshedIntrinsicFrom`, so that it's possible to compute transmutability for recursive types.
## Motivation
Safe Transmute currently already supports references (#110662). However, if a type is implemented recursively, it leads to an infinite loop when we try to check if transmutation is safe.
A couple simple examples that one might want to write, that are currently not possible to check transmutability for:
```rs
#[repr(C)] struct A(&'static B);
#[repr(C)] struct B(&'static A);
```
```rs
#[repr(C)]
enum IList<'a> { Nil, Cons(isize, &'a IList<'a>) }
#[repr(C)]
enum UList<'a> { Nil, Cons(usize, &'a UList<'a>) }
```
Previously, `@jswrenn` was considering writing a co-inductive solver from scratch, just for the `rustc_tranmsute` crate. Later on as I started working on Safe Transmute myself, I came across the `#[rustc_coinductive]` annotation, which is currently only being used for the `Sized` trait. Leveraging this trait actually solved the problem entirely, and it saves a lot of duplicate work that would have had to happen in `rustc_transmute`.
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
enable test_join test in Miri
Miri for quite a while now has a hack to support self-referential generators: non-`Unique` mutable references are exempt from aliasing conditions. So we can run this test now. (It passes.)
Also extend a comment in a Vec test, while I am at it.
Mark wrapped intrinsics as inline(always)
This should mitigate having the inliner decide not to inline when the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target features (e.g. PowerPC as today).
See https://github.com/rust-lang/stdarch/pull/1443#issuecomment-1613788080
This should mitigate having the inliner decide not to inline when
the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target
features (e.g. PowerPC as today).
Stabilize `const_cstr_methods`
This PR seeks to stabilize `const_cstr_methods`. Fixes most of #101719
## New const stable API
```rust
impl CStr {
// depends: memchr
pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError> {...}
// depends: const_slice_index
pub const fn to_bytes(&self) -> &[u8] {}
// depends: pointer casts
pub const fn to_bytes_with_nul(&self) -> &[u8] {}
// depends: str::from_utf8
pub const fn to_str(&self) -> Result<&str, str::Utf8Error> {}
}
```
I don't think any of these methods will have any issue when `CStr` becomes a thin pointer as long as `memchr` is const (which also allows for const `strlen`) .
## Notes
- `from_bytes_until_nul` relies on `const_slice_index`, which relies on `const_trait_impls`, and generally this should be avoided. After talking with Oli, it should be OK in this case because we could replace the ranges with pointer tricks if needed (worst case being those feature gates disappear). https://github.com/rust-lang/rust/pull/107624#discussion_r1101468480
- Making `from_ptr` const is deferred because it depends on `const_eval_select`. I have moved this under the new flag `const_cstr_from_ptr` https://github.com/rust-lang/rust/pull/107624#discussion_r1101555239
cc ``@oli-obk`` I think you're the const expert
``@rustbot`` modify labels: +T-libs-api +needs-fcp
This patch adds the `#[rustc_coinductive]` annotation to
`BikeshedIntrinsicFrom`, so that it's possible to compute transmutability for
recursive types.
Specialize `StepBy<Range<{integer}>>`
OLD
iter::bench_range_step_by_fold_u16 700.00ns/iter +/- 10.00ns
iter::bench_range_step_by_fold_usize 519.00ns/iter +/- 6.00ns
iter::bench_range_step_by_loop_u32 555.00ns/iter +/- 7.00ns
iter::bench_range_step_by_sum_reducible 37.00ns/iter +/- 0.00ns
NEW
iter::bench_range_step_by_fold_u16 49.00ns/iter +/- 0.00ns
iter::bench_range_step_by_fold_usize 194.00ns/iter +/- 1.00ns
iter::bench_range_step_by_loop_u32 98.00ns/iter +/- 0.00ns
iter::bench_range_step_by_sum_reducible 1.00ns/iter +/- 0.00ns
NEW + `-Ctarget-cpu=x86-64-v3`
iter::bench_range_step_by_fold_u16 22.00ns/iter +/- 0.00ns
iter::bench_range_step_by_fold_usize 80.00ns/iter +/- 1.00ns
iter::bench_range_step_by_loop_u32 41.00ns/iter +/- 0.00ns
iter::bench_range_step_by_sum_reducible 1.00ns/iter +/- 0.00ns
I have only optimized for walltime of those methods, I haven't tested whether it eliminates bounds checks when indexing into slices via things like `(0..slice.len()).step_by(16)`.
slice::from_raw_parts: mention no-wrap-around condition
Cc https://github.com/rust-lang/rust/issues/83996. This probably needs to be mentioned in more places, so I am not closing that issue, but this here should help at least.
