9 commits

Author	SHA1	Message	Date
Peh	1f011fa4a3	style: rename crates to kebab case	2022-05-01 10:48:58 +00:00
Jonas Schievink	fa42888e27	Diagnose unresolved derive macros	2022-04-27 20:03:57 +02:00
Lukas Wirth	a9dd606387	fix: Show what file paths were expected for unresolved modules	2022-03-11 17:08:30 +01:00
Lukas Wirth	ca4baa6e55	Use FileAstId<ast::Adt> in nameres where appropriate instead	2022-01-07 14:20:27 +01:00
Lukas Wirth	ea03defeac	fix: Diagnose invalid derive attribute input	2021-11-19 13:17:35 +01:00
Lukas Wirth	6757910934	fix: Diagnose using derive on non-adt items	2021-11-19 12:10:55 +01:00
Jonas Schievink	cb5454db86	Diagnose unimplemented built-in macros	2021-05-30 04:19:47 +02:00
Jonas Schievink	b52df91877	Stop expanding UseTrees during ItemTree lowering	2021-05-26 01:01:58 +02:00
Aleksey Kladov	5c9f31d4c2	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-25 17:49:59 +03:00