Ralf Jung
5a0a1ff0cd
move ConstValue into mir
...
this way we have mir::ConstValue and ty::ValTree as reasonably parallel
2023-09-19 11:11:02 +02:00
Ralf Jung
89ac57db4d
move required_consts check to general post-mono-check function
2023-09-14 22:30:42 +02:00
Ralf Jung
430c386821
make it more clear which functions create fresh AllocId
2023-09-14 07:27:31 +02:00
Ralf Jung
11a4a24d8e
make the set of methods between our two Const types more consistent
2023-09-13 07:29:34 +02:00
Ralf Jung
6e4779ab17
make the eval() functions on our const types return the resulting value
2023-09-13 07:29:34 +02:00
Camille GILLOT
26c48e6f95
Refactor how MIR represents composite debuginfo.
2023-09-05 17:20:07 +00:00
Matthias Krüger
9381e5bf58
Rollup merge of #115540 - cjgillot:custom-debuginfo, r=oli-obk
...
Support debuginfo for custom MIR.
2023-09-05 15:16:51 +02:00
bors
21305f4d5f
Auto merge of #115270 - sebastiantoh:issue-105479, r=Nadrieril
...
Add note on non-exhaustiveness when matching on str and nested non-exhaustive enums
Fixes https://github.com/rust-lang/rust/issues/105479
r? `@Nadrieril`
2023-09-03 19:31:47 +00:00
Sebastian Toh
d87b87d10e
Improve clarity of diagnostic message on non-exhaustive matches
2023-09-03 19:55:11 +08:00
Gurinder Singh
a0a71732f9
Fix code that now emits unused doc comment warning for expr field
2023-09-03 08:38:17 +05:30
Camille GILLOT
6cec91d647
Support debuginfo for custom MIR.
2023-09-01 16:16:31 +00:00
Ding Xiang Fei
39cf0b5dd5
use if only on lhs of binary logical exprs
2023-08-30 17:24:11 +08:00
Ding Xiang Fei
d9ed11872f
lower bare boolean expression with if-construct
2023-08-30 17:24:11 +08:00
Ding Xiang Fei
e5453b4806
lower ExprKind::Use, LogicalOp::Or and UnOp::Not
...
Co-authored-by: Abdulaziz Ghuloum <aghuloum@gmail.com>
2023-08-30 17:24:10 +08:00
Sebastian Toh
43dd8613a3
Add note when matching on nested non-exhaustive enums
2023-08-28 14:50:32 +08:00
Sebastian Toh
a293619caa
Add note that str cannot be matched exhaustively
2023-08-28 13:02:37 +08:00
bors
b60f7b51a2
Auto merge of #115045 - RalfJung:unwind-terminate-reason, r=davidtwco
...
when terminating during unwinding, show the reason why
With this, the output on double-panic becomes something like that:
```
thread 'main' panicked at src/tools/miri/tests/fail/panic/double_panic.rs:15:5:
first
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at src/tools/miri/tests/fail/panic/double_panic.rs:10:9:
second
stack backtrace:
0: 0xbe273a - std::backtrace_rs::backtrace::miri::trace_unsynchronized::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:99:5
1: 0xbe22e6 - std::backtrace_rs::backtrace::miri::trace::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:62:14
2: 0xbe1086 - std::backtrace_rs::backtrace::trace_unsynchronized::<[closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
3: 0xba3afd - std::sys_common::backtrace::_print_fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:67:5
4: 0xba2471 - <std::sys_common::backtrace::_print::DisplayBacktrace as std::fmt::Display>::fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:44:22
5: 0xbcf754 - core::fmt::rt::Argument::<'_>::fmt
at /home/r/src/rust/rustc.3/library/core/src/fmt/rt.rs:138:9
6: 0x9b8f81 - std::fmt::write
at /home/r/src/rust/rustc.3/library/core/src/fmt/mod.rs:1094:17
7: 0x21391d - <std::sys::unix::stdio::Stderr as std::io::Write>::write_fmt
at /home/r/src/rust/rustc.3/library/std/src/io/mod.rs:1714:15
8: 0xba37b1 - std::sys_common::backtrace::_print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:47:5
9: 0xba365b - std::sys_common::backtrace::print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:34:9
10: 0x143c67 - std::panic_hook_with_disk_dump::{closure#1}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:278:22
11: 0x144187 - std::panic_hook_with_disk_dump
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:312:9
12: 0x143659 - std::panicking::default_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:239:5
13: 0x1482a7 - std::panicking::rust_panic_with_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:729:13
14: 0x1475d5 - std::rt::begin_panic::<&str>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:650:9
15: 0xba496a - std::sys_common::backtrace::__rust_end_short_backtrace::<[closure@std::rt::begin_panic<&str>::{closure#0}], !>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:170:18
16: 0x147599 - std::rt::begin_panic::<&str>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:649:12
17: 0x31916 - <Foo as std::ops::Drop>::drop
at src/tools/miri/tests/fail/panic/double_panic.rs:10:9
18: 0x1a2b5e - std::ptr::drop_in_place::<Foo> - shim(Some(Foo))
at /home/r/src/rust/rustc.3/library/core/src/ptr/mod.rs:497:1
19: 0x202bf - main
at src/tools/miri/tests/fail/panic/double_panic.rs:16:1
20: 0xcc6a8 - <fn() as std::ops::FnOnce<()>>::call_once - shim(fn())
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:250:5
21: 0xba47d9 - std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:154:18
22: 0x141a6a - std::rt::lang_start::<()>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:166:18
23: 0xcca18 - std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:284:13
24: 0x146469 - std::panicking::try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
25: 0x145e09 - std::panicking::try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
26: 0x7b0ac - std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
27: 0x14189b - std::rt::lang_start_internal::{closure#2}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:48
28: 0x146481 - std::panicking::try::do_call::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
29: 0x145e2c - std::panicking::try::<isize, [closure@std::rt::lang_start_internal::{closure#2}]>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
30: 0x7b0d5 - std::panic::catch_unwind::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
31: 0x1418b0 - std::rt::lang_start_internal
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:20
32: 0x141a97 - std::rt::lang_start::<()>
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:165:17
thread 'main' panicked at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:126:5:
panic in a destructor during cleanup
stack backtrace:
0: 0xe9f6d7 - std::backtrace_rs::backtrace::miri::trace_unsynchronized::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:99:5
1: 0xe9f27d - std::backtrace_rs::backtrace::miri::trace::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:62:14
2: 0xe9e016 - std::backtrace_rs::backtrace::trace_unsynchronized::<[closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
3: 0xba3afd - std::sys_common::backtrace::_print_fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:67:5
4: 0xba2471 - <std::sys_common::backtrace::_print::DisplayBacktrace as std::fmt::Display>::fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:44:22
5: 0xbcf754 - core::fmt::rt::Argument::<'_>::fmt
at /home/r/src/rust/rustc.3/library/core/src/fmt/rt.rs:138:9
6: 0x9b8f81 - std::fmt::write
at /home/r/src/rust/rustc.3/library/core/src/fmt/mod.rs:1094:17
7: 0x4d0895 - <std::sys::unix::stdio::Stderr as std::io::Write>::write_fmt
at /home/r/src/rust/rustc.3/library/std/src/io/mod.rs:1714:15
8: 0xba37b1 - std::sys_common::backtrace::_print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:47:5
9: 0xba365b - std::sys_common::backtrace::print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:34:9
10: 0x400bd4 - std::panic_hook_with_disk_dump::{closure#1}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:278:22
11: 0x144187 - std::panic_hook_with_disk_dump
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:312:9
12: 0x143659 - std::panicking::default_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:239:5
13: 0x1482a7 - std::panicking::rust_panic_with_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:729:13
14: 0x40403b - std::panicking::begin_panic_handler::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:619:13
15: 0xe618b3 - std::sys_common::backtrace::__rust_end_short_backtrace::<[closure@std::panicking::begin_panic_handler::{closure#0}], !>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:170:18
16: 0x403fc8 - std::panicking::begin_panic_handler
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:617:5
17: 0xee23e9 - core::panicking::panic_nounwind_fmt
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:96:14
18: 0xee29e6 - core::panicking::panic_nounwind
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:126:5
19: 0xee365e - core::panicking::panic_in_cleanup
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:206:5
20: 0x2028a - main
at src/tools/miri/tests/fail/panic/double_panic.rs:13:1
21: 0x3895ee - <fn() as std::ops::FnOnce<()>>::call_once - shim(fn())
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:250:5
22: 0xe61725 - std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:154:18
23: 0x3fe9aa - std::rt::lang_start::<()>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:166:18
24: 0x389962 - std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:284:13
25: 0x4033b9 - std::panicking::try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
26: 0x402d58 - std::panicking::try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
27: 0x337ff7 - std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
28: 0x3fe7e7 - std::rt::lang_start_internal::{closure#2}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:48
29: 0x4033d6 - std::panicking::try::do_call::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
30: 0x402d7f - std::panicking::try::<isize, [closure@std::rt::lang_start_internal::{closure#2}]>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
31: 0x338028 - std::panic::catch_unwind::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
32: 0x1418b0 - std::rt::lang_start_internal
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:20
33: 0x3fe9dc - std::rt::lang_start::<()>
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:165:17
thread caused non-unwinding panic. aborting.
```
If we also land https://github.com/rust-lang/rust/pull/115020 , the 2nd backtrace disappears, hopefully making the "panic in a destructor during cleanup" easier to see.
Fixes https://github.com/rust-lang/rust/issues/114954 .
2023-08-25 08:47:18 +00:00
bors
c75b6bdb37
Auto merge of #114397 - sebastiantoh:issue-85222, r=Nadrieril
...
Add note when matching on tuples/ADTs containing non-exhaustive types
Fixes https://github.com/rust-lang/rust/issues/85222
r? `@Nadrieril`
2023-08-25 01:44:07 +00:00
Ralf Jung
4c53783f3c
when terminating during unwinding, show the reason why
2023-08-24 13:28:26 +02:00
bors
c9db1f804b
Auto merge of #115012 - Zoxc:thir-check-root, r=cjgillot
...
Ensure that THIR unsafety check is done before stealing it
This ensures that THIR unsafety check is done before stealing it by running it on the typeck root instead of on a closure, which does nothing.
Fixes https://github.com/rust-lang/rust/issues/111520
2023-08-24 00:42:46 +00:00
Sebastian Toh
82ce7b1461
Add note when matching on tuples/ADTs containing non-exhaustive types
2023-08-21 11:18:20 +08:00
Ralf Jung
818ec8e23a
give some unwind-related terminators a more clear name
2023-08-20 15:52:38 +02:00
John Kåre Alsaker
4170ca4be9
Ensure that THIR unsafety check is done before stealing it. Fixes #111520 .
2023-08-20 13:10:14 +02:00
Ralf Jung
7a6346660e
custom_mir: change Call() terminator syntax to something more readable
2023-08-19 22:41:33 +02:00
Camille GILLOT
933b618360
Revert "Implement references VarDebugInfo."
...
This reverts commit 2ec0071913
.
2023-08-17 17:02:04 +00:00
Matthias Krüger
8db5a6d8ee
Rollup merge of #114819 - estebank:issue-78124, r=compiler-errors
...
Point at return type when it influences non-first `match` arm
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`.
Fix #78124 .
2023-08-15 20:34:25 +02:00
Michael Goulet
1f42be6f55
Deny FnDef in patterns
2023-08-15 04:03:04 +00:00
Esteban Küber
5021dde1a0
Move scrutinee HirId
into MatchSource::TryDesugar
2023-08-14 21:43:56 +00:00
ouz-a
dcf2056049
Remove unnecessary FIXME
2023-08-14 20:52:17 +03:00
Matthias Krüger
3cd0a109a8
Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, r=oli-obk
...
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099 )) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
2023-08-08 03:30:56 +02:00
León Orell Valerian Liehr
5468336d6b
Store the laziness of type aliases in the DefKind
2023-08-07 15:54:31 +02:00
bors
84ec2633de
Auto merge of #113902 - Enselic:lint-recursive-drop, r=oli-obk
...
Make `unconditional_recursion` warning detect recursive drops
Closes #55388
Also closes #50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965 .
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
2023-08-07 13:39:28 +00:00
Matthias Krüger
99e4127d85
Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31
...
Improve spans for indexing expressions
fixes #114388
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
r? compiler-errors
2023-08-04 21:31:57 +02:00
Nilstrieb
5706be1854
Improve spans for indexing expressions
...
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
2023-08-04 13:17:39 +02:00
Matthias Krüger
576bf82702
Rollup merge of #114022 - oli-obk:tait_ice_alias_field_projection, r=cjgillot
...
Perform OpaqueCast field projection on HIR, too.
fixes #105819
This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).
See https://github.com/rust-lang/rust/pull/99806 for when and why we added OpaqueCast to MIR.
2023-08-04 09:18:58 +02:00
León Orell Valerian Liehr
9213aec762
Lower generic const items to HIR
2023-07-28 22:21:40 +02:00
Matthias Krüger
fa21a8c6f8
Rollup merge of #114075 - matthiaskrgr:fmt_args_rustc_3, r=wesleywiser
...
inline format!() args from rustc_codegen_llvm to the end (4)
r? `@WaffleLapkin`
2023-07-27 06:04:13 +02:00
Wesley Wiser
15e9f56088
Replace in-tree rustc_apfloat
with the new version of the crate
2023-07-26 10:20:15 -04:00
Matthias Krüger
c64ef5e070
inline format!() args from rustc_codegen_llvm to the end (4)
...
r? @WaffleLapkin
2023-07-25 23:20:28 +02:00
Oli Scherer
e390dc9c36
Perform OpaqueCast field projection on HIR, too.
...
This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).
2023-07-24 15:19:26 +00:00
Martin Nordholts
b4b33df983
Make unconditional_recursion
warning detect recursive drops
2023-07-22 14:04:45 +02:00
Martin Nordholts
eed34b8bc1
Add is_recursive_terminator() helper for unconditional_recursion
lint
2023-07-20 20:55:28 +02:00
Martin Nordholts
f92d6699b8
Avoid unneeded terminator()
call in fn ignore_edge()
2023-07-20 20:45:26 +02:00
Michael Goulet
846cc63e38
Make it clearer that edition functions are >=, not ==
2023-07-19 16:38:35 +00:00
syvb
2cfe8ed37d
Implement "items do not inherit unsafety" for THIR unsafeck
2023-07-15 11:59:38 -04:00
Mahdi Dibaiee
e55583c4b8
refactor(rustc_middle): Substs -> GenericArg
2023-07-14 13:27:35 +01:00
bors
fe03b46ee4
Auto merge of #113609 - nnethercote:maybe_lint_level_root_bounded-cache, r=cjgillot
...
Add a cache for `maybe_lint_level_root_bounded`
`maybe_lint_level_root_bounded` is called many times and traces node sub-paths many times. This PR adds a cache that lets many of these tracings be skipped, avoiding lots of calls to functions like `Map::attrs` and `Map::parent_id`.
r? `@cjgillot`
2023-07-14 05:30:53 +00:00
Mark Rousskov
cc907f80b9
Re-format let-else per rustfmt update
2023-07-12 21:49:27 -04:00
Nicholas Nethercote
667d75e546
Add a cache for maybe_lint_level_root_bounded
.
...
It's a nice speed win.
2023-07-13 09:32:09 +10:00
Nicholas Nethercote
f234dc3e1c
Move maybe_lint_level_root_bounded
.
...
From `TyCtxt` to the MIR `Builder`. This will allow us to add a cache to
`Builder` and use it from `maybe_lint_level_root_bounded`.
2023-07-12 10:02:13 +10:00