2021-05-22 08:53:47 -05:00
|
|
|
//! Re-export diagnostics such that clients of `hir` don't have to depend on
|
|
|
|
//! low-level crates.
|
|
|
|
//!
|
2022-09-04 12:28:04 -05:00
|
|
|
//! This probably isn't the best way to do this -- ideally, diagnostics should
|
2021-05-22 08:53:47 -05:00
|
|
|
//! be expressed in terms of hir types themselves.
|
2023-11-14 11:09:28 -06:00
|
|
|
pub use hir_ty::diagnostics::{CaseType, IncorrectCase};
|
2023-01-20 16:09:35 -06:00
|
|
|
|
2022-06-15 11:04:39 -05:00
|
|
|
use base_db::CrateId;
|
2021-06-13 09:29:25 -05:00
|
|
|
use cfg::{CfgExpr, CfgOptions};
|
2021-06-13 07:48:54 -05:00
|
|
|
use either::Either;
|
2022-10-18 07:18:59 -05:00
|
|
|
use hir_def::path::ModPath;
|
2021-06-12 11:28:19 -05:00
|
|
|
use hir_expand::{name::Name, HirFileId, InFile};
|
2023-04-16 10:22:06 -05:00
|
|
|
use syntax::{ast, AstPtr, SyntaxError, SyntaxNodePtr, TextRange};
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
|
2023-02-21 13:00:38 -06:00
|
|
|
use crate::{AssocItem, Field, Local, MacroKind, Type};
|
2021-07-31 13:00:09 -05:00
|
|
|
|
2021-06-13 06:41:19 -05:00
|
|
|
macro_rules! diagnostics {
|
2021-06-13 09:06:36 -05:00
|
|
|
($($diag:ident,)*) => {
|
2022-07-28 13:08:20 -05:00
|
|
|
#[derive(Debug)]
|
2021-06-13 06:41:19 -05:00
|
|
|
pub enum AnyDiagnostic {$(
|
|
|
|
$diag(Box<$diag>),
|
|
|
|
)*}
|
|
|
|
|
|
|
|
$(
|
|
|
|
impl From<$diag> for AnyDiagnostic {
|
|
|
|
fn from(d: $diag) -> AnyDiagnostic {
|
|
|
|
AnyDiagnostic::$diag(Box::new(d))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
)*
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2021-06-13 09:06:36 -05:00
|
|
|
diagnostics![
|
2023-04-06 08:37:53 -05:00
|
|
|
BreakOutsideOfLoop,
|
2023-03-03 11:04:24 -06:00
|
|
|
ExpectedFunction,
|
2021-06-13 11:35:30 -05:00
|
|
|
InactiveCode,
|
2021-06-13 13:09:03 -05:00
|
|
|
IncorrectCase,
|
2021-11-18 15:17:22 -06:00
|
|
|
InvalidDeriveTarget,
|
2023-01-20 16:09:35 -06:00
|
|
|
IncoherentImpl,
|
2023-04-16 07:15:59 -05:00
|
|
|
MacroDefError,
|
2023-04-16 10:22:06 -05:00
|
|
|
MacroError,
|
|
|
|
MacroExpansionParseError,
|
2021-11-19 06:17:35 -06:00
|
|
|
MalformedDerive,
|
2021-06-13 12:06:25 -05:00
|
|
|
MismatchedArgCount,
|
2023-09-08 07:31:26 -05:00
|
|
|
MismatchedTupleStructPatArgCount,
|
2021-06-13 11:35:30 -05:00
|
|
|
MissingFields,
|
2021-06-13 13:44:31 -05:00
|
|
|
MissingMatchArms,
|
2021-06-13 12:00:27 -05:00
|
|
|
MissingUnsafe,
|
2023-05-18 10:47:06 -05:00
|
|
|
MovedOutOfRef,
|
2023-02-21 13:00:38 -06:00
|
|
|
NeedMut,
|
2021-06-13 11:45:16 -05:00
|
|
|
NoSuchField,
|
2023-01-01 06:24:48 -06:00
|
|
|
PrivateAssocItem,
|
2022-12-31 07:20:59 -06:00
|
|
|
PrivateField,
|
2021-06-13 12:32:54 -05:00
|
|
|
ReplaceFilterMapNextWithFindMap,
|
2023-11-14 13:02:23 -06:00
|
|
|
TraitImplIncorrectSafety,
|
|
|
|
TraitImplOrphan,
|
2023-05-28 06:30:34 -05:00
|
|
|
TypedHole,
|
2022-03-20 10:26:48 -05:00
|
|
|
TypeMismatch,
|
2023-04-06 05:50:16 -05:00
|
|
|
UndeclaredLabel,
|
2021-06-13 11:35:30 -05:00
|
|
|
UnimplementedBuiltinMacro,
|
2023-04-06 05:50:16 -05:00
|
|
|
UnreachableLabel,
|
2021-06-13 09:06:36 -05:00
|
|
|
UnresolvedExternCrate,
|
2023-03-03 12:32:18 -06:00
|
|
|
UnresolvedField,
|
2021-06-13 09:06:36 -05:00
|
|
|
UnresolvedImport,
|
|
|
|
UnresolvedMacroCall,
|
2023-03-03 13:41:17 -06:00
|
|
|
UnresolvedMethodCall,
|
2021-06-13 11:35:30 -05:00
|
|
|
UnresolvedModule,
|
2021-06-13 09:51:44 -05:00
|
|
|
UnresolvedProcMacro,
|
2023-02-21 13:00:38 -06:00
|
|
|
UnusedMut,
|
2023-09-24 12:59:15 -05:00
|
|
|
UnusedVariable,
|
2021-06-13 09:06:36 -05:00
|
|
|
];
|
2021-06-13 06:41:19 -05:00
|
|
|
|
2023-04-06 08:37:53 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct BreakOutsideOfLoop {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub is_break: bool,
|
|
|
|
pub bad_value_break: bool,
|
|
|
|
}
|
|
|
|
|
2023-05-28 06:30:34 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct TypedHole {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub expected: Type,
|
|
|
|
}
|
|
|
|
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedModule {
|
2021-06-13 06:41:19 -05:00
|
|
|
pub decl: InFile<AstPtr<ast::Module>>,
|
2022-03-11 09:49:41 -06:00
|
|
|
pub candidates: Box<[String]>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedExternCrate {
|
2021-06-13 08:05:43 -05:00
|
|
|
pub decl: InFile<AstPtr<ast::ExternCrate>>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedImport {
|
2021-06-13 08:42:34 -05:00
|
|
|
pub decl: InFile<AstPtr<ast::UseTree>>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UnresolvedMacroCall {
|
2022-04-27 13:03:57 -05:00
|
|
|
pub macro_call: InFile<SyntaxNodePtr>,
|
2022-06-24 06:03:13 -05:00
|
|
|
pub precise_location: Option<TextRange>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
pub path: ModPath,
|
2022-04-27 13:03:57 -05:00
|
|
|
pub is_bang: bool,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
}
|
2023-04-06 05:50:16 -05:00
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UnreachableLabel {
|
|
|
|
pub node: InFile<AstPtr<ast::Lifetime>>,
|
|
|
|
pub name: Name,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UndeclaredLabel {
|
|
|
|
pub node: InFile<AstPtr<ast::Lifetime>>,
|
|
|
|
pub name: Name,
|
|
|
|
}
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct InactiveCode {
|
2021-06-13 09:29:25 -05:00
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
pub cfg: CfgExpr,
|
|
|
|
pub opts: CfgOptions,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UnresolvedProcMacro {
|
2021-06-13 09:51:44 -05:00
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
/// If the diagnostic can be pinpointed more accurately than via `node`, this is the `TextRange`
|
|
|
|
/// to use instead.
|
|
|
|
pub precise_location: Option<TextRange>,
|
|
|
|
pub macro_name: Option<String>,
|
2022-06-14 03:40:57 -05:00
|
|
|
pub kind: MacroKind,
|
2022-06-15 11:04:39 -05:00
|
|
|
/// The crate id of the proc-macro this macro belongs to, or `None` if the proc-macro can't be found.
|
2022-06-28 03:41:10 -05:00
|
|
|
pub krate: CrateId,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct MacroError {
|
2021-06-13 10:41:04 -05:00
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
2022-06-24 06:03:13 -05:00
|
|
|
pub precise_location: Option<TextRange>,
|
internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-23 15:31:59 -05:00
|
|
|
pub message: String,
|
|
|
|
}
|
|
|
|
|
2023-04-16 10:22:06 -05:00
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct MacroExpansionParseError {
|
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
|
|
|
pub precise_location: Option<TextRange>,
|
|
|
|
pub errors: Box<[SyntaxError]>,
|
|
|
|
}
|
|
|
|
|
2023-04-16 07:15:59 -05:00
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct MacroDefError {
|
|
|
|
pub node: InFile<AstPtr<ast::Macro>>,
|
|
|
|
pub message: String,
|
|
|
|
pub name: Option<TextRange>,
|
|
|
|
}
|
|
|
|
|
2021-05-29 21:19:47 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnimplementedBuiltinMacro {
|
2021-06-13 11:35:30 -05:00
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
2021-05-29 21:19:47 -05:00
|
|
|
}
|
2021-06-12 09:17:23 -05:00
|
|
|
|
2021-11-18 15:17:22 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct InvalidDeriveTarget {
|
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
|
|
|
}
|
|
|
|
|
2021-11-19 06:17:35 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MalformedDerive {
|
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
|
|
|
}
|
|
|
|
|
2021-06-12 09:17:23 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct NoSuchField {
|
2023-10-06 05:32:37 -05:00
|
|
|
pub field: InFile<AstPtr<Either<ast::RecordExprField, ast::RecordPatField>>>,
|
2023-09-08 16:19:30 -05:00
|
|
|
pub private: bool,
|
2021-06-12 09:17:23 -05:00
|
|
|
}
|
|
|
|
|
2023-01-01 06:24:48 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct PrivateAssocItem {
|
2023-10-06 05:32:37 -05:00
|
|
|
pub expr_or_pat: InFile<AstPtr<Either<ast::Expr, Either<ast::Pat, ast::SelfParam>>>>,
|
2023-01-01 06:24:48 -06:00
|
|
|
pub item: AssocItem,
|
|
|
|
}
|
|
|
|
|
2023-09-08 07:31:26 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MismatchedTupleStructPatArgCount {
|
2023-10-06 05:32:37 -05:00
|
|
|
pub expr_or_pat: InFile<AstPtr<Either<ast::Expr, ast::Pat>>>,
|
2023-09-08 07:31:26 -05:00
|
|
|
pub expected: usize,
|
|
|
|
pub found: usize,
|
|
|
|
}
|
|
|
|
|
2023-03-03 11:04:24 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct ExpectedFunction {
|
|
|
|
pub call: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub found: Type,
|
|
|
|
}
|
|
|
|
|
2023-03-03 12:32:18 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedField {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub receiver: Type,
|
|
|
|
pub name: Name,
|
|
|
|
pub method_with_same_name_exists: bool,
|
|
|
|
}
|
|
|
|
|
2023-03-03 13:41:17 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedMethodCall {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub receiver: Type,
|
|
|
|
pub name: Name,
|
|
|
|
pub field_with_same_name: Option<Type>,
|
|
|
|
}
|
|
|
|
|
2022-12-31 07:20:59 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct PrivateField {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub field: Field,
|
|
|
|
}
|
|
|
|
|
2021-06-12 09:39:46 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingUnsafe {
|
2021-06-13 12:00:27 -05:00
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 09:39:46 -05:00
|
|
|
}
|
2021-06-12 11:28:19 -05:00
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingFields {
|
|
|
|
pub file: HirFileId,
|
2023-10-06 05:32:37 -05:00
|
|
|
pub field_list_parent: AstPtr<Either<ast::RecordExpr, ast::RecordPat>>,
|
2021-06-12 11:28:19 -05:00
|
|
|
pub field_list_parent_path: Option<AstPtr<ast::Path>>,
|
|
|
|
pub missed_fields: Vec<Name>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct ReplaceFilterMapNextWithFindMap {
|
|
|
|
pub file: HirFileId,
|
|
|
|
/// This expression is the whole method chain up to and including `.filter_map(..).next()`.
|
|
|
|
pub next_expr: AstPtr<ast::Expr>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MismatchedArgCount {
|
2021-06-13 12:06:25 -05:00
|
|
|
pub call_expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 11:28:19 -05:00
|
|
|
pub expected: usize,
|
|
|
|
pub found: usize,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingMatchArms {
|
2023-03-10 07:21:54 -06:00
|
|
|
pub scrutinee_expr: InFile<AstPtr<ast::Expr>>,
|
2022-06-20 05:48:09 -05:00
|
|
|
pub uncovered_patterns: String,
|
2021-06-12 11:28:19 -05:00
|
|
|
}
|
|
|
|
|
2021-08-08 03:12:40 -05:00
|
|
|
#[derive(Debug)]
|
2022-03-20 10:26:48 -05:00
|
|
|
pub struct TypeMismatch {
|
2023-10-06 05:32:37 -05:00
|
|
|
pub expr_or_pat: InFile<AstPtr<Either<ast::Expr, ast::Pat>>>,
|
2022-03-20 10:26:48 -05:00
|
|
|
pub expected: Type,
|
|
|
|
pub actual: Type,
|
2021-08-08 03:12:40 -05:00
|
|
|
}
|
|
|
|
|
2023-02-21 13:00:38 -06:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct NeedMut {
|
|
|
|
pub local: Local,
|
|
|
|
pub span: InFile<SyntaxNodePtr>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnusedMut {
|
|
|
|
pub local: Local,
|
|
|
|
}
|
2023-05-18 10:47:06 -05:00
|
|
|
|
2023-09-24 12:59:15 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnusedVariable {
|
|
|
|
pub local: Local,
|
|
|
|
}
|
|
|
|
|
2023-05-18 10:47:06 -05:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MovedOutOfRef {
|
|
|
|
pub ty: Type,
|
|
|
|
pub span: InFile<SyntaxNodePtr>,
|
|
|
|
}
|
2023-11-14 11:09:28 -06:00
|
|
|
|
|
|
|
#[derive(Debug, PartialEq, Eq)]
|
|
|
|
pub struct IncoherentImpl {
|
|
|
|
pub file_id: HirFileId,
|
|
|
|
pub impl_: AstPtr<ast::Impl>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, PartialEq, Eq)]
|
|
|
|
pub struct TraitImplOrphan {
|
|
|
|
pub file_id: HirFileId,
|
|
|
|
pub impl_: AstPtr<ast::Impl>,
|
|
|
|
}
|
2023-11-14 13:02:23 -06:00
|
|
|
|
|
|
|
// FIXME: Split this off into the corresponding 4 rustc errors
|
|
|
|
#[derive(Debug, PartialEq, Eq)]
|
|
|
|
pub struct TraitImplIncorrectSafety {
|
|
|
|
pub file_id: HirFileId,
|
|
|
|
pub impl_: AstPtr<ast::Impl>,
|
|
|
|
pub should_be_safe: bool,
|
|
|
|
}
|