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
|
|
|
//! Diagnostics emitted during DefMap construction.
|
|
|
|
|
|
|
|
use cfg::{CfgExpr, CfgOptions};
|
|
|
|
use hir_expand::MacroCallKind;
|
2021-05-25 23:01:58 +00:00
|
|
|
use la_arena::Idx;
|
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;
|
|
|
|
|
2021-05-25 23:01:58 +00:00
|
|
|
use crate::{
|
2021-11-18 21:17:22 +00:00
|
|
|
attr::AttrId,
|
2021-05-25 23:01:58 +00:00
|
|
|
item_tree::{self, ItemTreeId},
|
|
|
|
nameres::LocalModuleId,
|
|
|
|
path::ModPath,
|
|
|
|
AstId,
|
|
|
|
};
|
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, PartialEq, Eq)]
|
|
|
|
pub enum DefDiagnosticKind {
|
|
|
|
UnresolvedModule { ast: AstId<ast::Module>, candidate: String },
|
|
|
|
|
|
|
|
UnresolvedExternCrate { ast: AstId<ast::ExternCrate> },
|
|
|
|
|
2021-05-25 23:01:58 +00:00
|
|
|
UnresolvedImport { id: ItemTreeId<item_tree::Import>, index: Idx<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
|
|
|
|
|
|
|
UnconfiguredCode { ast: AstId<ast::Item>, cfg: CfgExpr, opts: CfgOptions },
|
|
|
|
|
|
|
|
UnresolvedProcMacro { ast: MacroCallKind },
|
|
|
|
|
|
|
|
UnresolvedMacroCall { ast: AstId<ast::MacroCall>, path: ModPath },
|
|
|
|
|
|
|
|
MacroError { ast: MacroCallKind, message: String },
|
2021-05-30 02:19:47 +00:00
|
|
|
|
|
|
|
UnimplementedBuiltinMacro { ast: AstId<ast::Macro> },
|
2021-11-18 21:17:22 +00:00
|
|
|
|
|
|
|
InvalidDeriveTarget { ast: AstId<ast::Item>, id: u32 },
|
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, PartialEq, Eq)]
|
|
|
|
pub struct DefDiagnostic {
|
|
|
|
pub in_module: LocalModuleId,
|
|
|
|
pub kind: DefDiagnosticKind,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl DefDiagnostic {
|
|
|
|
pub(super) fn unresolved_module(
|
|
|
|
container: LocalModuleId,
|
|
|
|
declaration: AstId<ast::Module>,
|
|
|
|
candidate: String,
|
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
|
|
|
kind: DefDiagnosticKind::UnresolvedModule { ast: declaration, candidate },
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn unresolved_extern_crate(
|
|
|
|
container: LocalModuleId,
|
|
|
|
declaration: AstId<ast::ExternCrate>,
|
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
|
|
|
kind: DefDiagnosticKind::UnresolvedExternCrate { ast: declaration },
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn unresolved_import(
|
|
|
|
container: LocalModuleId,
|
2021-05-25 23:01:58 +00:00
|
|
|
id: ItemTreeId<item_tree::Import>,
|
|
|
|
index: Idx<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
|
|
|
) -> Self {
|
2021-05-25 23:01:58 +00:00
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnresolvedImport { id, index } }
|
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(super) fn unconfigured_code(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: AstId<ast::Item>,
|
|
|
|
cfg: CfgExpr,
|
|
|
|
opts: CfgOptions,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnconfiguredCode { ast, cfg, opts } }
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn unresolved_proc_macro(container: LocalModuleId, ast: MacroCallKind) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnresolvedProcMacro { ast } }
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn macro_error(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: MacroCallKind,
|
|
|
|
message: String,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::MacroError { ast, message } }
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn unresolved_macro_call(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: AstId<ast::MacroCall>,
|
|
|
|
path: ModPath,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnresolvedMacroCall { ast, path } }
|
|
|
|
}
|
2021-05-30 02:19:47 +00:00
|
|
|
|
|
|
|
pub(super) fn unimplemented_builtin_macro(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: AstId<ast::Macro>,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnimplementedBuiltinMacro { ast } }
|
|
|
|
}
|
2021-11-18 21:17:22 +00:00
|
|
|
|
|
|
|
pub(super) fn invalid_derive_target(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: AstId<ast::Item>,
|
|
|
|
id: AttrId,
|
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
|
|
|
kind: DefDiagnosticKind::InvalidDeriveTarget { ast, id: id.ast_index },
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|