about summary refs log tree commit diff
path: root/tests/ui/error-codes
AgeCommit message (Collapse)AuthorLines
2024-12-07reword trait bound suggestion message to include the boundsEsteban Küber-2/+2
2024-12-02Add `core::arch::breakpoint` and testJosh Triplett-4/+4
Approved in [ACP 491](https://github.com/rust-lang/libs-team/issues/491). Remove the `unsafe` on `core::intrinsics::breakpoint()`, since it's a safe intrinsic to call and has no prerequisites. (Thanks to @zachs18 for figuring out the `bootstrap`/`not(bootstrap)` logic.)
2024-11-30Rollup merge of #133620 - ↵许杰友 Jieyou Xu (Joe)-5/+30
dev-ardi:simplify-hir_typeck_pass_to_variadic_function, r=compiler-errors Simplify hir_typeck_pass_to_variadic_function r? ``@compiler-errors`` This reworks a bit how the diagnostic is generated so that it does the same as #133538 The `help` is useless now so I removed it
2024-11-30Rollup merge of #116161 - Soveu:varargs2, r=cjgillot许杰友 Jieyou Xu (Joe)-1/+1
Stabilize `extended_varargs_abi_support` I think that is everything? If there is any documentation regarding `extern` and/or varargs to correct, let me know, some quick greps suggest that there might be none. Tracking issue: https://github.com/rust-lang/rust/issues/100189
2024-11-29simplify how the `hir_typeck_pass_to_variadic_function` diagnostic is createdOrion Gonzalez-5/+30
2024-11-29Rollup merge of #133538 - dev-ardi:69232-better-diag, r=compiler-errorsMatthias Krüger-5/+8
Better diagnostic for fn items in variadic functions closes #69232
2024-11-29bless the tests and add a new oneOrion Gonzalez-5/+8
2024-11-27Stabilize `extended_varargs_abi_support`Soveu-1/+1
2024-11-27Bless tests due to extra error reporting due to normalizing types that are ↵Michael Goulet-2/+5
not WF It's okay though b/c these are duplicated diagnostics.
2024-11-23Update tests for new TRPL chapter orderChris Krycho-1/+1
2024-11-08remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic ↵Ralf Jung-19/+21
functions instead
2024-11-04Rollup merge of #132025 - duncpro:E0027, r=compiler-errorsJubilee-0/+16
fix suggestion for diagnostic error E0027 Closes #132008
2024-10-29Remove detail from label/note that is already available in other noteEsteban Küber-2/+2
Remove the "which is required by `{root_obligation}`" post-script in "the trait `X` is not implemented for `Y`" explanation in E0277. This information is already conveyed in the notes explaining requirements, making it redundant while making the text (particularly in labels) harder to read. ``` error[E0277]: the trait bound `NotCopy: Copy` is not satisfied --> $DIR/wf-static-type.rs:10:13 | LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None }; | ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy` | = note: required for `Option<NotCopy>` to implement `Copy` note: required by a bound in `IsCopy` --> $DIR/wf-static-type.rs:7:17 | LL | struct IsCopy<T:Copy> { t: T } | ^^^^ required by this bound in `IsCopy` ``` vs the prior ``` error[E0277]: the trait bound `NotCopy: Copy` is not satisfied --> $DIR/wf-static-type.rs:10:13 | LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None }; | ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy` | = note: required for `Option<NotCopy>` to implement `Copy` note: required by a bound in `IsCopy` --> $DIR/wf-static-type.rs:7:17 | LL | struct IsCopy<T:Copy> { t: T } | ^^^^ required by this bound in `IsCopy` ```
2024-10-24add third help hint to diagnostic error E0027Duncan Proctor-0/+16
2024-10-19Prevent overflowing enum cast from ICEingclubby789-2/+68
2024-10-17Rollup merge of #128391 - cafce25:issue-128390, r=lcnrMatthias Krüger-6/+8
Change orphan hint from "only" to "any uncovered type inside..." Fix #128390
2024-10-15stabilize `-Znext-solver=coherence`lcnr-1/+1
2024-10-08fix/update teach_note from 'escaping mutable ref/ptr' const-checkRalf Jung-1/+1
2024-10-04Use wide pointers consistenly across the compilerUrgau-1/+1
2024-09-27Rollup merge of #130826 - fmease:compiler-mv-obj-safe-dyn-compat, ↵Matthias Krüger-2/+2
r=compiler-errors Compiler: Rename "object safe" to "dyn compatible" Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118. Tracking issue: https://github.com/rust-lang/rust/issues/130852 Excludes `compiler/rustc_codegen_cranelift` (to be filed separately). Includes Stable MIR. Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language). r? ghost
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-26Make new information notes instead of labelsJonathan Birk-8/+8
2024-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-2/+2
2024-09-16Introduce distinct error codes for precise capturingMichael Goulet-0/+26
2024-09-15stabilize const_mut_refsRalf Jung-170/+7
2024-09-11Revert 'Stabilize -Znext-solver=coherence'Michael Goulet-1/+1
2024-09-09Ban non-array SIMDScott McMurray-7/+16
2024-09-05stabilize `-Znext-solver=coherence`lcnr-1/+1
2024-08-31Rewrite lint_expectations in a single pass.Camille GILLOT-6/+1
2024-08-23Print the generic parameter along with the variance in dumps.Camille GILLOT-2/+2
2024-08-19Reword the "unreachable pattern" explanationsNadrieril-2/+2
2024-08-11Add more information link to orphan implsJonathan Birk-2/+4
2024-08-10Differentiate between methods and associated functionsEsteban Küber-7/+7
Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
2024-08-02More information for fully-qualified suggestion when there are multiple implsEsteban Küber-6/+10
``` error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type --> $DIR/E0283.rs:30:21 | LL | fn create() -> u32; | ------------------- `Coroutine::create` defined here ... LL | let cont: u32 = Coroutine::create(); | ^^^^^^^^^^^^^^^^^^^ cannot call associated function of trait | help: use a fully-qualified path to a specific available implementation | LL | let cont: u32 = <Impl as Coroutine>::create(); | ++++++++ + LL | let cont: u32 = <AnotherImpl as Coroutine>::create(); | +++++++++++++++ + ```
2024-07-31Rollup merge of #128244 - compiler-errors:move-clone-sugg, r=estebankMatthias Krüger-2/+2
Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks Also remove a heck of a lot of weird hacks in `suggest_cloning` that I don't think we should have around. I know this regresses tests, but I don't believe most of these suggestions were accurate, b/c: 1. They either produced type errors (e.g. turning `&x` into `x.clone()`) 2. They don't fix the issue 3. They fix the issue ostensibly, but introduce logic errors (e.g. cloning a `&mut Option<T>` to then `Option::take` out...) Most of the suggestions are still wrong, but they're not particularly *less* wrong IMO. Stacked on top of #128241, which is an "obviously worth landing" subset of this PR. r? estebank
2024-07-30Adjust orphan note in testsJonathan Birk-2/+2
2024-07-29Structured suggestion for `extern crate foo` when `foo` isn't resolved in importEsteban Küber-1/+4
When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```
2024-07-27improve dangling/oob errors and make them more uniformRalf Jung-1/+1
2024-07-26Peel off explicit (or implicit) deref before suggesting clone on move error ↵Michael Goulet-2/+2
in borrowck
2024-07-26Auto merge of #128034 - Nadrieril:explain-unreachable, r=compiler-errorsbors-1/+10
exhaustiveness: Explain why a given pattern is considered unreachable This PR tells the user why a given pattern is considered unreachable. I reused the intersection information we were already computing; even though it's incomplete I convinced myself that it is sufficient to always get a set of patterns that cover the unreachable one. I'm not a fan of the diagnostic messages I came up with, I'm open to suggestions. Fixes https://github.com/rust-lang/rust/issues/127870. This is also the other one of the two diagnostic improvements I wanted to do before https://github.com/rust-lang/rust/pull/122792. Note: the first commit is an unrelated drive-by tweak. r? `@compiler-errors`
2024-07-25Rollup merge of #128111 - estebank:no-question, r=fmeaseMatthias Krüger-1/+1
Do not use question as label We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might": ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ you might be missing crate `spam` | = help: consider adding `extern crate spam` to use the `spam` crate ```
2024-07-25Rollup merge of #127528 - estebank:ascii-control-chars, r=oli-obkMatthias Krüger-1/+1
Replace ASCII control chars with Unicode Control Pictures Replace ASCII control chars like `CR` with Unicode Control Pictures like `␍`: ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ``` Centralize the checking of unicode char width for the purposes of CLI display in one place. Account for the new replacements. Remove unneeded tracking of "zero-width" unicode chars, as we calculate these in the `SourceMap` as needed now.
2024-07-24Do not use question as labelEsteban Küber-1/+1
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might": ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ you might be missing crate `spam` | = help: consider adding `extern crate spam` to use the `spam` crate ```
2024-07-24Improve "covered_by_many" errorNadrieril-2/+7
2024-07-24Explain why a given pattern is considered unreachableNadrieril-1/+5
2024-07-22Revert suggestion verbosity changeEsteban Küber-48/+24
2024-07-22On generic and lifetime removal suggestion, do not leave behind stray `,`Esteban Küber-6/+6
2024-07-22Change suggestion message wordingEsteban Küber-16/+16
2024-07-22Use verbose suggestion for "wrong # of generics"Esteban Küber-24/+48
2024-07-21Auto merge of #127722 - BoxyUwU:new_adt_const_params_limitations, ↵bors-6/+6
r=compiler-errors Forbid borrows and unsized types from being used as the type of a const generic under `adt_const_params` Fixes #112219 Fixes #112124 Fixes #112125 ### Motivation Currently the `adt_const_params` feature allows writing `Foo<const N: [u8]>` this is entirely useless as it is not possible to write an expression which evaluates to a type that is not `Sized`. In order to actually use unsized types in const generics they are typically written as `const N: &[u8]` which *is* possible to provide a value of. Unfortunately allowing the types of const parameters to contain references is non trivial (#120961) as it introduces a number of difficult questions about how equality of references in the type system should behave. References in the types of const generics is largely only useful for using unsized types in const generics. This PR introduces a new feature gate `unsized_const_parameters` and moves support for `const N: [u8]` and `const N: &...` from `adt_const_params` into it. The goal here hopefully is to experiment with allowing `const N: [u8]` to work without references and then eventually completely forbid references in const generics. Splitting this out into a new feature gate means that stabilization of `adt_const_params` does not have to resolve #120961 which is the only remaining "big" blocker for the feature. Remaining issues after this are a few ICEs and naming bikeshed for `ConstParamTy`. ### Implementation The implementation is slightly subtle here as we would like to ensure that a stabilization of `adt_const_params` is forwards compatible with any outcome of `unsized_const_parameters`. This is inherently tricky as we do not support unstable trait implementations and we determine whether a type is valid as the type of a const parameter via a trait bound. There are a few constraints here: - We would like to *allow for the possibility* of adding a `Sized` supertrait to `ConstParamTy` in the event that we wind up opting to not support unsized types and instead requiring people to write the 'sized version', e.g. `const N: [u8; M]` instead of `const N: [u8]`. - Crates should be able to enable `unsized_const_parameters` and write trait implementations of `ConstParamTy` for `!Sized` types without downstream crates that only enable `adt_const_params` being able to observe this (required for std to be able to `impl<T> ConstParamTy for [T]` Ultimately the way this is accomplished is via having two traits (sad), `ConstParamTy` and `UnsizedConstParamTy`. Depending on whether `unsized_const_parameters` is enabled or not we change which trait is used to check whether a type is allowed to be a const parameter. Long term (when stabilizing `UnsizedConstParamTy`) it should be possible to completely merge these traits (and derive macros), only having a single `trait ConstParamTy` and `macro ConstParamTy`. Under `adt_const_params` it is now illegal to directly refer to `ConstParamTy` it is only used as an internal impl detail by `derive(ConstParamTy)` and checking const parameters are well formed. This is necessary in order to ensure forwards compatibility with all possible future directions for `feature(unsized_const_parameters)`. Generally the intuition here should be that `ConstParamTy` is the stable trait that everything uses, and `UnsizedConstParamTy` is that plus unstable implementations (well, I suppose `ConstParamTy` isn't stable yet :P).