`ByRef` const values have no identity beyond their value, we should not treat them as having identity. The `AllocId` often differed between equal constants, because of the way that the miri-engine evaluates constants.
Refactor interning to properly mark memory as mutable or immutable
r? @RalfJung
This implementation is incomplete out of multiple reasons
* [ ] add `-Zunleash_the_miri_inside_of_you` tests
* [ ] report an error if there's an `UnsafeCell` behind a reference in a constant
* [ ] make validity checks actually test whether the mutability of their allocations match what they see in the type
Rollup of 11 pull requests
Successful merges:
- #61505 (Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages)
- #61701 (move stray run-pass const tests into const/ folder)
- #61748 (Tweak transparent enums and unions diagnostic spans)
- #61802 (Make MaybeUninit #[repr(transparent)])
- #61839 (ci: Add a script for generating CPU usage graphs)
- #61842 (Remove unnecessary lift calls)
- #61843 (Turn down the myriad-closures test)
- #61896 (rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.)
- #61898 (syntax: Factor out common fields from `SyntaxExtension` variants)
- #61938 (create an issue for miri even in status test-fail)
- #61941 (Preserve generator and yield source for error messages)
Failed merges:
r? @ghost
Preserve generator and yield source for error messages
Previously, error messages after HIR lowering all referred
to generators and yield, regardless of whether the original
source was a generator or an async/await body. This change
tracks the kind of each generator and yield source in order
to provide appropriately tailored error messages.
Fixes#60615.
Turn down the myriad-closures test
This tests takes nearly 5 minutes to compile on CI where the CPUs we
have aren't exactly the fastest. This test does actually require all
closures to exist to exhibit the original bug, but it seems a little
excessive to test a single bug on CI on all platforms which simply pegs
a single CPU for 5 minutes with no parallelism opportunities, so this
turns down the test to still exercise it somewhat at least.
Previously, error messages after HIR lowering all referred
to generators and yield, regardless of whether the original
source was a generator or an async/await body. This change
tracks the kind of each generator and yield source in order
to provide appropriately tailored error messages.
Refactor C FFI variadics to more closely match their C counterparts, and add Clone implementation
We had to make some changes to expose `va_copy` and `va_end` directly to users (mainly for C2Rust, but not exclusively):
- redefine the Rust variadic structures to more closely correspond to C: `VaList` now matches `va_list`, and `VaListImpl` matches `__va_list_tag`
- add `Clone` for `VaListImpl`
- add explicit `as_va_list()` conversion function from `VaListImpl` to `VaList`
- add deref coercion from `VaList` to `VaListImpl`
- add support for the `asmjs` target
All these changes were needed for use cases like:
```Rust
let mut ap2 = va_copy(ap);
vprintf(fmt, ap2);
va_end(&mut ap2);
```
Make use of `ptr::null(_mut)` instead of casting zero
There are few places that I don't replace the zero casting pointer with `ptr::null`
or `ptr::null_mut`:
```bash
% git grep -E '[ ([{]0 as \*'
src/libcore/ptr/mod.rs:216:pub const fn null<T>() -> *const T { 0 as *const T }
src/libcore/ptr/mod.rs:231:pub const fn null_mut<T>() -> *mut T { 0 as *mut T }
src/test/run-pass/consts/const-cast-ptr-int.rs:12:static a: TestStruct = TestStruct{x: 0 as *const u8};
src/test/ui/issues/issue-45730.rs:5: let x: *const _ = 0 as *const _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.rs:8: let x = 0 as *const i32 as *const _ as *mut _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.stderr:14:LL | let x: *const _ = 0 as *const _;
src/test/ui/issues/issue-45730.stderr:24:LL | let x = 0 as *const i32 as *const _ as *mut _;
src/test/ui/lint/lint-forbid-internal-unsafe.rs:15: println!("{}", evil!(*(0 as *const u8)));
src/test/ui/order-dependent-cast-inference.rs:5: let mut y = 0 as *const _;
src/test/ui/order-dependent-cast-inference.stderr:4:LL | let mut y = 0 as *const _;
```
r? @sfackler
Help LLVM better optimize slice::Iter(Mut)::len
r? @RalfJung
I've included a codegen test that fails without this change as a demonstration of usefulness.
Replace some uses of NodeId with HirId
We are still using `NodeId` in some spots where we could use `HirId` instead; this PR targets some of these spots and removes some of the associated `hir::map` functions.
test more variants of enum-int-casting
As I learned in https://github.com/rust-lang/rust/pull/61673#issuecomment-500213506, there is a code path we are not testing yet. Looks like enum-int-casting with and without an intermediate let-binding is totally different.
EDIT: The reason for this is to get rid of the cycle in definitions such as:
```rust
enum Foo {
A = 0,
B = Foo::A as isize + 2,
}
```
This has historically been supported, so a hack adding special treatment to `Enum::Variant as _` was added to keep supporting it.
weird-exprs: if if if if
The `if` keyword can be chained as long as there are enough `{...} else {...}` following, and they all return a `bool` (not required for the last one).
`if` expression can be also put inside a `match` arm guard, thus making the whole thing a little bit more confusing.
Discovered this clusterfunk while reading the reference because I have nothing better to do.
Optimize matches
Attempt to fix or improve #60571
This is breaking some diagnostics because the MIR for match arms isn't in source order any more.
cc @centril
Rollup of 6 pull requests
Successful merges:
- #61785 (note some safety concerns of raw-ptr-to-ref casts)
- #61805 (typeck: Fix ICE for blocks in repeat expr count.)
- #61813 (Remove some unnecessary symbol interner ops)
- #61824 (in which we decline to lint single-use lifetimes in `derive`d impls)
- #61844 (Change `...` to `..=` where applicable)
- #61854 (Minor cosmetic improvements to accompany PR 61825)
Failed merges:
r? @ghost
typeck: Fix ICE for blocks in repeat expr count.
Fixes#61336 (again). This PR fixes an ICE that occured when a block expression resolving to a const generic was used for the count of an array repeat expression.
r? @varkor
Limit dylib symbols
This makes `windows-gnu` match the behavior of `windows-msvc`. It probably doesn't make sense to export these symbols on other platforms either.
type_alias_enum_variants: fix#61801; allow a path pattern to infer
Fix#61801.
Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression.
Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...)
The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler.
r? @petrochenkov
cc @eddyb @alexreg
cc https://github.com/rust-lang/rust/pull/61682
cc https://github.com/rust-lang/rust/issues/49683
This tests takes nearly 5 minutes to compile on CI where the CPUs we
have aren't exactly the fastest. This test does actually require all
closures to exist to exhibit the original bug, but it seems a little
excessive to test a single bug on CI on all platforms which simply pegs
a single CPU for 5 minutes with no parallelism opportunities, so this
turns down the test to still exercise it somewhat at least.
Unify all uses of 'gcx and 'tcx.
This is made possible by @Zoxc landing #57214 (see https://github.com/rust-lang/rust/pull/57214#issuecomment-465036053 for the decision).
A bit of context for the approach: just like #61722, this is *not* how I originally intended to go about this, but @Zoxc and my own experimentation independently resulted in the same conclusion:
The interim alias `type TyCx<'tcx> = TyCtxt<'tcx, 'tcx>;` attempt required more work (adding `use`s), even only for handling the `TyCtxt<'tcx, 'tcx>` case and not the general `TyCtxt<'gcx, 'tcx>` one.
What this PR is based on is the realization that `'gcx` is a special-enough name that it can be replaced, without caring for context, with `'tcx`, and then repetitions of the name `'tcx` be compacted away.
After that, only a small number of error categories remained, each category easily dealt with with either more mass replacements (e.g. `TyCtxt<'tcx, '_>` -> `TyCtxt<'tcx>`) or by hand.
For the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise, like in #61735 and #61722, and like the latter, there was also a weird bug to work around.
It should be reviewed separately, and dropped if unwanted (in this PR it's pretty significant).
cc @rust-lang/compiler r? @nikomatsakis
in which we decline to suggest the anonymous lifetime in declarations
The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of the "anywhere else", and yet meriting different rules as far as the lint was concerned, so it seemed expedient to introduce a new enum member. We yank out `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields—one would have hoped to think of something more elegant than this, but it definitely beats changing the signature of `lower_ty` to take a `ParamMode`!
Resolves#61124.
cc @memoryruins
r? @oli-obk
The elided-lifetimes-in-path lint (part of our suite of Rust 2018
idiom lints which we are hoping to promote to Warn status) was firing
with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code
was already deciding whether to act on the basis of a `ParamMode`
enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of
the "anywhere else", and yet meriting different rules as far as the
lint was concerned, so it seemed expedient to introduce a new enum
member. We yank out a `TyKind::Path` arm into its own method so that
we can call it with our new `ParamMode` specifically when lowering
struct fields. (The alternative strategy of changing the signature of
`lower_ty` to take a `ParamMode` would be inelegant given that most of
the `TyKind` match arm bodies therein don't concern themselves with
`ParamMode`.)
Resolves#61124.
This commit extends the work in #61698 to get the `DefId` of const
parameters from block that resolve to a const parameter (as well as
const parameters directly, as it was previously).
