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.
|
|
|
|
|
2024-03-04 10:10:06 +00:00
|
|
|
use std::ops::Not;
|
|
|
|
|
2022-06-15 16:04:39 +00:00
|
|
|
use base_db::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 20:31:59 +00:00
|
|
|
use cfg::{CfgExpr, CfgOptions};
|
2023-07-04 07:16:15 +00:00
|
|
|
use hir_expand::{attrs::AttrId, ErasedAstId, MacroCallKind};
|
2021-05-25 23:01:58 +00:00
|
|
|
use la_arena::Idx;
|
2023-07-04 07:16:15 +00:00
|
|
|
use syntax::{ast, SyntaxError};
|
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
|
|
|
|
2021-05-25 23:01:58 +00:00
|
|
|
use crate::{
|
|
|
|
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 {
|
2022-03-11 15:49:41 +00:00
|
|
|
UnresolvedModule { ast: AstId<ast::Module>, 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 20:31:59 +00:00
|
|
|
UnresolvedExternCrate { ast: AstId<ast::ExternCrate> },
|
2023-08-02 12:19:38 +00:00
|
|
|
UnresolvedImport { id: ItemTreeId<item_tree::Use>, index: Idx<ast::UseTree> },
|
2023-07-04 07:16:15 +00:00
|
|
|
UnconfiguredCode { ast: ErasedAstId, cfg: CfgExpr, opts: CfgOptions },
|
2022-06-28 08:41:10 +00:00
|
|
|
UnresolvedProcMacro { ast: MacroCallKind, krate: CrateId },
|
2022-04-27 18:03:57 +00:00
|
|
|
UnresolvedMacroCall { ast: MacroCallKind, path: ModPath },
|
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
|
|
|
MacroError { ast: MacroCallKind, message: String },
|
2023-04-16 15:22:06 +00:00
|
|
|
MacroExpansionParseError { ast: MacroCallKind, errors: Box<[SyntaxError]> },
|
2021-05-30 02:19:47 +00:00
|
|
|
UnimplementedBuiltinMacro { ast: AstId<ast::Macro> },
|
2023-01-09 19:47:51 +00:00
|
|
|
InvalidDeriveTarget { ast: AstId<ast::Item>, id: usize },
|
|
|
|
MalformedDerive { ast: AstId<ast::Adt>, id: usize },
|
2023-04-16 12:15:59 +00:00
|
|
|
MacroDefError { ast: AstId<ast::Macro>, message: 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 20:31:59 +00:00
|
|
|
}
|
|
|
|
|
2024-01-15 10:07:26 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq, Eq)]
|
|
|
|
pub struct DefDiagnostics(Option<triomphe::Arc<Box<[DefDiagnostic]>>>);
|
|
|
|
|
|
|
|
impl DefDiagnostics {
|
|
|
|
pub fn new(diagnostics: Vec<DefDiagnostic>) -> Self {
|
2024-03-04 10:10:06 +00:00
|
|
|
Self(
|
|
|
|
diagnostics
|
|
|
|
.is_empty()
|
|
|
|
.not()
|
|
|
|
.then(|| triomphe::Arc::new(diagnostics.into_boxed_slice())),
|
|
|
|
)
|
2024-01-15 10:07:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn iter(&self) -> impl Iterator<Item = &DefDiagnostic> {
|
|
|
|
self.0.as_ref().into_iter().flat_map(|it| &***it)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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>,
|
2022-03-11 15:49:41 +00:00
|
|
|
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 20:31:59 +00:00
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
2022-03-11 15:49:41 +00:00
|
|
|
kind: DefDiagnosticKind::UnresolvedModule { ast: declaration, candidates },
|
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 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,
|
2023-08-02 12:19:38 +00:00
|
|
|
id: ItemTreeId<item_tree::Use>,
|
2021-05-25 23:01:58 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2022-08-08 11:15:27 +00:00
|
|
|
pub fn unconfigured_code(
|
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
|
|
|
container: LocalModuleId,
|
2023-07-04 07:16:15 +00:00
|
|
|
ast: ErasedAstId,
|
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
|
|
|
cfg: CfgExpr,
|
|
|
|
opts: CfgOptions,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnconfiguredCode { ast, cfg, opts } }
|
|
|
|
}
|
|
|
|
|
2023-04-22 09:24:50 +00:00
|
|
|
// FIXME: Whats the difference between this and unresolved_macro_call
|
2024-02-12 12:34:38 +00:00
|
|
|
// FIXME: This is used for a lot of things, unresolved proc macros, disabled proc macros, etc
|
|
|
|
// yet the diagnostic handler in ide-diagnostics has to figure out what happened because this
|
|
|
|
// struct loses all that information!
|
2023-04-22 09:24:50 +00:00
|
|
|
pub(crate) fn unresolved_proc_macro(
|
2022-06-15 15:33:55 +00:00
|
|
|
container: LocalModuleId,
|
|
|
|
ast: MacroCallKind,
|
2022-06-28 08:41:10 +00:00
|
|
|
krate: CrateId,
|
2022-06-15 15:33:55 +00:00
|
|
|
) -> Self {
|
2022-06-15 16:04:39 +00:00
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::UnresolvedProcMacro { ast, krate } }
|
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
|
|
|
}
|
|
|
|
|
2023-04-16 15:22:06 +00:00
|
|
|
pub(crate) fn macro_error(
|
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
|
|
|
container: LocalModuleId,
|
|
|
|
ast: MacroCallKind,
|
|
|
|
message: String,
|
|
|
|
) -> Self {
|
|
|
|
Self { in_module: container, kind: DefDiagnosticKind::MacroError { ast, message } }
|
|
|
|
}
|
|
|
|
|
2023-04-16 15:22:06 +00:00
|
|
|
pub(crate) fn macro_expansion_parse_error(
|
|
|
|
container: LocalModuleId,
|
|
|
|
ast: MacroCallKind,
|
2024-03-04 10:39:38 +00:00
|
|
|
errors: Box<[SyntaxError]>,
|
2023-04-16 15:22:06 +00:00
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
2024-03-04 10:39:38 +00:00
|
|
|
kind: DefDiagnosticKind::MacroExpansionParseError { ast, errors },
|
2023-04-16 15:22:06 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-04-22 09:24:50 +00:00
|
|
|
// FIXME: Whats the difference between this and unresolved_proc_macro
|
|
|
|
pub(crate) fn unresolved_macro_call(
|
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
|
|
|
container: LocalModuleId,
|
2022-04-27 18:03:57 +00:00
|
|
|
ast: MacroCallKind,
|
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
|
|
|
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,
|
2023-01-09 19:47:51 +00:00
|
|
|
kind: DefDiagnosticKind::InvalidDeriveTarget { ast, id: id.ast_index() },
|
2021-11-18 21:17:22 +00:00
|
|
|
}
|
|
|
|
}
|
2021-11-19 12:17:35 +00:00
|
|
|
|
|
|
|
pub(super) fn malformed_derive(
|
|
|
|
container: LocalModuleId,
|
2022-01-07 13:19:11 +00:00
|
|
|
ast: AstId<ast::Adt>,
|
2021-11-19 12:17:35 +00:00
|
|
|
id: AttrId,
|
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
in_module: container,
|
2023-01-09 19:47:51 +00:00
|
|
|
kind: DefDiagnosticKind::MalformedDerive { ast, id: id.ast_index() },
|
2021-11-19 12:17:35 +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
|
|
|
}
|