Commit Graph

654 Commits

Author SHA1 Message Date
bors
e5f83d24ae Auto merge of #84797 - richkadel:cover-unreachable-statements, r=tmandry
Report coverage `0` of dead blocks

Fixes: #84018

With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.

If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.

Check out the resulting changes in the test coverage reports in this PR (in [commit 1](0b0d293c7c)).

r? `@tmandry`
cc: `@wesleywiser`
2021-05-07 10:06:40 +00:00
Rich Kadel
cb70221857 Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884

This solution might be considered a compromise, but I think it is the
better choice.

The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.

One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.

Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.

The callsite is most likely to be the preferred site for coverage.

I applied this fix to all `MacroKinds`, not just `Bang`.

I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.

I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.
2021-05-06 11:15:39 -07:00
Andy Wang
5417b45c26
Use local and remapped paths where appropriate 2021-05-05 15:31:28 +01:00
Rich Kadel
0b0d293c7c Report coverage 0 of dead blocks
Fixes: #84018

With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.

If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.

Check out the resulting changes in the test coverage reports in this PR.
2021-05-01 15:04:48 -07:00
bors
1c2c6b6700 Auto merge of #84582 - richkadel:issue-84561, r=tmandry
Vastly improves coverage spans for macros

Fixes: #84561

This resolves problems where macros like `trace!(...)` would show zero coverage if tracing was disabled, and `assert_eq!(...)` would show zero coverage if the assertion did not fail, because only one coverage span was generated, for the branch.

This PR started with an idea that I could just drop branching blocks with same span as expanded macro. (See the fixed issue for more details.)

That did help, but it didn't resolve everything.

I also needed to add a span specifically for the macro name (plus `!`) to ensure the macro gets coverage even if it's internal expansion adds conditional branching blocks that are retained, and would otherwise drop the outer span. Now that outer span is _only_ the `(argument, list)`, which can safely be dropped now), because the macro name has its own span.

While testing, I also noticed the spanview debug output can cause an ICE on a function with no body. The
workaround for this is included in this PR (separate commit).

r? `@tmandry`
cc? `@wesleywiser`
2021-05-01 07:48:24 +00:00
Rich Kadel
0312bf5fb9 Rebuilt out of date tests and fixed an old bug now exposed 2021-04-30 01:10:48 -07:00
Ralf Jung
9a852776f4 don't let const_fn feature flag affect impl-block-level trait bounds 2021-04-29 09:27:45 +02:00
Rich Kadel
eef546abb6 addressed review feedback 2021-04-28 20:27:27 -07:00
Rich Kadel
f12795f8a0 More improvements to macro coverage 2021-04-28 20:27:27 -07:00
Rich Kadel
c26afb765c Drop branching blocks with same span as expanded macro
Fixes: #84561
2021-04-28 20:27:27 -07:00
bors
20040fa332 Auto merge of #84562 - richkadel:issue-83601, r=tmandry
Adds feature-gated `#[no_coverage]` function attribute, to fix derived Eq `0` coverage issue #83601

Derived Eq no longer shows uncovered

The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.

Fixes: #83601

The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).

Adding a `no_coverage` feature gate with tracking issue #84605.

r? `@tmandry`
cc: `@wesleywiser`
2021-04-28 13:05:16 +00:00
Yuki Okushi
3f89ca1a32
Rollup merge of #84529 - richkadel:issue-84180, r=tmandry
Improve coverage spans for chained function calls

Fixes: #84180

For chained function calls separated by the `?` try operator, the
function call following the try operator produced a MIR `Call` span that
matched the span of the first call. The `?` try operator started a new
span, so the second call got no span.

It turns out the MIR `Call` terminator has a `func` `Operand`
for the `Constant` representing the function name, and the function
name's Span can be used to reset the starting position of the span.

r? `@tmandry`
cc: `@wesleywiser`
2021-04-28 16:59:06 +09:00
Rich Kadel
888d0b4c96 Derived Eq no longer shows uncovered
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.

Fixes: #83601

The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).

While testing, I also noticed two other issues:

* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
2021-04-27 11:11:56 -07:00
bors
e1886935b7 Auto merge of #84532 - richkadel:issue-83792, r=tmandry
Fix coverage ICE because fn_sig can have a span that crosses file bou…

Fixes: #83792

MIR `InstrumentCoverage` assumed the `FnSig` span was contained within a
single file, but this is not always the case. Some macro constructions
can result in a span that starts in one `SourceFile` and ends in a
different one.

The `FnSig` span is included in coverage results as long as that span is
in the same `SourceFile` and the same macro context, but by assuming the
`FnSig` span's `hi()` and `lo()` were in the same file, I took this for
granted, and checked only that the `FnSig` `hi()` was in the same
`SourceFile` as the `body_span`.

I actually drop the `hi()` though, and extend the `FnSig` span to the
`body_span.lo()`, so I really should have simply checked that the
`FnSig` span's `lo()` was in the `SourceFile` of the `body_span`.

r? `@tmandry`
cc: `@wesleywiser`
2021-04-27 07:29:26 +00:00
Ralf Jung
9082078a26 unsafety checking: no longer care about is_min_const_fn
Rejecting the forbidden unsafe ops is done by const checking, not by unsafety checking
2021-04-25 12:53:05 +02:00
Rich Kadel
41667e8534 Improve spans for chained function calls
Fixes: #84180

For chained function calls separated by the `?` try operator, the
function call following the try operator produced a MIR `Call` span that
matched the span of the first call. The `?` try operator started a new
span, so the second call got no span.

It turns out the MIR `Call` terminator has a `func` `Operand`
for the `Constant` representing the function name, and the function
name's Span can be used to reset the starting position of the span.
2021-04-24 17:27:24 -07:00
bors
b56b175c6c Auto merge of #84310 - RalfJung:const-fn-feature-flags, r=oli-obk
further split up const_fn feature flag

This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)

I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.

`@oli-obk` are you currently able to do reviews?
2021-04-24 23:16:03 +00:00
Rich Kadel
31cba57ea5 Fix coverage ICE because fn_sig can have a span that crosses file boundaries
Fixes: #83792

MIR `InstrumentCoverage` assumed the `FnSig` span was contained within a
single file, but this is not always the case. Some macro constructions
can result in a span that starts in one `SourceFile` and ends in a
different one.

The `FnSig` span is included in coverage results as long as that span is
in the same `SourceFile` and the same macro context, but by assuming the
`FnSig` span's `hi()` and `lo()` were in the same file, I took this for
granted, and checked only that the `FnSig` `hi()` was in the same
`SourceFile` as the `body_span`.

I actually drop the `hi()` though, and extend the `FnSig` span to the
`body_span.lo()`, so I really should have simply checked that the
`FnSig` span's `lo()` was in the `SourceFile` of the `body_span`.
2021-04-24 15:41:56 -07:00
Yuki Okushi
e109aa3613
Rollup merge of #83519 - oli-obk:assign_shrink_your_normal_code, r=pnkfelix
Implement a lint that highlights all moves larger than a configured limit

