Move binder for dyn to each list item
This essentially changes `ty::Binder<&'tcx List<ExistentialTraitRef>>` to `&'tcx List<ty::Binder<ExistentialTraitRef>>`.
This is a first step in moving the `dyn Trait` representation closer to Chalk, which we've talked about in `@rust-lang/wg-traits.`
r? `@nikomatsakis`
Move binder for dyn to each list item
This essentially changes `ty::Binder<&'tcx List<ExistentialTraitRef>>` to `&'tcx List<ty::Binder<ExistentialTraitRef>>`.
This is a first step in moving the `dyn Trait` representation closer to Chalk, which we've talked about in `@rust-lang/wg-traits.`
r? `@nikomatsakis`
bootstrap: update ci-llvm stamp after #80087Fixes#80086.
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This PR updates the ci-llvm stamp to resolve that problem.
r? `@Mark-Simulacrum`
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
r? `@ghost`
Always run intrinsics lowering pass
Move intrinsics lowering pass from the optimization phase (where it
would not run if -Zmir-opt-level=0), to the drop lowering phase where it
runs unconditionally.
The implementation of those intrinsics in code generation and
interpreter is unnecessary. Remove it.
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated
ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This commit
updates the ci-llvm stamp to resolve that problem.
Signed-off-by: David Wood <david@davidtw.co>
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.
Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures, that intrinsic is translated as a corresponding CPU instruction know as "popcount" or "popcnt".
This PR makes it so that searching for those names in rustdoc shows those methods.
CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases
Fixed conflict with drop elaboration and coverage
See
https://github.com/rust-lang/rust/issues/80045#issuecomment-745733339
Coverage statements are moved to the beginning of the BCB. This does
also affect what's counted before a panic, changing some results, but I
think these results may even be preferred? In any case, there are no
guarantees about what's counted when a panic occurs (by design).
r? `@tmandry`
FYI `@wesleywiser` `@ecstatic-morse`
Fix issue #78496
EarlyOtherwiseBranch finds MIR structures like:
```
bb0: {
...
_2 = discriminant(X)
...
switchInt(_2) -> [1_isize: bb1, otherwise: bb3]
}
bb1: {
...
_3 = discriminant(Y)
...
switchInt(_3) -> [1_isize: bb2, otherwise: bb3]
}
bb2: {...}
bb3: {...}
```
And transforms them into something like:
```
bb0: {
...
_2 = discriminant(X)
_3 = discriminant(Y)
_4 = Eq(_2, _3)
switchInt(_4) -> [true: bb4, otherwise: bb3]
}
bb2: {...} // unchanged
bb3: {...} // unchanged
bb4: {
switchInt(_2) -> [1_isize: bb2, otherwise: bb3]
}
```
But that is not always a safe thing to do -- sometimes the early `otherwise` branch is necessary so the later block could assume the value of `discriminant(X)`.
I am not totally sure what's the best way to detect that, but fixing #78496 should be easy -- we just check if `X` is a sub-expression of `Y`. A more precise test might be to check if `Y` contains a `Downcast(1)` of `X`, but I think this might be good enough.
Fix#78496
Allow `since="TBD"` for rustc_deprecated
Closes#78381.
This PR only affects `#[rustc_deprecated]`, not `#[deprecated]`, so there is no effect on any stable language feature.
Likewise this PR only implements `since="TBD"`, it does not actually tag any library functions with it, so there is no effect on any stable API.
Overview of changes:
* `rustc_middle/stability.rs`:
* change `deprecation_in_effect` function to return `false` when `since="TBD"`
* tidy up the compiler output when a deprecated item has `since="TBD"`
* `rustc_passes/stability.rs`:
* allow `since="TBD"` to pass the sanity check for stable_version < deprecated_version
* refactor the "invalid stability version" and "invalid deprecation version" error into separate errors
* rustdoc: make `since="TBD"` message on a deprecated item's page match the command-line deprecation output
* tests:
* test rustdoc output
* test that the `deprecated_in_future` lint fires when `since="TBD"`
* test the new "invalid deprecation version" error message
Implement if-let match guards
Implements rust-lang/rfcs#2294 (tracking issue: #51114).
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
Implement if-let match guards
Implements rust-lang/rfcs#2294 (tracking issue: #51114).
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
Take into account negative impls in "trait item not found" suggestions
This removes the suggestion to implement a trait for a type when that type already has a negative implementation for the trait, and replaces it with a note to point out that the trait is explicitely unimplemented, as suggested by `@scottmcm.`
Helps with #79683.
r? `@scottmcm` do you want to review this?
Integer types have a `count_ones` method that end up calling
`intrinsics::ctpop`.
On some architectures, that intrinsic is translated as a corresponding
CPU instruction know as "popcount" or "popcnt".
This PR makes it so that searching for those names in rustdoc shows those methods.
CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases
