Modify GenericArg and Term structs to use strict provenance rules
This is the first PR to solve issue #119217 . In this PR, I have modified the GenericArg struct to use the `NonNull` struct as the pointer instead of `NonZeroUsize`. The change were tested by running `./x test compiler/rustc_middle`.
Resolves https://github.com/rust-lang/rust/issues/119217
r? `@WaffleLapkin`
Replacement of #114390: Add new intrinsic `is_var_statically_known` and optimize pow for powers of two
This adds a new intrinsic `is_val_statically_known` that lowers to [``@llvm.is.constant.*`](https://llvm.org/docs/LangRef.html#llvm-is-constant-intrinsic).` It also applies the intrinsic in the int_pow methods to recognize and optimize the idiom `2isize.pow(x)`. See #114390 for more discussion.
While I have extended the scope of the power of two optimization from #114390, I haven't added any new uses for the intrinsic. That can be done in later pull requests.
Note: When testing or using the library, be sure to use `--stage 1` or higher. Otherwise, the intrinsic will be a noop and the doctests will be skipped. If you are trying out edits, you may be interested in [`--keep-stage 0`](https://rustc-dev-guide.rust-lang.org/building/suggested.html#faster-builds-with---keep-stage).
Fixes#47234Resolves#114390
`@Centri3`
Return a finite number of AllocIds per ConstAllocation in Miri
Before this, every evaluation of a const slice would produce a new AllocId. So in Miri, this program used to have unbounded memory use:
```rust
fn main() {
loop {
helper();
}
}
fn helper() {
"ouch";
}
```
Every trip around the loop creates a new AllocId which we need to keep track of a base address for. And the provenance GC can never clean up that AllocId -> u64 mapping, because the AllocId is for a const allocation which will never be deallocated.
So this PR moves the logic of producing an AllocId for a ConstAllocation to the Machine trait, and the implementation that Miri provides will only produce 16 AllocIds for each allocation. The cache is also keyed on the Instance that the const is evaluated in, so that equal consts evaluated in two functions will have disjoint base addresses.
r? RalfJung
Use `assert_unchecked` instead of `assume` intrinsic in the standard library
Now that a public wrapper for the `assume` intrinsic exists, we can use it in the standard library.
CC #119131
Pack u128 in the compiler to mitigate new alignment
This is based on #116672, adding a new `#[repr(packed(8))]` wrapper on `u128` to avoid changing any of the compiler's size assertions. This is needed in two places:
* `SwitchTargets`, otherwise its `SmallVec<[u128; 1]>` gets padded up to 32 bytes.
* `LitKind::Int`, so that entire `enum` can stay 24 bytes.
* This change definitely has far-reaching effects though, since it's public.
Add `#[track_caller]` to the "From implies Into" impl
This pr implements what was mentioned in https://github.com/rust-lang/rust/issues/77474#issuecomment-1074480790
This follows from my URLO https://users.rust-lang.org/t/104497
```rust
#![allow(warnings)]
fn main() {
// Gives a good location
let _: Result<(), Loc> = dbg!(Err::<(), _>(()).map_err(|e| e.into()));
// still doesn't work, gives location of `FnOnce::call_once()`
let _: Result<(), Loc> = dbg!(Err::<(), _>(()).map_err(Into::into));
}
#[derive(Debug)]
pub struct Loc {
pub l: &'static std::panic::Location<'static>,
}
impl From<()> for Loc {
#[track_caller]
fn from(_: ()) -> Self {
Loc {
l: std::panic::Location::caller(),
}
}
}
```
Document some alternatives to `Vec::split_off`
One of the discussion points that came up in #119917 is that some people use `Vec::split_off` in cases where they probably shouldn't, because the alternatives (like `mem::take`) are hard to discover.
This PR adds some suggestions to the documentation of `split_off` that should point people towards alternatives that might be more appropriate for their use-case.
I've deliberately tried to keep these changes as simple and uncontroversial as possible, so that they don't depend on how the team decides to handle the concerns raised in #119917. That's why I haven't touched the existing documentation for `split_off`, and haven't added links to `split_off` to the documentation of other methods.
`rustc_mir_dataflow`: Restore removed exports
Added back previously available exports:
* `Forward`/`Backward`: used when implementing `AnalysisDomain`
* `Engine`: used in user's code to solve the dataflow problem
* `SwitchIntEdgeEffects`: used when implementing functions of the `Analysis` trait
* `graphviz`: potentially useful for debugging purposes
Closes#120130
fix: Drop guard was deallocating with the incorrect size
InPlaceDstBufDrop holds onto the allocation before the shrinking happens which means it must deallocate the destination elements but the source allocation.
Thanks `@cuviper` for spotting this.
Make stable_mir::with_tables sound
See the first commit for the actual soundness fix. The rest is just fallout from that and is entirely safe code. Includes most of #120120
The major difference to #120120 is that we don't need an unsafe trait, as we can now rely on the type system (the only unsafe part, and the actual source of the unsoundness was in `with_tables`)
r? `@celinval`
Implement iterator specialization traits on more adapters
This adds
* `TrustedLen` to `Skip` and `StepBy`
* `TrustedRandomAccess` to `Skip`
* `InPlaceIterable` and `SourceIter` to `Copied` and `Cloned`
The first two might improve performance in the compiler itself since `skip` is used in several places. Constellations that would exercise the last point are probably rare since it would require an owning iterator that has references as Items somewhere in its iterator pipeline.
Improvements for `Skip`:
```
# old
test iter::bench_skip_trusted_random_access ... bench: 8,335 ns/iter (+/- 90)
# new
test iter::bench_skip_trusted_random_access ... bench: 2,753 ns/iter (+/- 27)
```
Rollup of 8 pull requests
Successful merges:
- #116090 (Implement strict integer operations that panic on overflow)
- #118811 (Use `bool` instead of `PartiolOrd` as return value of the comparison closure in `{slice,Iteraotr}::is_sorted_by`)
- #119081 (Add Ipv6Addr::is_ipv4_mapped)
- #119461 (Use an interpreter in MIR jump threading)
- #119996 (Move OS String implementation into `sys`)
- #120015 (coverage: Format all coverage tests with `rustfmt`)
- #120027 (pattern_analysis: Remove `Ty: Copy` bound)
- #120084 (fix(rust-analyzer): use new pkgid spec to compare)
r? `@ghost`
`@rustbot` modify labels: rollup
coverage: Format all coverage tests with `rustfmt`
As suggested by <https://github.com/rust-lang/rust/pull/119984#discussion_r1452856806>.
Test files in `tests/` are normally ignored by `x fmt`, but sometimes those files end up being run through `rustfmt` anyway, either by `rust-analyzer` or by hand.
When that happens, it's annoying to have to manually revert formatting changes that are unrelated to the actual changes being made. So it's helpful for the tests in the repository to already have standard formatting beforehand.
However, there are several coverage tests that deliberately use non-standard formatting, so that line counts reveal more information about where code regions begin and end. In those cases, we can use `#[rustfmt::skip]` to prevent that code from being disturbed.
``@rustbot`` label +A-code-coverage
Move OS String implementation into `sys`
Part of #117276. The new structure is really useful here, since we can easily eliminate a number of ugly `#[path]`-based imports.
In the future, it might be good to move the WTF-8 implementation directly to the OS string implementation, I cannot see it being used anywhere else. That is a story for another PR, however.
Add Ipv6Addr::is_ipv4_mapped
This change consists of cherry-picking the content from the original PR[1], which got closed due to inactivity, and applying the following changes:
* Resolving merge conflicts (obviously)
* Linked to to_ipv4_mapped instead of to_ipv4 in the documentation (seems more appropriate)
* Added the must_use and rustc_const_unstable attributes the original didn't have
I think it's a reasonably useful method to have.
[1] https://github.com/rust-lang/rust/pull/86490
Use `bool` instead of `PartiolOrd` as return value of the comparison closure in `{slice,Iteraotr}::is_sorted_by`
Changes the function signature of the closure given to `{slice,Iteraotr}::is_sorted_by` to return a `bool` instead of a `PartiolOrd` as suggested by the libs-api team here: https://github.com/rust-lang/rust/issues/53485#issuecomment-1766411980.
This means these functions now return true if the closure returns true for all the pairs of values.
Implement strict integer operations that panic on overflow
This PR implements the first part of the ACP for adding panic on overflow style arithmetic operations (https://github.com/rust-lang/libs-team/issues/270), mentioned in #116064.
It adds the following operations on both signed and unsigned integers:
- `strict_add`
- `strict_sub`
- `strict_mul`
- `strict_div`
- `strict_div_euclid`
- `strict_rem`
- `strict_rem_euclid`
- `strict_neg`
- `strict_shl`
- `strict_shr`
- `strict_pow`
Additionally, signed integers have:
- `strict_add_unsigned`
- `strict_sub_unsigned`
- `strict_abs`
And unsigned integers have:
- `strict_add_signed`
The `div` and `rem` operations are the same as normal division and remainder but are added for completeness similar to the corresponding `wrapping_*` operations.
I'm not sure if I missed any operations, I basically found them from the `wrapping_*` and `checked_*` operations on both integer types.
Don't forget that the lifetime on hir types is `'tcx`
This PR just tracks the `'tcx` lifetime to wherever the original objects actually have that lifetime. This code is needed for https://github.com/rust-lang/rust/pull/107606 (now #120131) so that `ast_ty_to_ty` can invoke `lit_to_const` on an argument passed to it. Currently the argument is `&hir::Ty<'_>`, but after this PR it is `&'tcx hir::Ty<'tcx>`.
internal: add `max_line_length` to `.editorconfig`
This helps with setting proper visual guides/rulers for the right margin in some editors/IDEs (e.g. CLion)
Avoid code generation for ThinVec<Diagnostic>'s destructor in the query system
This avoids 2 instances of the destructor of `ThinVec<Diagnostic>` from being included in `execute_job`. It also outlines the cold branch in `store_side_effects` / `store_side_effects_for_anon_node`.
fix panic with reference in macro
it panic at `builder.make_mut(segment)`, where segment is from macro expand. And the usage reference in orginal macro call isn't a `PathSegment` so we can't update it in `apply_references`, I can't find a way to deal with it properly so here just filter out the reference in macro. LMK if there are better way to fix this
try to close https://github.com/rust-lang/rust-analyzer/issues/16328
Work through temporarily allowed clippy lints, part 1
This is the first batch of not allowing but actually fixing the clippy lints. Each commit removes one lint from the lint table and then fixes the resulting warnings.
Follow-up to #16401
