avoid duplicate issues for Miri build failures
Currently, when Miri regressed from test-pass to test-fail, we pen an issue -- and then when it regresses further from test-fail to build-fail, we open a *second* issue.
This changes the logic to avoid the redundant second issue for Miri.
r? @pietroalbini @kennytm
improve Vec example soundness in mem::transmute docs
The previous version of the `Vec` example had a case of questionable soundness, because at one point `v_orig` was aliased.
r? @RalfJung
Shrink `SubregionOrigin`.
It's currently 120 bytes on x86-64, due to one oversized variant
(`Subtype`). This commit boxes `Subtype`'s contents, reducing the size
of `SubregionOrigin` to 32 bytes.
The change speeds things up by avoiding lots of `memcpy` calls, mostly
relating to `RegionConstraintData::constraints`, which is a `BTreeMap`
with `SubregionOrigin` values.
adjust desugaring for async fn to correct drop order
Old desugaring, given a user function body `{ $stmts; $expr }`
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
$stmts;
$expr
}
```
New desugaring:
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
drop-temps {
$stmts;
$expr
}
}
```
The drop-temps is an internal bit of HIR that drops temporaries from the resulting expression, but it should be equivalent to `return { $stmts; $expr }`.
Fixes#64512Fixes#64391
azure: Disable more LLVM/debug assertions in
This commit disables LLVM/debug assertions in our 5 slowest builders:
* i686-gnu
* i686-gnu-nopt
* i686-msvc-1
* i686-msvc-2
* x86_64-msvc-cargo
This is reducing the amount of test coverage for LLVM/debug assertions,
but we're just unfortunately running out of time on CI too many times.
Some test builds have shown that i686-gnu drops nearly an hour of CI
time by disabling these two assertions. Perhaps when we eventually get
4-core machines we can reenable these, but for now turn them off and
hook them up to the tracking issue at #59637 which will ideally be
repurposes to tracking all of these.
Various refactorings to clean up nll diagnostics
- Create ErrorReportingCtx and ErrorConstraintInfo, vasting reducing the
number of arguments passed around everywhere in the error reporting code
- Create RegionErrorNamingCtx, making a given lifetime have consistent
numbering thoughout all error messages for that MIR def.
- Make the error reporting code return the DiagnosticBuilder rather than
directly buffer the Diagnostic. This makes it easier to modify the
diagnostic later, e.g. to add suggestions.
r? @estebank
Split out from https://github.com/rust-lang/rust/pull/58281
Rollup of 4 pull requests
Successful merges:
- #64357 (`AdtDef` is an algebraic data type, not abstract data type)
- #64485 (update Miri)
- #64509 (Make some adjustments to the documentation for `std::convert::identity`)
- #64518 (Use while let slice_pattern instead of carrying an index around)
Failed merges:
r? @ghost
update Miri
Fixes https://github.com/rust-lang/rust/issues/64363
r? @alexcrichton for the Cargo.toml changes: with byteorder 1.3, the `i128` feature is a NOP, so we can remove it everywhere and then get rid of this crate in the workspace-hack.
Old desugaring, given a user function body { $stmts; $expr }
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
$stmts;
$expr
}
```
New desugaring:
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
drop-temps {
$stmts;
$expr
}
}
```
The drop-temps is an internal bit of HIR that drops temporaries from
the resulting expression, but it should be equivalent to `return {
$stmts; $expr }`.
This commit disables LLVM/debug assertions in our 5 slowest builders:
* i686-gnu
* i686-gnu-nopt
* i686-msvc-1
* i686-msvc-2
* x86_64-msvc-cargo
This is reducing the amount of test coverage for LLVM/debug assertions,
but we're just unfortunately running out of time on CI too many times.
Some test builds have shown that i686-gnu drops nearly an hour of CI
time by disabling these two assertions. Perhaps when we eventually get
4-core machines we can reenable these, but for now turn them off and
hook them up to the tracking issue at #59637 which will ideally be
repurposes to tracking all of these.
