about summary refs log tree commit diff
path: root/src/test/ui/recursion/recursion.stderr
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-15/+0
2022-11-18Make "long type" printing type awareEsteban Küber-1/+1
Instead of simple string cutting, use a custom printer to hide parts of long printed types.
2020-09-21Let user see the full type of type-length limit errorKornel Lesiński-2/+3
2020-09-17Better handling for exponential-sized types in misc placesValerii Lashmanov-1/+1
Mostly to fix ui/issues/issue-37311-type-length-limit/issue-37311.rs. Most parts of the compiler can handle deeply nested types with a lot of duplicates just fine, but some parts still attempt to naively traverse type tree. Before such problems were caught by type length limit check, but now these places will have to be changed to handle duplicated types gracefully.
2020-08-22Use smaller def span for functionsAaron Hill-7/+2
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-06-22Point at the call spawn when overflow occurs during monomorphizationAaron Hill-2/+7
This improves the output for issue #72577, but there's still more work to be done. Currently, an overflow error during monomorphization results in an error that points at the function we were unable to monomorphize. However, we don't point at the call that caused the monomorphization to happen. In the overflow occurs in a large recursive function, it may be difficult to determine where the issue is. This commit tracks and `Span` information during collection of `MonoItem`s, which is used when emitting an overflow error. `MonoItem` itself is unchanged, so this only affects `src/librustc_mir/monomorphize/collector.rs`
2020-02-11Specify overflow checks behaviour in testMatthew Jasper-1/+1
2019-12-21rework run-fail and support check,build-failMazdak Farrokhzad-1/+1
2019-07-07Raise the default recursion limit to 128Simonas Kazlauskas-1/+1
2019-03-11Update testsVadim Petrochenkov-1/+1
2018-12-25Remove licensesMark Rousskov-1/+1
2018-08-14Merged migrated compile-fail tests and ui tests. Fixes #46841.David Wood-0/+14