| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Split critical edge targeting the start block
Fixes #88043.
|
|
Rollup of 10 pull requests
Successful merges:
- #87818 (Fix anchors display in rustdoc)
- #87983 (Use more accurate spans when proposing adding lifetime to item)
- #88012 (Change WASI's `RawFd` from `u32` to `c_int` (`i32`).)
- #88031 (Make `BuildHasher` object safe)
- #88036 (Fix dead code warning when inline const is used in pattern)
- #88082 (Take into account jobs number for rustdoc GUI tests)
- #88109 (Fix environment variable getter docs)
- #88111 (Add background-color on clickable definitions in source code)
- #88129 (Fix dataflow graphviz bug, make dataflow graphviz modules public)
- #88136 (Move private_unused.rs test to impl-trait)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Move private_unused.rs test to impl-trait
This test was added to fix this issue #55124 which is about impl traits but not related with type alias impl traits.
r? `@oli-obk`
`@bors` rollup=always
|
|
Fix dead code warning when inline const is used in pattern
Fixes #78171
|
|
Use more accurate spans when proposing adding lifetime to item
|
|
Matthew's work on improving NLL's "higher-ranked subtype error"s
This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374.
These are a blocker to turning full NLLs on, and doing some internal cleanups to remove some of the old region code.
The goal is so `@nikomatsakis` can take a look at this early, and I'll then do my best to help do the changes and followup work to land this work, and move closer to turning off the migration mode.
I've only updated the branch and made it compile, removed a warning or two.
r? `@nikomatsakis`
(Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)
|
|
|
|
|
|
Forbid `!` from being used in `asm!` output
Fixes #87802
r? `@Amanieu`
|
|
Update `polonius-engine` to 0.13.0
This PR updates the use of `polonius-engine` to the recently released 0.13.0:
- this version renamed a lot of relations to match the current terminology
- "illegal subset relationships errors" (AKA "subset errors" or "universal region errors" in rustc parlance) have been implemented in all variants, and therefore the `Hybrid` variant can be the rustc default once again
- some of the blessed expectations were updated: new tests have been added since the last time I updated the tests, diagnostics have changed, etc.
In particular:
- a few tests had trivial expectations changes such as basic diagnostics changes for the migrate-mode and full NLLs
- others were recursion and lengths limits which emits a file, and under the polonius compare-mode, the folder has a different name
- a few tests were ignored in the NLL compare-mode for reasons that obviously also apply to Polonius
- some diagnostics were unified so that older expectations no longer made sense: the NLL and Polonius outputs were identical.
- in a few cases Polonius gets a chance to emit more errors than NLLs
A few tests in the compare-mode still are super slow and trigger the 60s warning, or OOM rustc during fact generation, and I've detailed these [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius/topic/Challenges.20for.20move.2Finit.2C.20liveness.2C.20and.20.60Location.3A.3AAll.60):
- `src/test/ui/numbers-arithmetic/saturating-float-casts.rs` -> OOM during rustc fact generation
- `src/test/ui/numbers-arithmetic/num-wrapping.rs`
- `src/test/ui/issues/issue-72933-match-stack-overflow.rs`
- `src/test/ui/issues/issue-74564-if-expr-stack-overflow.rs`
- `src/test/ui/repr/repr-no-niche.rs`
In addition, 2 tests don't currently pass and I didn't want to bless them now: they deal with HRTBs and miss errors that NLLs emit. We're currently trying to see if we need chalk to deal with HRTB errors (as we thought we would have to) but during the recent sprint, we discovered that we may be able to detect some of these errors in a way that resembles subset errors:
- `ui/hrtb/hrtb-just-for-static.rs` -> 3 errors in NLL, 2 in polonius: a missing error about HRTB + needing to outlive 'static
- `ui/issues/issue-26217.rs` -> missing HRTB that makes the test compile instead of emitting an error
We'll keep talking about this at the next sprint as well.
cc `@rust-lang/wg-polonius` r? `@nikomatsakis`
|
|
Add "doc(test(...))" attribute checks
Fixes #82672.
r? `@camelid`
|
|
Stabilize `arbitrary_enum_discriminant`
Closes #60553.
----
## Stabilization Report
_copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_
### Summary
Enables a user to specify *explicit* discriminants on arbitrary enums.
Previously, this was hard to achieve:
```rust
#[repr(u8)]
enum Foo {
A(u8) = 0,
B(i8) = 1,
C(bool) = 42,
}
```
Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants.
In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md), this feature would provide more flexibility for FFI and unsafe code involving enums.
### Test cases
Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant), there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete).
### Edge cases
The feature is well defined and does not have many edge cases.
One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved.
### Previous PRs
The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book, https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639.
### Resolution of unresolved questions
The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271.
----
(someone please add `needs-fcp`)
|
|
constified implementations of `Default`
|
|
Enable compiler consumers to obtain mir::Body with Polonius facts.
This PR adds a function (``get_body_with_borrowck_facts``) that can be used by compiler consumers to obtain ``mir::Body`` with accompanying borrow checker information.
The most important borrow checker information that [our verifier called Prusti](https://github.com/viperproject/prusti-dev) needs is lifetime constraints. I have not found a reasonable way to compute the lifetime constraints on the Prusti side. In the compiler, the constraints are computed during the borrow checking phase and then dropped. This PR adds an additional parameter to the `do_mir_borrowck` function that tells it to return the computed information instead of dropping it.
The additionally returned information by `do_mir_borrowck` contains a ``mir::Body`` with non-erased lifetime regions and Polonius facts. I have decided to reuse the Polonius facts because this way I needed fewer changes to the compiler and Polonius facts contains other useful information that we otherwise would need to recompute.
Just FYI: up to now, Prusti was obtaining this information by [parsing the compiler logs](https://github.com/viperproject/prusti-dev/blob/b58ced8dfd14ef30582b503d517167ccd771eaff/prusti-interface/src/environment/borrowck/regions.rs#L25-L39). This is not only a hacky approach, but we also reached its limits.
r? `@nikomatsakis`
|
|
Improve non_fmt_panics suggestion based on trait impls.
This improves the non_fmt_panics lint suggestions by checking first which trait (Display or Debug) are actually implemented on the type.
Fixes https://github.com/rust-lang/rust/issues/87313
Fixes https://github.com/rust-lang/rust/issues/87999
Before:
```
help: add a "{}" format string to Display the message
|
2 | panic!("{}", Some(1));
| +++++
help: or use std::panic::panic_any instead
|
2 | std::panic::panic_any(Some(1));
| ~~~~~~~~~~~~~~~~~~~~~
```
After:
```
help: add a "{:?}" format string to use the Debug implementation of `Option<i32>`
|
2 | panic!("{:?}", Some(1));
| +++++++
help: or use std::panic::panic_any instead
|
2 | std::panic::panic_any(Some(1));
| ~~~~~~~~~~~~~~~~~~~~~
```
r? `@estebank`
|
|
Revert "Auto merge of #83417 - erikdesjardins:enableremovezsts, r=oli-obk"
This reverts commit 8007b506ac5da629f223b755f5a5391edd5f6d01, reversing changes made to e55c13e1099b78b1a485202fabc9c1b10b1f1d15.
Fixes #88043
r? `@oli-obk`
|
|
|
|
|
|
Use note for pointing at bound introducing requirement
Modify output for pointing where a trait bound obligation is introduced in an E0277 from using a span label to using a note in order to always preserve order of the output:
Before:
```
error[E0277]: `<<Self as Case1>::A as Iterator>::Item` doesn't implement `Debug`
--> $DIR/bounds-on-assoc-in-trait.rs:18:28
|
LL | type A: Iterator<Item: Debug>;
| ^^^^^ `<<Self as Case1>::A as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
::: $SRC_DIR/core/src/fmt/mod.rs:LL:COL
|
LL | pub trait Debug {
| --------------- required by this bound in `Debug`
|
= help: the trait `Debug` is not implemented for `<<Self as Case1>::A as Iterator>::Item`
```
After:
```
error[E0277]: `<<Self as Case1>::A as Iterator>::Item` doesn't implement `Debug`
--> $DIR/bounds-on-assoc-in-trait.rs:18:28
|
LL | type A: Iterator<Item: Debug>;
| ^^^^^ `<<Self as Case1>::A as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
= help: the trait `Debug` is not implemented for `<<Self as Case1>::A as Iterator>::Item`
note: required by a bound in `Debug`
--> $SRC_DIR/core/src/fmt/mod.rs:LL:COL
|
LL | pub trait Debug {
| ^^^^^^^^^^^^^^^ required by this bound in `Debug`
```
|
|
Include (potentially remapped) working dir in crate hash
Fixes #85019
A `SourceFile` created during compilation may have a relative
path (e.g. if rustc itself is invoked with a relative path).
When we write out crate metadata, we convert all relative paths
to absolute paths using the current working directory.
However, the working directory is not included in the crate hash.
This means that the crate metadata can change while the crate
hash remains the same. Among other problems, this can cause a
fingerprint mismatch ICE, since incremental compilation uses
the crate metadata hash to determine if a foreign query is green.
This commit moves the field holding the working directory from
`Session` to `Options`, including it as part of the crate hash.
cc `@ohsayan`
|
|
|
|
Rustdoc font test
Add a font test based on #85669 fixes #85632.
r? `@jsha` `@GuillaumeGomez`
|
|
Skip assert ICE with default_method_body_is_const
functions marked with #[default_method_body_is_const] would
ICE when being const checked due to it not being a const function:
`tcx.is_const_fn_raw(did)` returns false. We should skip this assert
when it is marked with that attribute.
r? `@oli-obk`
|
|
r=estebank
Closure migration multispan suggestions
This changes the `rust_2021_incompatible_closure_captures` lint to only suggest inserting the parts that need to be inserted, instead of suggesting to replace the entire closure by an almost identical closure with one statement added.
Before:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
7 + dbg!(a.0);
8 + println!("1");
9 + println!("2");
10 + println!("3");
...
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| ~~~~~~~~~~~~~~~~~~~~~~~~~
```
After:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| +++++++++++
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| +++++++++++++ +
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add future-incompat lint for `doc(primitive)`
## What is `doc(primitive)`?
`doc(primitive)` is an attribute recognized by rustdoc which adds documentation for the built-in primitive types, such as `usize` and `()`. It has been stable since Rust 1.0.
## Why change anything?
`doc(primitive)` is useless for anyone outside the standard library. Since rustdoc provides no way to combine the documentation on two different primitive items, you can only replace the docs, and since the standard library already provides extensive documentation there is no reason to do so.
While fixing rustdoc's handling of primitive items (https://github.com/rust-lang/rust/pull/87073) I discovered that even rustdoc's existing handling of primitive items was broken if you had more than two crates using it (it would pick randomly between them). That meant both:
- Keeping rustdoc's existing treatment was nigh-impossible, because it was random.
- doc(primitive) was even more useless than it would otherwise be.
The only use-case for this outside the standard library is for no-std libraries which want to link to primitives (https://github.com/rust-lang/rust/issues/73423) which is being fixed in https://github.com/rust-lang/rust/pull/87073.
https://github.com/rust-lang/rust/pull/87073 makes various breaking changes to `doc(primitive)` (breaking in the sense that they change the semantics, not in that they cause code to fail to compile). It's not possible to avoid these and still fix rustdoc's issues.
## What can we do about it?
As shown by the crater run (https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706), no one is actually using doc(primitive), there wasn't a single true regression in the whole run. We can either:
1. Feature gate it completely, breaking anyone who crater missed. They can easily fix the breakage just by removing the attribute.
2. add it to the `INVALID_DOC_ATTRIBUTES` future-incompat lint, and at the same time make it a no-op unless you add a feature gate. That would mean rustdoc has to look at the features of dependent crates, because it needs to know where primitives are defined in order to link to them.
3. add it to `INVALID_DOC_ATTRIBUTES`, but still use it to determine where primitives come from
4. do nothing; the behavior will silently change in https://github.com/rust-lang/rust/pull/87073.
My preference is for 2, but I would also be happy with 1 or 3. I don't think we should silently change the behavior.
This PR currently implements 3.
|
|
|
|
|
|
|
|
|
|
|
|
Fix `reachable_set` for non-function items in non-library crates
I unintentionally changed `reachable_set` to ignore non-function items when `!self.any_library` in https://github.com/rust-lang/rust/pull/86492, which can lead to "undefined reference" errors in non-library (`cdylib`/`staticlib`/`bin`) crates, for example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6bb2c5065a9be7e40943d0541e161b5a
This PR restores the behavior of `reachable_set` for non-function items.
Fixes https://github.com/rust-lang/rust/issues/88016.
<details>
<summary>The modified test will fail with this output without the `reachable_set` change</summary>
```
---- [codegen] codegen/external-no-mangle-statics.rs#staticlib stdout ----
error in revision `staticlib`: verification with 'FileCheck' failed
status: exit status: 1
command: "/checkout/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll" "/checkout/src/test/codegen/external-no-mangle-statics.rs" "--check-prefixes" "CHECK,NONMSVC,staticlib"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
/checkout/src/test/codegen/external-no-mangle-statics.rs:10:11: error: CHECK: expected string not found in input
// CHECK: `@A` = local_unnamed_addr constant
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:1: note: scanning from here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:6: note: possible intended match here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
Input file: /checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll
Check file: /checkout/src/test/codegen/external-no-mangle-statics.rs
-dump-input=help explains the following input dump.
Input was:
<<<<<<
1: ; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
check:10'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
check:10'1 ? possible intended match
2: source_filename = "external_no_mangle_statics.b50529d3-cgu.0"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4: target triple = "x86_64-unknown-linux-gnu"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5:
check:10'0 ~
6: !llvm.module.flags = !{!0, !1}
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.
.
.
>>>>>>
------------------------------------------
failures:
[codegen] codegen/external-no-mangle-statics.rs#staticlib
```
</details>
|
|
Uplift the invalid_atomic_ordering lint from clippy to rustc
This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.
r? `@lcnr` since you reviewed the last one, but feel free to reassign.
---
This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.
As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.
As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.
In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?
---
Some notes on the code for reviewers / others below
## Changes from clippy
The code is changed from [the implementation in clippy](https://github.com/rust-lang/rust-clippy/blob/68cf94f6a66e47234e3adefc6dfbe806cd6ad164/clippy_lints/src/atomic_ordering.rs) in the following ways:
1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
- It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
- There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
- I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
- These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
- grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
- function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
- avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).
## Potential issues
(This is just about the code in this PR, not conceptual issues with the lint or anything)
1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
- It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.
2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
- I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.
3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.
4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
|
|
|
|
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead
I ran into tons of trouble with this because apparently the change to
store HIR attrs in a side table also gave the DefIds of the
constructor instead of the variant itself. So I had to change
`matches_ordering` to also check the grandparent of the defid as well.
- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches
This prevents an ICE when there aren't enough arguments.
- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`
The functions take values, so this couldn't ever be anything else.
- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
|
|
|
|
This reverts commit 8007b506ac5da629f223b755f5a5391edd5f6d01, reversing
changes made to e55c13e1099b78b1a485202fabc9c1b10b1f1d15.
|
|
Introduce `hir::ExprKind::Let` - Take 2
Builds on #68577 and depends on #79328.
cc #53667
|
|
|
|
Deprecate llvm_asm!
We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target, to add this support to rustc).
The only remaining user of `llvm_asm!` in the standard library was `black_box`, which has been rewritten to use volatile operations when `asm!` is not available on the current target.
cc `@rust-lang/wg-inline-asm`
cc `@RalfJung` for the changes to `black_box` which might affect Miri.
r? `@nagisa`
|
|
|
|
Fixes #85019
A `SourceFile` created during compilation may have a relative
path (e.g. if rustc itself is invoked with a relative path).
When we write out crate metadata, we convert all relative paths
to absolute paths using the current working direction.
However, the working directory is not included in the crate hash.
This means that the crate metadata can change while the crate
hash remains the same. Among other problems, this can cause a
fingerprint mismatch ICE, since incremental compilation uses
the crate metadata hash to determine if a foreign query is green.
This commit moves the field holding the working directory from
`Session` to `Options`, including it as part of the crate hash.
|
|
|
|
Add automatic migration for assert!(.., string).
Fixes part of #87313.
|
|
|
