about summary refs log tree commit diff
path: root/tests/ui/inference
AgeCommit message (Collapse)AuthorLines
2025-09-30Fix unuseful span in type error in some format_args!() invocationsTomoaki Kobayashi-3/+3
2025-09-26use `try_structurally_resolve_type` for method receiverlcnr-2/+2
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`. This slightly worsens the span of `infer_var.method()` which is now the same as for `Box::new(infer_var).method()`. Unlike `structurally_resolve_type`, `probe_op` does not check whether the infcx is already tainted, so this results in 2 previously not emitted errors.
2025-09-26Auto merge of #145882 - m-ou-se:format-args-extend-1-arg, r=petrochenkovbors-3/+3
Extended temporary argument to format_args!() in all cases Fixes https://github.com/rust-lang/rust/issues/145880 by removing the special case.
2025-09-19Rollup merge of #146541 - joboet:simplify-lookup-host, r=tgross35Stuart Cook-19/+1
std: simplify host lookup The logic for splitting up a string into a hostname and port is currently duplicated across (nearly) all of the networking implementations in `sys`. Since it does not actually rely on any system internals, this PR moves it to the `ToSocketAddr` implementation for `&str`, making it easier to discover and maintain. On the other hand, the `ToSocketAddr` implementation (or rather the `resolve_socket_addr` function) contained logic to overwrite the port on the socket addresses returned by `LookupHost`, even though `LookupHost` is already aware of the port and sets the port already on Xous. This PR thus removes this logic by moving the responsibility of setting the port to the system-specific `LookupHost` implementation. As a consequence of these changes, there remains only one way of creating `LookupHost`, hence I've removed the `TryFrom` implementations in favour of a `lookup_host` function, mirroring other, public iterator-based features. And finally, I've simplified the parsing logic responsible for recognising IP addresses passed to `<(&str, u16)>::to_socket_addrs()` by using the `FromStr` impl of `IpAddr` rather than duplicating the parsing for both IP versions.
2025-09-19std: simplify host lookupjoboet-19/+1
2025-09-18support calls on opaque types :<lcnr-4/+2
2025-09-08disallow c-variadic coroutinesFolkert de Vries-2/+9
2025-08-26Update tests.Mara Bos-3/+3
2025-08-19bless tests with new lint messagesKarol Zwolak-2/+2
2025-08-19Rollup merge of #140956 - Kixunil:impl-partialeq-str-for-path, r=AmanieuStuart Cook-8/+4
`impl PartialEq<{str,String}> for {Path,PathBuf}` This is a revival of #105877 Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions. ACP: https://github.com/rust-lang/libs-team/issues/151
2025-08-10Rollup merge of #144403 - Kivooeo:issue4, r=jieyouxuStuart Cook-0/+31
`tests/ui/issues/`: The Issues Strike Back [4/N] Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895. r? ````````@jieyouxu````````
2025-08-09commentsKivooeo-0/+24
2025-08-08Rollup merge of #144039 - estebank:short-paths, r=fee1-deadTrevor Gross-2/+5
Use `tcx.short_string()` in more diagnostics `TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`. We add support for shortening the path of "trait path only". Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
2025-08-07Use `tcx.short_string()` in more diagnosticsEsteban Küber-2/+5
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`. We add support for shortening the path of "trait path only". Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem). When we don't actually print out a shortened type we don't need the "use `--verbose`" note. On E0599 show type identity to avoid expanding the receiver's generic parameters. Unify wording on `long_ty_path` everywhere.
2025-08-05commentsKivooeo-0/+56
2025-08-05Rollup merge of #144548 - Oneirical:uncountable-integer-2, r=jieyouxuSamuel Tardieu-0/+20
Rehome 21 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` rust-lang/rust#143902 divided into smaller, easier to review chunks. Part of rust-lang/rust#133895 Methodology: 1. Refer to the previously written `tests/ui/SUMMARY.md` 2. Find an appropriate category for the test, using the original issue thread and the test contents. 3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers) 4. Rename the tests to make their purpose clearer Inspired by the methodology that ``@Kivooeo`` was using. r? ``@jieyouxu``
2025-08-02Rehome tests/ui/issues/ tests [2/?]Oneirical-0/+20
2025-07-25commentsKivooeo-0/+25
2025-07-25moved 34 tests to organized locationsKivooeo-0/+7
2025-07-10Make `Diag::multipart_suggestions` always verboseEsteban Küber-3/+6
2025-06-26Rollup merge of #142981 - compiler-errors:verbose-missing-suggestion, r=estebankMatthias Krüger-10/+24
Make missing lifetime suggestion verbose I keep seeing this suggestion when working on rustc, and it's annoying that it's inline. Part of https://github.com/rust-lang/rust/issues/141973. Feel free to close this if there's another PR already doing this. r? ``@estebank``
2025-06-26Simplify IfCauseMichael Goulet-15/+12
2025-06-24Make missing lifetime suggestion verboseMichael Goulet-10/+24
2025-06-23compiletest: Improve diagnostics for line annotation mismatchesVadim Petrochenkov-1/+1
2025-05-13`impl PartialEq<{str,String}> for {Path,PathBuf}`Martin Habovstiak-8/+4
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions. ACP: https://github.com/rust-lang/libs-team/issues/151
2025-05-09Disarm `time` bomb (diagnostics)Jieyou Xu-27/+0
Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu" This reverts commit 26f75a65d70773e4520634b9f6599ddf08c499e6, reversing changes made to 2572e0e8c9d5d671eccb1d5791e55c929c4720f4. Imports are modified to fix merge conflicts and remove unused ones.
2025-04-30compiletest: Make diagnostic kind mandatory on line annotationsVadim Petrochenkov-9/+11
2025-04-19tests: adjust `tests/ui/auto-instantiate.rs`Jieyou Xu-0/+28
- Reformat the test. - Document test intention. - Move test under `tests/ui/inference/`.
2025-02-22Remove MaybeForgetReturn suggestionMichael Goulet-8/+0
2025-02-14fallout :skull_emoji:lcnr-2/+2
2025-02-12Rollup merge of #135965 - estebank:shorten-ty-sugg, r=lcnrMatthias Krüger-10/+34
In "specify type" suggestion, skip type params that are already known When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified. This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible: ``` error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>` --> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9 | LL | let y = Err(x); | ^ ------ type must be known at this point | help: consider giving `y` an explicit type, where the type for type parameter `T` is specified | LL | let y: Result<T, _> = Err(x); | ++++++++++++++ ``` Fix #135919.
2025-02-10Show diff suggestion format on verbose replacementEsteban Küber-54/+81
``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL - let _ = 2.l; LL + let _ = 2.0f64; | ```
2025-02-05Rollup merge of #136449 - joboet:move_pal_net, r=ChrisDenton许杰友 Jieyou Xu (Joe)-1/+1
std: move network code into `sys` As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules. I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
2025-02-03In "specify type" suggestion, skip type params that are already knownEsteban Küber-10/+34
When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified. This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible: ``` error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>` --> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9 | LL | let y = Err(x); | ^ ------ type must be known at this point | help: consider giving `y` an explicit type, where the type for type parameter `T` is specified | LL | let y: Result<T, _> = Err(x); | ++++++++++++++ ```
2025-02-03Enable more tests on WindowsBen Kimock-1/+1
2025-02-02bless UI test involving private namejoboet-1/+1
2025-01-11Bless new test output (new trait impls in lists of suggestions)Josh Triplett-5/+17
2024-12-31chore: fix typosdxsullivan-1/+1
Signed-off-by: dxsullivan <193140725+dxsullivan@users.noreply.github.com>
2024-11-26Auto merge of #133505 - compiler-errors:rollup-xjp8hdi, r=compiler-errorsbors-2/+2
Rollup of 12 pull requests Successful merges: - #133042 (btree: add `{Entry,VacantEntry}::insert_entry`) - #133070 (Lexer tweaks) - #133136 (Support ranges in `<[T]>::get_many_mut()`) - #133140 (Inline ExprPrecedence::order into Expr::precedence) - #133155 (Yet more `rustc_mir_dataflow` cleanups) - #133282 (Shorten the `MaybeUninit` `Debug` implementation) - #133326 (Remove the `DefinitelyInitializedPlaces` analysis.) - #133362 (No need to re-sort existential preds in relate impl) - #133367 (Simplify array length mismatch error reporting (to not try to turn consts into target usizes)) - #133394 (Bail on more errors in dyn ty lowering) - #133410 (target check_consistency: ensure target feature string makes some basic sense) - #133435 (miri: disable test_downgrade_observe test on macOS) r? `@ghost` `@rustbot` modify labels: rollup
2024-11-26tests: remove `//@ pretty-expanded` usages许杰友 Jieyou Xu (Joe)-3/+0
Done with ```bash sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs ``` and ``` sd '//@pretty-expanded.*\n' '' tests/ui/**/*.rs ```
2024-11-24Simplify array length mismatch error reportingMichael Goulet-2/+2
2024-11-03use backticks instead of single quotes when reporting "use of unstable ↵dianne-1/+1
library feature" This is consistent with all other diagnostics I could find containing features and enables the use of `DiagSymbolList` for generalizing diagnostics for unstable library features to multiple features.
2024-09-27On implicit `Sized` bound on fn argument, point at type instead of patternEsteban Küber-2/+2
Instead of ``` error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time --> $DIR/issue-59324.rs:23:20 | LL | fn with_factory<H>(factory: dyn ThriftService<()>) {} | ^^^^^^^ doesn't have a size known at compile-time ``` output ``` error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time --> $DIR/issue-59324.rs:23:29 | LL | fn with_factory<H>(factory: dyn ThriftService<()>) {} | ^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time ```
2024-09-16Relate receiver invariantly in method probe for Mode::PathMichael Goulet-4/+4
2024-09-05Rollup merge of #129664 - ↵Matthias Krüger-2/+2
adetaylor:arbitrary-self-types-pointers-feature-gate, r=wesleywiser Arbitrary self types v2: pointers feature gate. The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are: * _do_ support `self` types which can't safely implement `Deref` * do _not_ support generic `self` types * do _not_ support raw pointers as `self` types. This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes. For now, this can be resolved by adding the new `arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate. [Tracking issue](https://github.com/rust-lang/rust/issues/44874) This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-08-29Make the "detect-old-time" UI test more representativeJosh Stone-8/+16
The test code did have an inference failure, but that would have failed on Rust 1.79 and earlier too. Now it is rewritten to be specifically affected by 1.80's `impl FromIterator<_> for Box<str>`.
2024-08-28Emit specific message for `time<0.3.35` inference failureEsteban Küber-0/+19
``` error[E0282]: type annotations needed for `Box<_>` --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/time-0.3.34/src/format_description/parse/mod.rs:83:9 | 83 | let items = format_items | ^^^^^ ... 86 | Ok(items.into()) | ---- type must be known at this point | = note: this is an inference error on crate `time` caused by a change in Rust 1.80.0; update `time` to version `>=0.3.35` ``` Partially address #127343.
2024-08-27Arbitrary self types v2: pointers feature gate.Adrian Taylor-2/+2
The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are: * _do_ support `self` types which can't safely implement `Deref` * do _not_ support generic `self` types * do _not_ support raw pointers as `self` types. This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes. For now, this can be resolved by adding the new `arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate. [Tracking issue](https://github.com/rust-lang/rust/issues/44874) This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-07-29only accept adt type during infer source visitorbohan-0/+116
2024-07-17Split part of `adt_const_params` into `unsized_const_params`Boxy-1/+1