ouz-a
3148e6a993
subtyping_projections
2023-10-02 23:37:49 +03:00
Nadrieril
eac7bcde5f
Move eval_bits
optimization upstream
2023-10-01 21:12:24 +02:00
Nadrieril
0a6d794d0b
Cleanup number literal evaluation
2023-10-01 00:00:38 +02:00
Nadrieril
d6e9b321b3
No need to carry bias
in IntRange
2023-10-01 00:00:38 +02:00
Nadrieril
fac50e8fb3
Evaluate float consts eagerly
2023-10-01 00:00:37 +02:00
Matthias Krüger
fd95627134
fix clippy::{redundant_guards, useless_format}
2023-09-27 23:49:15 +02:00
bors
c4ce33cfbc
Auto merge of #115887 - RalfJung:pat, r=oli-obk
...
thir::pattern: update some comments and error type names
Follow-up to [these comments](https://github.com/rust-lang/rust/pull/105750#pullrequestreview-1629697578 ). Please carefully fact-check, I'm new to this area of the compiler!
2023-09-27 13:20:53 +00:00
bors
6b99cf1d35
Auto merge of #116163 - compiler-errors:lazyness, r=oli-obk
...
Don't store lazyness in `DefKind::TyAlias`
1. Don't store lazyness of a type alias in its `DefKind`, but instead via a query.
2. This allows us to treat type aliases as lazy if `#[feature(lazy_type_alias)]` *OR* if the alias contains a TAIT, rather than having checks for both in separate parts of the codebase.
r? `@oli-obk` cc `@fmease`
2023-09-27 01:48:53 +00:00
Michael Goulet
d6ce9ce115
Don't store lazyness in DefKind
2023-09-26 02:53:59 +00:00
Ralf Jung
a1d6fc4340
rename lint; add tracking issue
2023-09-25 19:05:10 +02:00
Ralf Jung
b589976606
use a must_hold variant for checking PartialEq
2023-09-24 16:59:47 +02:00
Ralf Jung
c3ed0c454e
make sure we always emit the no-PartialEq lint, even if there were other lints
2023-09-24 16:36:26 +02:00
Ralf Jung
c5fccb98ea
work towards rejecting consts in patterns that do not implement PartialEq
2023-09-24 16:36:26 +02:00
Guillaume Gomez
208f6ed95c
Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obk
...
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const
Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`.
Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all.
However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish...
``@oli-obk`` any ideas?
2023-09-21 13:25:39 +02:00
Oli Scherer
9c762b58ba
Prevent promotion of const fn calls in inline consts
2023-09-21 09:00:22 +00:00
Ralf Jung
c94410c145
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const
2023-09-21 08:12:30 +02:00
Ralf Jung
a2374e65aa
the Const::eval_bits methods don't need to be given the Ty
2023-09-20 07:27:21 +02:00
Ralf Jung
ea22adbabd
adjust constValue::Slice to work for arbitrary slice types
2023-09-19 20:17:43 +02:00
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
12a1b55afd
better ICE than sorry
2023-09-18 07:42:35 +02:00
Ralf Jung
d34e15e740
thir::pattern: update some comments and error type names
2023-09-16 12:25:33 +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