2021-05-22 13:53:47 +00:00
|
|
|
//! Re-export diagnostics such that clients of `hir` don't have to depend on
|
|
|
|
//! low-level crates.
|
|
|
|
//!
|
|
|
|
//! This probably isn't the best way to do this -- ideally, diagnistics should
|
|
|
|
//! be expressed in terms of hir types themselves.
|
2021-06-13 14:29:25 +00:00
|
|
|
use cfg::{CfgExpr, CfgOptions};
|
2021-06-13 12:48:54 +00:00
|
|
|
use either::Either;
|
2021-08-08 08:12:40 +00:00
|
|
|
use hir_def::{path::ModPath, type_ref::Mutability};
|
2021-06-12 16:28:19 +00:00
|
|
|
use hir_expand::{name::Name, HirFileId, InFile};
|
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 20:31:59 +00:00
|
|
|
use syntax::{ast, AstPtr, SyntaxNodePtr, TextRange};
|
|
|
|
|
2021-07-31 18:00:09 +00:00
|
|
|
use crate::Type;
|
|
|
|
|
2021-06-13 11:41:19 +00:00
|
|
|
macro_rules! diagnostics {
|
2021-06-13 14:06:36 +00:00
|
|
|
($($diag:ident,)*) => {
|
2021-06-13 11:41:19 +00: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 14:06:36 +00:00
|
|
|
diagnostics![
|
2021-08-08 08:12:40 +00:00
|
|
|
AddReferenceHere,
|
2021-06-13 16:51:19 +00:00
|
|
|
BreakOutsideOfLoop,
|
2021-06-13 16:35:30 +00:00
|
|
|
InactiveCode,
|
2021-06-13 18:09:03 +00:00
|
|
|
IncorrectCase,
|
2021-06-13 16:35:30 +00:00
|
|
|
MacroError,
|
2021-06-13 17:06:25 +00:00
|
|
|
MismatchedArgCount,
|
2021-06-13 16:35:30 +00:00
|
|
|
MissingFields,
|
2021-06-13 18:44:31 +00:00
|
|
|
MissingMatchArms,
|
2021-06-13 17:19:11 +00:00
|
|
|
MissingOkOrSomeInTailExpr,
|
2021-06-13 17:00:27 +00:00
|
|
|
MissingUnsafe,
|
2021-06-13 16:45:16 +00:00
|
|
|
NoSuchField,
|
2021-06-13 17:13:15 +00:00
|
|
|
RemoveThisSemicolon,
|
2021-06-13 17:32:54 +00:00
|
|
|
ReplaceFilterMapNextWithFindMap,
|
2021-06-13 16:35:30 +00:00
|
|
|
UnimplementedBuiltinMacro,
|
2021-06-13 14:06:36 +00:00
|
|
|
UnresolvedExternCrate,
|
|
|
|
UnresolvedImport,
|
|
|
|
UnresolvedMacroCall,
|
2021-06-13 16:35:30 +00:00
|
|
|
UnresolvedModule,
|
2021-06-13 14:51:44 +00:00
|
|
|
UnresolvedProcMacro,
|
2021-06-13 14:06:36 +00:00
|
|
|
];
|
2021-06-13 11:41:19 +00:00
|
|
|
|
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 20:31:59 +00:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedModule {
|
2021-06-13 11:41:19 +00:00
|
|
|
pub decl: InFile<AstPtr<ast::Module>>,
|
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 20:31:59 +00:00
|
|
|
pub candidate: String,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedExternCrate {
|
2021-06-13 13:05:43 +00: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 20:31:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnresolvedImport {
|
2021-06-13 13:42:34 +00: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 20:31:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UnresolvedMacroCall {
|
2021-06-13 14:06:36 +00:00
|
|
|
pub macro_call: InFile<AstPtr<ast::MacroCall>>,
|
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 20:31:59 +00:00
|
|
|
pub path: ModPath,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct InactiveCode {
|
2021-06-13 14:29:25 +00: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 20:31:59 +00:00
|
|
|
pub cfg: CfgExpr,
|
|
|
|
pub opts: CfgOptions,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct UnresolvedProcMacro {
|
2021-06-13 14:51:44 +00: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 20:31:59 +00: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>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
|
|
|
pub struct MacroError {
|
2021-06-13 15:41:04 +00: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 20:31:59 +00:00
|
|
|
pub message: String,
|
|
|
|
}
|
|
|
|
|
2021-05-30 02:19:47 +00:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct UnimplementedBuiltinMacro {
|
2021-06-13 16:35:30 +00:00
|
|
|
pub node: InFile<SyntaxNodePtr>,
|
2021-05-30 02:19:47 +00:00
|
|
|
}
|
2021-06-12 14:17:23 +00:00
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct NoSuchField {
|
2021-06-13 16:45:16 +00:00
|
|
|
pub field: InFile<AstPtr<ast::RecordExprField>>,
|
2021-06-12 14:17:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct BreakOutsideOfLoop {
|
2021-06-13 16:51:19 +00:00
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 14:17:23 +00:00
|
|
|
}
|
2021-06-12 14:39:46 +00:00
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingUnsafe {
|
2021-06-13 17:00:27 +00:00
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 14:39:46 +00:00
|
|
|
}
|
2021-06-12 16:28:19 +00:00
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingFields {
|
|
|
|
pub file: HirFileId,
|
2021-06-13 12:48:54 +00:00
|
|
|
pub field_list_parent: Either<AstPtr<ast::RecordExpr>, AstPtr<ast::RecordPat>>,
|
2021-06-12 16:28:19 +00: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 17:06:25 +00:00
|
|
|
pub call_expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 16:28:19 +00:00
|
|
|
pub expected: usize,
|
|
|
|
pub found: usize,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct RemoveThisSemicolon {
|
2021-06-13 17:13:15 +00:00
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 16:28:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingOkOrSomeInTailExpr {
|
2021-06-13 17:19:11 +00:00
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
2021-06-12 16:28:19 +00:00
|
|
|
// `Some` or `Ok` depending on whether the return type is Result or Option
|
|
|
|
pub required: String,
|
2021-07-31 18:00:09 +00:00
|
|
|
pub expected: Type,
|
2021-06-12 16:28:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct MissingMatchArms {
|
|
|
|
pub file: HirFileId,
|
|
|
|
pub match_expr: AstPtr<ast::Expr>,
|
|
|
|
pub arms: AstPtr<ast::MatchArmList>,
|
|
|
|
}
|
|
|
|
|
2021-08-08 08:12:40 +00:00
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct AddReferenceHere {
|
|
|
|
pub expr: InFile<AstPtr<ast::Expr>>,
|
|
|
|
pub mutability: Mutability,
|
|
|
|
}
|
|
|
|
|
2021-06-12 19:05:23 +00:00
|
|
|
pub use hir_ty::diagnostics::IncorrectCase;
|