about summary refs log tree commit diff
path: root/compiler/rustc_borrowck
AgeCommit message (Collapse)AuthorLines
2023-10-02Add docs, remove code, change subtyper codeouz-a-7/+16
2023-10-02subtyping_projectionsouz-a-0/+12
2023-09-27fix clippy::{redundant_guards, useless_format}Matthias Krüger-2/+2
2023-09-27Auto merge of #116163 - compiler-errors:lazyness, r=oli-obkbors-1/+1
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-26subst -> instantiatelcnr-7/+6
2023-09-26Don't store lazyness in DefKindMichael Goulet-1/+1
2023-09-24Remove span from BrAnon.Camille GILLOT-35/+19
2023-09-24Try to use approximate placeholder regions when outputting an ↵Jack Huey-13/+54
AscribeUserType error in borrowck
2023-09-21Record asyncness span in HIRMichael Goulet-1/+1
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-22/+21
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-21Prevent promotion of const fn calls in inline constsOli Scherer-1/+1
2023-09-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-22/+21
2023-09-18Remove `RegionHighlightMode::tcx`.Nicholas Nethercote-4/+4
It's easier to pass it in to the one method that needs it (`highlighting_region_vid`) than to store it in the type. This means `RegionHighlightMode` can impl `Default`.
2023-09-12cleanup on messagesyukang-9/+0
2023-09-11Auto merge of #114586 - oli-obk:patch_tait_rpit_order_check, ↵bors-13/+20
r=lcnr,compiler-errors Bubble up opaque <eq> opaque operations instead of picking an order In case we are in `Bubble` mode (meaning every opaque type that is defined in the current crate is treated as if it were in its defining scope), we don't try to register an opaque type as the hidden type of another opaque type, but instead bubble up an obligation to equate them at the query caller site. Usually that means we have a `DefiningAnchor::Bind` and thus can reliably figure out whether an opaque type is in its defining scope. Where we can't, we'll error out, so the default is sound. With this change we start using `AliasTyEq` predicates in the old solver, too. fixes https://github.com/rust-lang/rust/issues/108498 But also regresses `tests/ui/impl-trait/anon_scope_creep.rs`. Our use of `Bubble` for `check_opaque_type_well_formed` is going to keep biting us. r? `@lcnr` `@compiler-errors`
2023-09-11Bubble up opaque <eq> opaque operations instead of picking an orderOli Scherer-13/+20
2023-09-11Auto merge of #115595 - surechen:114896, r=davidtwcobors-6/+78
Fix incorrect mutable suggestion information for binding in ref pattern like: `let &b = a;` fixes #114896 I find we have to get pat_span but not local_decl.source_info.span for suggestion. In `let &b = a;` pat_span is &b. I think check `let &b = a` in hir to make sure it is hir::Node::Local(hir::Local {pat: hir::Pat{kind: hir::PatKind::Ref(....... can distinguish it from other situation, but I'm not sure. If my processing method is not accurate, please guide me to modify it, thank you. r? `@davidtwco`
2023-09-11Auto merge of #115308 - chenyukang:yukang-fix-62387-iter-mut, r=davidtwcobors-1/+41
suggest iter_mut() where trying to modify elements from .iter() Fixes https://github.com/rust-lang/rust/issues/115259 Fixes https://github.com/rust-lang/rust/issues/62387
2023-09-11Disentangle `Debug` and `Display` for `Ty`.Nicholas Nethercote-5/+22
The `Debug` impl for `Ty` just calls the `Display` impl for `Ty`. This is surprising and annoying. In particular, it means `Debug` doesn't show as much information as `Debug` for `TyKind` does. And `Debug` is used in some user-facing error messages, which seems bad. This commit changes the `Debug` impl for `Ty` to call the `Debug` impl for `TyKind`. It also does a number of follow-up changes to preserve existing output, many of which involve inserting `with_no_trimmed_paths!` calls. It also adds `Display` impls for `UserType` and `Canonical`. Some tests have changes to expected output: - Those that use the `rustc_abi(debug)` attribute. - Those that use the `EMIT_MIR` annotation. In each case the output is slightly uglier than before. This isn't ideal, but it's pretty weird (particularly for the attribute) that the output is using `Debug` in the first place. They're fairly obscure attributes (I hadn't heard of them) so I'm not worried by this. For `async-is-unwindsafe.stderr`, there is one line that now lacks a full path. This is a consistency improvement, because all the other mentions of `Context` in this test lack a path.
2023-09-07Auto merge of #115602 - oli-obk:lower_intrinsics, r=petrochenkovbors-9/+29
Don't report any errors in `lower_intrinsics`. Intrinsics should have been type checked earlier. This is part of moving all mir-opt diagnostics early enough so that they are reliably emitted even in check builds: https://github.com/rust-lang/rust/issues/49292#issuecomment-1692212095
2023-09-07fixes #114896surechen-6/+78
2023-09-06Rollup merge of #114511 - chenyukang:yukang-fix-114374-fmt-args, r=b-naberMatthias Krüger-13/+37
Remove the unhelpful let binding diag comes from FormatArguments Fixes #114374
2023-09-07suggest iter_mut() where trying to modify elements from .iter()yukang-1/+41
2023-09-06Don't report any errors in `lower_intrinsics`. They should have been ↵Oli Scherer-9/+29
typecked before.
2023-09-02Take `&mut Results` in `ResultsVisitor`Jason Newcomb-3/+3
2023-08-31remove dummy UniverseInfo causes from type checker `fully_perform_op`Rémy Rakic-7/+5
This was backfilling causes for new universes that may have been created by an op, when there was no error info to use for improved diagnostics. We don't need to do that anymore: `other()` is the default when there is no registered universe cause.
2023-08-31remove dummy UniverseInfo causes from type checker `type_check`Rémy Rakic-4/+0
This was pre-filling causes for universes that could already exist in the InferCtxt. We don't need to do that anymore: `other()` is the default when there is no registered universe cause.
2023-08-31remove dummy UniverseInfo causes from type checker ↵Rémy Rakic-7/+0
`instantiate_canonical_with_fresh_inference_vars` This was backfilling causes for the new universes that can be created by the InferCtxt. We don't need to do that anymore: `other()` is the default when there is no registered universe cause.
2023-08-30return default `UniverseInfo` cause in `RegionInferenceContext`Rémy Rakic-1/+8
Query canonicalization can create local super-universes without causes, creating ICEs when accessed during diagnostics.
2023-08-25Auto merge of #115045 - RalfJung:unwind-terminate-reason, r=davidtwcobors-6/+6
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-24Auto merge of #115147 - estebank:issue-114311, r=davidtwcobors-88/+91
Suggest mutable borrow on read only for-loop that should be mutable ``` error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference --> $DIR/suggest-mut-iterator.rs:22:9 | LL | for test in &tests { | ------ this iterator yields `&` references LL | test.add(2); | ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: use a mutable iterator instead | LL | for test in &mut tests { | +++ ``` Fix #114311.
2023-08-24when terminating during unwinding, show the reason whyRalf Jung-6/+6
2023-08-23Bump cfg(bootstrap)Mark Rousskov-1/+1
2023-08-23Suggest mutable borrow on read only for-loop that should be mutableEsteban Küber-88/+91
``` error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference --> $DIR/suggest-mut-iterator.rs:22:9 | LL | for test in &tests { | ------ this iterator yields `&` references LL | test.add(2); | ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: use a mutable iterator instead | LL | for test in &mut tests { | +++ ``` Address #114311.
2023-08-23Remove the unhelpful let binding diag comes from FormatArgumentsyukang-13/+37
2023-08-20give some unwind-related terminators a more clear nameRalf Jung-10/+14
2023-08-19Fix redundant explicit link in rustc_borrowckKyle Lin-1/+1
2023-08-16Make TerminatorEdge plural.Camille GILLOT-2/+2
2023-08-16Allow apply_terminator_effect to customize edges.Camille GILLOT-6/+9
2023-08-16Move domain_size to GenKillAnalysis.Camille GILLOT-0/+4
2023-08-14reviewlcnr-9/+6
2023-08-14check for non-defining uses of RPITlcnr-27/+17
2023-08-08Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, ↵Matthias Krüger-1/+1
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-07Store the laziness of type aliases in the DefKindLeón Orell Valerian Liehr-1/+1
2023-08-04Rollup merge of #114477 - estebank:arc-clone, r=compiler-errorsMatthias Krüger-1/+11
Account for `Rc` and `Arc` when suggesting to clone When suggesting to clone a reference-counted value, be less uncertain.
2023-08-04Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31Matthias Krüger-3/+3
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-04Account for `Rc` and `Arc` when suggesting to cloneEsteban Küber-1/+11
When suggesting to clone a reference-counted value, be less uncertain.
2023-08-04don't ICE on higher ranked hidden typesAli MJ Al-Nasrawy-11/+29
2023-08-04Improve spans for indexing expressionsNilstrieb-3/+3
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-04Rollup merge of #114022 - oli-obk:tait_ice_alias_field_projection, r=cjgillotMatthias Krüger-4/+2
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 06:19:51 +0000