Tracking issue: #83518
[MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress

r? ```@pnkfelix```

The main open issue I see with this minimal impl of the feature is that the lint is immediately "stable" (so it can be named on stable), even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate, so that would be a bigger change.
2021-04-25 01:53:09 +09:00
Rich Kadel
a07bf2e174 Fix ICE if original_span(fn_sig) returns a span not in body sourcefile
Fixes: #84421
2021-04-22 15:49:13 -07:00
Oli Scherer
a46bc5664a Tidy 2021-04-20 09:30:28 -04:00
Oli Scherer
e9696c8b62 Implement a lint that highlights all moves larger than 1000 bytes 2021-04-20 09:30:21 -04:00
bors
6af1e632a9 Auto merge of #84323 - richkadel:uncovered-functions, r=tmandry
coverage of async function bodies should match non-async

This fixes some missing coverage within async function bodies.

Commit 1 demonstrates the problem in the fixed issue, and commit 2 corrects it.

Fixes: #83985
2021-04-20 08:33:51 +00:00
Rich Kadel
5d8d67f746 compute fn_sig span from body call_site, and use body ctxt, not root 2021-04-19 12:30:55 -07:00
Ralf Jung
46d09f7a4b remove E0723 error code 2021-04-19 14:58:11 +02:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
Ralf Jung
04db4abbfc add gate tests and pacify tidy 2021-04-19 10:25:31 +02:00
Rich Kadel
1893721ec4 Fixes the issue with uncovered source in async function bodies
The body_span was assumed to be in the Span root context, but this was
not the case for async function bodies.
2021-04-18 16:26:18 -07:00
Ralf Jung
fbfaab2cb7 separate feature flag for unsizing casts in const fn 2021-04-18 19:11:29 +02:00
Ralf Jung
fdad6ab3a3 move 'trait bounds on const fn' to separate feature gate 2021-04-18 18:36:41 +02:00
bors
cd56e255c4 Auto merge of #83870 - jackh726:binder-refactor-fix, r=nikomatsakis
Don't concatenate binders across types

Partially addresses #83737

There's actually two issues that I uncovered in #83737. The first is that we are concatenating bound vars across types, i.e. in
```
F: Fn(&()) -> &mut (dyn Future<Output = ()> + Unpin)
```
the bound vars on `Future` get set as `for<anon>` since those are the binders on `Fn(&()`. This is obviously wrong, since we should only concatenate directly nested trait refs. This is solved here by introducing a new `TraitRefBoundary` scope, that we put around the "syntactical" trait refs and basically don't allow concatenation across.

Now, this alone *shouldn't* be a super terrible problem. At least not until you consider the other issue, which is a much more elusive and harder to design a "perfect" fix. A repro can be seen in:
```
use core::future::Future;

async fn handle<F>(slf: &F)
where
    F: Fn(&()) -> &mut (dyn for<'a> Future<Output = ()> + Unpin),
{
    (slf)(&()).await;
}
```
Notice the `for<'a>` around `Future`. Here, `'a` is unused, so the `for<'a>` Binder gets changed to a `for<>` Binder in the generator witness, but the "local decl" still has it. This has heavy intersections with region anonymization and erasing. Luckily, it's not *super* common to find this unique set of circumstances. It only became apparently because of the first issue mentioned here. However, this *is* still a problem, so I'm leaving #83737 open.

r? `@nikomatsakis`
2021-04-09 01:50:01 +00:00
Dylan DPC
b81c6cdb57
Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov
Use AnonConst for asm! constants

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for `const` operands is still the same as before: `const <expr>`.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
2021-04-07 13:07:14 +02:00
Amanieu d'Antras
32be124e30 Use AnonConst for asm! constants 2021-04-06 12:35:41 +01:00
Jack Huey
1a14315975 Don't concatenate binders across types 2021-04-05 00:41:08 -04:00
Roxane
0a97eee8df Reduce size of statements 2021-04-02 19:11:50 -04:00
Jack Huey
30187c81f6 Track bound vars 2021-03-31 10:15:27 -04:00
Dylan DPC
b2e254318d
Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se
Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
2021-03-27 20:37:07 +01:00
Ralf Jung
fb4f48e032 make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces 2021-03-27 16:59:37 +01:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
bors
372afcf93b Auto merge of #83445 - erikdesjardins:rmunion, r=RalfJung
RemoveZsts: don't touch unions

This should fix a Miri ICE

r? `@RalfJung`
2021-03-25 07:48:52 +00:00
bors
dbc37a97dc Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandry
coverage bug fixes and optimization support

Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144

Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651

Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875

Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.

FYI: `@wesleywiser`

r? `@tmandry`
2021-03-25 05:07:34 +00:00
Erik Desjardins
d5c1ad5ca1 RemoveZsts: don't touch unions 2021-03-24 13:00:36 -04:00
bors
79e5814f45 Auto merge of #83177 - erikdesjardins:zstassign, r=oli-obk
Remove assignments to ZST places instead of marking ZST return place as unused

partially reverts #83118

requested by `@tmiasko` in https://github.com/rust-lang/rust/pull/83118#issuecomment-799692574

r? `@oli-obk`
2021-03-23 12:23:27 +00:00
Erik Desjardins
6960bc9696 only run RemoveZsts at mir-opt-level 3 and above 2021-03-22 18:30:56 -04:00
Dylan DPC
1fdf7d18ad
Rollup merge of #83351 - RalfJung:precise-const-drop, r=oli-obk
post-drop-elab check-const: explain why we still check qualifs

r? `@oli-obk`
2021-03-22 15:21:29 +01:00
Ralf Jung
4e7f1fa14f post-drop-elab check-const: explain why we still check qualifs 2021-03-21 21:20:59 +01:00
Dylan DPC
69f6a195da
Rollup merge of #83327 - tmiasko:visit-lhs, r=davidtwco
Extend comment in `UsedLocals::visit_lhs`
2021-03-21 02:01:40 +01:00
lcnr
43ebac119b extract ConstKind::Unevaluated into a struct 2021-03-20 17:21:44 +01:00
Erik Desjardins
46fd49cdc3 avoid calling for types which can't be ZSTs 2021-03-19 22:25:56 -04:00
Rich Kadel
bcf755562a coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144

Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651

Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875

Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-19 17:11:50 -07:00
Tomasz Miąsko
43cadc99b7 Extend comment in UsedLocals::visit_lhs 2021-03-20 00:00:00 +00:00
Dylan DPC
90e52a1ad2
Rollup merge of #83277 - spastorino:early_otherwise-opt-unsound, r=oli-obk
Mark early otherwise optimization unsound

r? `@oli-obk`
cc `@tmiasko`

Related to #78496 and #82905

Should I also bump this one to level 3 or 4 or given that is unsound it doesn't matter?.
Probably need to adjust some tests.
2021-03-19 23:01:40 +01:00
Santiago Pastorino
778e1978d5
Mark early otherwise optimization unsound 2021-03-18 20:57:44 -03:00
Mara Bos
cfb4ad4f2a Remove unwrap_none/expect_none from compiler/. 2021-03-18 14:25:54 +01:00
Erik Desjardins
93c1380e0b remove inhabitedness check 2021-03-17 20:56:38 -04:00
Erik Desjardins
1205e82578 remove unnecessary and ineffective caching 2021-03-17 20:24:29 -04:00
Dylan DPC
b688b694d0
Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiser
Make source-based code coverage compatible with MIR inlining

When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.

Fixes #83061
2021-03-18 00:28:09 +01:00
Erik Desjardins
bca761dc5d move to separate pass, cache layouts 2021-03-16 21:34:31 -04:00
bors
e655fb6221 Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasper
Implement (but don't use) valtree and refactor in preparation of use

This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.

cc `@rust-lang/wg-const-eval` on the following commits:

* 2027184 implement valtree
* eeecea9 fallible Scalar -> ScalarInt
* 042f663 ScalarInt convenience methods

cc `@eddyb` on ef04a6d

cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2021-03-16 22:42:56 +00:00
Erik Desjardins
899836306f remove assignments to ZST places 2021-03-15 21:57:52 -04:00
Erik Desjardins
affb081fa0 revert changes from #83118 to mark zst return place as unused 2021-03-15 20:18:03 -04:00
Tomasz Miąsko
1796cc0e6c Make source-based code coverage compatible with MIR inlining
When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.
2021-03-15 23:26:03 +01:00
Oli Scherer
c30c1be1e6 s/ConstantSource/ConstantKind/ 2021-03-15 12:06:52 +00:00
Erik Desjardins
47f8bacc46 remove unnecessary condition
`_local` isn't visited in `_local = <rhs>` statements in the situation
we care about
2021-03-14 20:21:20 -04:00
Simon Vandel Sillesen
bb36e3c7e7 Move ZST check inside UsedLocals 2021-03-13 18:00:28 -05:00
Simon Vandel Sillesen
4e901be57d Extend SimplifyLocals to remove ZST writes 2021-03-13 17:58:11 -05:00
Oli Scherer
3127a9c60f Prepare mir::Constant for ty::Const only supporting valtrees 2021-03-12 12:43:54 +00:00
Cameron Steffen
b0514a6a0a Rename Option::get_or_insert_default 2021-03-10 09:07:16 -06:00
Yuki Okushi
1c3fea2f8c
Rollup merge of #82849 - camsteffen:option-get-or-default, r=joshtriplett
Add Option::get_or_default

Tracking issue: #82901

The original issue is #55042, which was closed, but for an invalid reason (see discussion there). Opening this to reconsider (I hope that's okay). It seems like the only gap for `Option` being "entry-like".

I ran into a need for this method where I had a `Vec<Option<MyData>>` and wanted to do `vec[n].get_or_default().my_data_method()`. Using an `Option` as an inner component of a data structure is probably where the need for this will normally arise.
2021-03-10 08:01:32 +09:00
Yuki Okushi
c46f948a80
Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn, r=nikomatsakis
Stabilize `unsafe_op_in_unsafe_fn` lint

This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896.

Tracking issue: #71668
r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung```

# Stabilization report

This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`.

## Summary

Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.

The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.

For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.

For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md)

### Example

```rust
// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}

// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
    // Here, no `unsafe` block is needed to
    // perform unsafe operations...
    unsf();

    // ...and any `unsafe` block is considered
    // unused and is warned on by the compiler.
    unsafe {
        unsf();
    }
}

#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
    // Removing this `unsafe` block will
    // cause the compiler to emit a warning.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}

#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
    // Removing this `unsafe` block will
    // cause a compilation error.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}
```
2021-03-10 08:01:25 +09:00
kadmin
4bceb294f4 Clean up todos
Also add some span_bugs where it is unreachable
2021-03-09 19:31:31 +00:00
kadmin
217ff6b7ea Switch to changing cp_non_overlap in tform
It was suggested to lower this in MIR instead of ssa, so do that instead.
2021-03-09 16:54:14 +00:00
kadmin
982382dc03 Update cranelift 2021-03-09 16:54:14 +00:00
kadmin
37a6c04718 Update interpret step 2021-03-09 16:54:13 +00:00
kadmin
89f45ed9f3 Update match branches
This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.
2021-03-09 16:54:13 +00:00
Cameron Steffen
1cc8c4de6a Use Option::get_or_default 2021-03-08 09:24:11 -06:00
Dylan DPC
dd7a606804
Rollup merge of #82684 - tmiasko:dest-prop, r=jonas-schievink
Disable destination propagation on all mir-opt-levels

The new `// compile-flags: -Zunsound-mir-opts` are inserted without an extra newline to avoid introducing a large mir-opt diff.
2021-03-08 13:13:24 +01:00
bors
27885a94c6 Auto merge of #82727 - oli-obk:shrinkmem, r=pnkfelix
Test the effect of shrinking the size of Rvalue by 16 bytes

r? `@ghost`
2021-03-08 08:39:24 +00:00
Tomasz Miąsko
6f49aadabb Disable destination propagation on all mir-opt-levels 2021-03-06 00:00:00 +00:00
Santiago Pastorino
004465c620
Bump one missing mir_opt_level 2021-03-05 17:13:58 -03:00
Santiago Pastorino
782c7b04cf
Bump all mir_opt_level 2 to 3 2021-03-05 17:13:57 -03:00
Santiago Pastorino
f3b8920d4b
Bump all mir_opt_level 3 to 4 2021-03-05 17:13:56 -03:00
Santiago Pastorino
fde8d6ee81
For better consistency change mir_opt_level <= 1 to < 2 2021-03-05 17:13:56 -03:00
Santiago Pastorino
8152da22a1
Extract mir_opt_level to a method and use Option to be able to know if the value is provided or not 2021-03-05 17:13:56 -03:00
Oli Scherer
9a2362e5a9 Shrink the size of Rvalue by 16 bytes 2021-03-05 09:33:01 +00:00
bors
6f7673d077 Auto merge of #81114 - bugadani:generator, r=estebank
Box generator-related Body fields

Might save some memory on functions that aren't generators.
2021-03-04 00:23:42 +00:00
Yuki Okushi
ae5e024194
Rollup merge of #82376 - tmiasko:inline-options, r=oli-obk
Add option to enable MIR inlining independently of mir-opt-level

Add `-Zinline-mir` option that enables MIR inlining independently of the
current MIR opt level. The primary use-case is enabling MIR inlining on the
default MIR opt level.

Turn inlining thresholds into optional values to make it possible to configure
different defaults depending on the current mir-opt-level (although thresholds
are yet to be used in such a manner).
2021-03-02 21:23:14 +09:00
Guillaume Gomez
865cf0c3b6
Rollup merge of #80734 - abonander:ab/issue-66693, r=oli-obk
check that first arg to `panic!()` in const is `&str`

closes #66693

~~TODO: regression test~~

cc `@RalfJung` for error message wording
2021-03-02 00:50:04 +01:00
Austin Bonander
5a33f531cd check that first arg to panic!() in const is &str 2021-03-01 08:32:15 -08:00
Dániel Buga
b97eb23cd0 Box generator-related Body fields 2021-03-01 08:32:49 +01:00
Tomasz Miąsko
8b184ff1b8 Remove storage markers if they won't be used during code generation
The storage markers constitute a substantial portion of all MIR
statements. At the same time, for builds without any optimizations,
the storage markers have no further use during and after MIR
optimization phase.

If storage markers are not necessary for code generation, remove them.
2021-02-28 20:10:44 +01:00
Tomasz Miąsko
500aeccc5b Use optional values for inlining thresholds
Turn inlining threshold into optional values to make it possible to
configure different defaults depending on the current mir-opt-level.
2021-02-27 10:19:19 +01:00
Tomasz Miąsko
f895f1c35a Add option enabling MIR inlining independently of mir-opt-level 2021-02-27 10:18:06 +01:00
Dylan DPC
2942cf5a1f
Rollup merge of #82482 - tmiasko:small-cycles, r=varkor
Use small hash set in `mir_inliner_callees`

Use small hash set in `mir_inliner_callees` to avoid temporary
allocation when possible and quadratic behaviour for large number of
callees.
2021-02-27 02:34:32 +01:00
Guillaume Gomez
ee4129f70c
Rollup merge of #82491 - tmiasko:i, r=lcnr
Consider inexpensive inlining criteria first

Refactor inlining decisions so that inexpensive criteria are considered first:

1. Based on code generation attributes.
2. Based on MIR availability (examines call graph).
3. Based on MIR body.
2021-02-26 15:52:32 +01:00
bors
89d32eb1ea Auto merge of #82338 - RalfJung:interp-error-allocs, r=oli-obk
all InterpError allocate now, so adjust alloc-error-check

Cc https://github.com/rust-lang/rust/pull/82116#discussion_r578310770
r? `@oli-obk`
2021-02-25 08:27:09 +00:00
bors
1fdadbf13a Auto merge of #82159 - BoxyUwU:uwu, r=varkor
Use correct param_env in conservative_is_privately_uninhabited

cc `@lcnr`
r? `@varkor` since this is your FIXME that was removed ^^
2021-02-24 21:54:52 +00:00
bors
6b56603e35 Auto merge of #80475 - simonvandel:fix-77355, r=oli-obk
New mir-opt pass to simplify gotos with const values (reopening #77486)

Reopening PR #77486

Fixes #77355

This pass optimizes the following sequence
```rust
bb2: {
    _2 = const true;
    goto -> bb3;
}

bb3: {
    switchInt(_2) -> [false: bb4, otherwise: bb5];
}
```
into
```rust
bb2: {
    _2 = const true;
    goto -> bb5;
}
```
2021-02-24 07:23:54 +00:00
Tomasz Miąsko
ef731b31db Use small hash set in mir_inliner_callees
Use small hash set in `mir_inliner_callees` to avoid temporary
allocation when possible and quadratic behaviour for large number of
callees.
2021-02-24 00:00:00 +00:00
Tomasz Miąsko
6d5c0c1bcb Consider inexpensive inlining criteria first
Refactor inlining decisions so that inexpensive criteria are considered first:

1. Based on code generation attributes.
2. Based on MIR availability (examines call graph).
3. Based on MIR body.
2021-02-24 00:00:00 +00:00