about summary refs log tree commit diff
path: root/compiler/rustc_borrowck/src
AgeCommit message (Collapse)AuthorLines
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/+27
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/+27
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.
2023-08-03Add `internal_features` lintNilstrieb-0/+1
It lints against features that are inteded to be internal to the compiler and standard library. Implements MCP #596. We allow `internal_features` in the standard library and compiler as those use many features and this _is_ the standard library from the "internal to the compiler and standard library" after all. Marking some features as internal wasn't exactly the most scientific approach, I just marked some mostly obvious features. While there is a categorization in the macro, it's not very well upheld (should probably be fixed in another PR). We always pass `-Ainternal_features` in the testsuite About 400 UI tests and several other tests use internal features. Instead of throwing the attribute on each one, just always allow them. There's nothing wrong with testing internal features^^
2023-08-02Remove constness from `TraitPredicate`Deadbeef-5/+1
2023-08-02Rollup merge of #114079 - compiler-errors:closure-upvars, r=oli-obkNilstrieb-25/+18
Use `upvar_tys` in more places, make it return a list Just a cleanup that fell out of a PR that I was gonna write, but that PR kinda got stuck.
2023-08-02Auto merge of #114358 - matthiaskrgr:rollup-d810m9e, r=matthiaskrgrbors-1/+2
Rollup of 6 pull requests Successful merges: - #114178 (Account for macros when suggesting a new let binding) - #114199 (Don't unsize coerce infer vars in select in new solver) - #114301 (Don't check unnecessarily that impl trait is RPIT) - #114314 (Tweaks to `adt_sized_constraint`) - #114322 (Fix invalid slice coercion suggestion reported in turbofish) - #114340 ([rustc_attr][nit] Replace `filter` + `is_some` with `map_or`.) r? `@ghost` `@rustbot` modify labels: rollup
2023-08-02Rollup merge of #114178 - estebank:let-binding-macro, r=petrochenkovMatthias Krüger-1/+2
Account for macros when suggesting a new let binding Provide a structured suggestion when the expression comes from a macro expansion: ``` error[E0716]: temporary value dropped while borrowed --> $DIR/borrowck-let-suggestion.rs:2:17 | LL | let mut x = vec![1].iter(); | ^^^^^^^ - temporary value is freed at the end of this statement | | | creates a temporary value which is freed while still in use LL | LL | x.use_mut(); | - borrow later used here | = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider using a `let` binding to create a longer lived value | LL ~ let binding = vec![1]; LL ~ let mut x = binding.iter(); | ```
2023-08-02Auto merge of #114170 - lcnr:add-commmentz, r=compiler-errorsbors-2/+6
add `dropck_outlives` comments
2023-08-01Use upvar_tys in more places, make it a listMichael Goulet-25/+18
2023-08-01Auto merge of #111753 - cjgillot:simp-place-conflict, r=compiler-errorsbors-90/+87
Only consider places with the same local in each_borrow_involving_path. This avoids having a busy loop that repeatedly checks for equality of locals.
2023-07-31update commentlcnr-7/+3
2023-07-28Account for macros when suggesting a new let bindingEsteban Küber-1/+2
2023-07-28dropck_outlives commentslcnr-2/+10
2023-07-27Remove `constness` from `ParamEnv`Deadbeef-6/+0
2023-07-27Rollup merge of #114075 - matthiaskrgr:fmt_args_rustc_3, r=wesleywiserMatthias Krüger-96/+67
inline format!() args from rustc_codegen_llvm to the end (4) r? `@WaffleLapkin`
2023-07-25Rollup merge of #113661 - oli-obk:tait_wtf, r=lcnrMatthias Krüger-2/+2
Double check that hidden types match the expected hidden type Fixes https://github.com/rust-lang/rust/issues/113278 specifically, but I left a TODO for where we should also add some hardening. It feels a bit like papering over the issue, but at least this way we don't get unsoundness, but just surprising errors. Errors will be improved and given spans before this PR lands. r? `@compiler-errors` `@lcnr`
2023-07-25inline format!() args from rustc_codegen_llvm to the end (4)Matthias Krüger-96/+67
r? @WaffleLapkin
2023-07-24borrowck/errors: fix i18n error in delayed bugDavid Wood-5/+4
During borrowck, the `MultiSpan` from a buffered diagnostic is cloned and used to emit a delayed bug indicating a diagnostic was buffered - when the buffered diagnostic is translated, then the cloned `MultiSpan` may contain labels which can only render with the diagnostic's arguments, but the delayed bug being emitted won't have those arguments. Adds a function which clones `MultiSpan` without also cloning the contained labels, and use this function when creating the buffered diagnostic delayed bug. Signed-off-by: David Wood <david@davidtw.co>
2023-07-24Some tracing changesOli Scherer-4/+2