rust/tests/ui/debuginfo/impl-copy-function-debuginfo-58463.rs

// https://github.com/rust-lang/rust/issues/58463
//@ run-pass
//@ compile-flags:-C debuginfo=2

fn foo() -> impl Copy {
    foo
}
fn main() {
    foo();
}
Add test batch 3 2025-08-20 14:02:50 -04:00			`// https://github.com/rust-lang/rust/issues/58463`
[AUTO-GENERATED] Migrate ui tests from `//` to `//@` directives 2024-02-16 20:02:50 +00:00			`//@ run-pass`
			`//@ compile-flags:-C debuginfo=2`
Upgrade Emscripten targets to use upstream LLVM backend - Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649. 2019-08-16 22:08:01 -07:00
Fix stack overflow when generating debuginfo for 'recursive' type By using 'impl trait', it's possible to create a self-referential type as follows: fn foo() -> impl Copy { foo } This is a function which returns itself. Normally, the signature of this function would be impossible to write - it would look like 'fn foo() -> fn() -> fn() ...' e.g. a function which returns a function, which returns a function... Using 'impl trait' allows us to avoid writing this infinitely long type. While it's useless for practical purposes, it does compile and run However, issues arise when we try to generate llvm debuginfo for such a type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we generate debuginfo, which can lead to us recursing back to the original 'fn' type when we try to process its return type. To resolve this, I've modified debuginfo generation to account for these kinds of weird types. Unfortunately, there's no 'correct' debuginfo that we can generate - 'impl trait' does not exist in debuginfo, and this kind of recursive type is impossible to directly represent. To ensure that we emit something, this commit emits dummy debuginfo/type names whenever it encounters a self-reference. In practice, this should never happen - it's just to ensure that we can emit some kind of debuginfo, even if it's not particularly meaningful Fixes #58463 2019-03-26 15:30:41 -04:00			`fn foo() -> impl Copy {`
			`foo`
			`}`
			`fn main() {`
			`foo();`
			`}`