This removes the `usize` argument to `inc_step_counter`. Now, the step
counter increments by exactly one for every terminator evaluated. After
`STEPS_UNTIL_DETECTOR_ENABLED` steps elapse, the detector is run every
`DETECTOR_SNAPSHOT_PERIOD` steps. The step counter is only kept modulo
this period.
This test relies on the fact that restrictions on expressions in `const
fn` do not apply when computing array lengths. It is more difficult to
statically analyze than the simple `loop{}` mentioned in #50637.
This test should be updated to ignore the warning after #49980 is resolved.
The detector runs every `DETECTOR_SNAPSHOT_PERIOD` steps. Since the
number of steps can increase by more than 1 (I'd like to remove this),
the detector may fail if the step counter is incremented past the
scheduled detection point during the loop.
This reverts commit 59d21c526c036d7097d05edd6dffdad9c5b1cb62, and uses
tuple to store the mutable parts of an EvalContext (which now includes
`Machine`). This requires that `Machine` be `Clone`.
Use the approach suggested by @oli-obk, a table holding `EvalState`
hashes and a table holding full `EvalState` objects. When a hash
collision is observed, the state is cloned and put into the full
table. If the collision was not spurious, it will be detected during the
next iteration of the infinite loop.
I use a pattern binding in each custom impl, so that adding fields to
`Memory` or `Frame` will cause a compiler error instead of causing e.g.
`PartialEq` to become invalid. This may be too cute.
This adds several requirements to `Machine::MemoryData`. These can be
removed if we don't want this associated type to be part of the equality
of `Memory`.
Reuse the `DefsUsesVisitor` in `simulate_block()`.
This avoids a bunch of allocations for the bitsets within it,
speeding up a number of NLL benchmarks, the best by 1%.
r? @nikomatsakis
Unpin references
I also considered adding an impl for raw pointers as well, but that makes it easy to accidentally have unsound owning-collections that might otherwise be able to project pinned-ness (e.g. `Box`).
cc @RalfJung
r? @withoutboats
Move self trait predicate to items
This is a "reimagination" of @tmandry's PR #50183. The main effect is described in this comment from one of the commits:
---
Before we had the following results for `predicates_of`:
```rust
trait Foo { // predicates_of: Self: Foo
fn bar(); // predicates_of: Self: Foo (inherited from trait)
}
```
Now we have removed the `Self: Foo` from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
`<T as Foo>::bar()`, they still need to prove that `T: Foo`, and
having it in the `predicates_of` seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):
```rust
trait Foo { // predicates_of: []
fn bar(); // predicates_of: Self: Foo
}
```
However, we sometimes want to get the list of *just* the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define `predicates_defined_on`,
which does not contain the `Self: Foo` predicate yet, and we plumb
that through metadata and so forth.
---
I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)
r? @eddyb
cc @scalexm @tmandry @leodasvacas
[NLL] Use better span for initializing a variable twice
Closes#51217
When assigning to a (projection from a) local immutable local which starts initialised (everything except `let PATTERN;`):
* Point to the declaration of that local
* Make the error message refer to the local, rather than the projection.
r? @nikomatsakis
introduce dirty list to dataflow
@nikomatsakis my naive implementation never worked, So, I decided to implement using `work_queue` data structure. This PR also includes your commits from `nll-liveness-dirty-list` branch. Those commits should not visible once your branch is merged.
r? @nikomatsakis
Rollup of 13 pull requests
Successful merges:
- #51548 (Initialize LLVM's AMDGPU target machine, if available.)
- #51809 (Add read_exact_at and write_all_at methods to FileExt on unix)
- #51914 (add outlives annotations to `BTreeMap`)
- #51958 (Show known meta items in unknown meta items error)
- #51973 (Make Stdio handle UnwindSafe)
- #51977 (bootstrap: tests should use rustc from config.toml)
- #51978 (Do not suggest changes to str literal if it isn't one)
- #51979 (Get rid of `TyImplTraitExistential`)
- #51980 (Emit column info in debuginfo for non msvc like targets)
- #51982 (incr.comp.: Take names of children into account when computing the ICH of a module's HIR.)
- #51997 (add entry for cargo-metadata feature to RELEASES)
- #52004 (toolstate: Fixed detection of changed submodule, and other fixes.)
- #52006 ( Change --keep-stage to apply more often)
Failed merges:
r? @ghost
Change --keep-stage to apply more often
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
r? @alexcrichton
cc @nikomatsakis - I believe you wanted this functionality
toolstate: Fixed detection of changed submodule, and other fixes.
1. Make sure that if a submodule is updated but failed to test-pass, we'll block the merge.
2. Make sure failure on external docs (nomicon/RBE/etc) are properly checked.
3. If the commit message starts with "Update RLS" (or clippy etc), automatically run the "tools" job on the PR, so that we could know if the update failed before merging.
incr.comp.: Take names of children into account when computing the ICH of a module's HIR.
Fixes#40876. Red-green tracking does not make this a problem anymore. We should verify this via a perf-run though.
r? @nikomatsakis
bootstrap: tests should use rustc from config.toml
Tests should always use "rustc" and "cargo" from config.toml instead of assuming that stage0 binaries was downloaded to build directory.
Without this change `./x.py test src/bootstrap` will always try to use `build/ARCH/stage0/bin/rustc` file as compiler, but when we use local compiler to bootstrap this file does not exist.
Show known meta items in unknown meta items error
This PR adds a label to E0541. It also factors built-in attribute parsing into a submodule of `attr` for ease of future refactoring.
Fixes#51469.
Add read_exact_at and write_all_at methods to FileExt on unix
This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop.
I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently.
I asked in Discord and was told that as this change is small it does not require an RFC.
Initialize LLVM's AMDGPU target machine, if available.
Note this isn't useful, yet. More changes will be necessary to be able to
actually codegen for this machine. As such, it is not enabled by default.
This patch is on its own for the benefit of the reviewers.
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms
This reverts commit 837d6c7023 "Remove TryFrom impls that might become conditionally-infallible with a portability lint".
This fixes#49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
Make custom trait object for `Future` generic
- `TaskObj` -> `FutureObj<'static, ()>`
- The `impl From<...> for FutureObj<'a, T>` impls are impossible because of the type parameter `T`. The impl has to live in libstd, but `FutureObj<'a, T>` is from libcore. Therefore `Into<FutureObj<'a, T>>` was implemented instead. Edit: This didn‘t compile without warnings. I am now using non-generic Form impls.
See https://github.com/rust-lang-nursery/futures-rs/issues/1058
r? @cramertj
Edit: Added lifetime
introduce dirty list to liveness, eliminate `ins` vector
At least in my measurements, this seems to knock much of the liveness computation off the profile.
r? @Zoxc
cc @nnethercote
