feat: separating compiler/lint diagnostics

[hongjr03]

This pull request refactors how diagnostics and editor notifications are handled, introducing a more modular and extensible system for reporting diagnostics from both the compiler and the lint engine. The changes separate compiler and lint diagnostics, introduce a new hook-based architecture for compile-time notifications, and update the data structures and APIs throughout the codebase to support these improvements.

Diagnostics Handling and Data Structures:

• Introduced a new DiagnosticsResult struct to encapsulate both compiler and lint diagnostics, replacing the previous single DiagnosticsMap response in CheckRequest.
• Added the DiagKind enum and DiagKey struct to distinguish and track diagnostics from different sources (compiler vs. lint) per project, updating all related data structures and methods in EditorActor accordingly. [1] [2]

Editor Notification and API Changes:

• Updated the EditorRequest::Diag variant and related methods to accept a DiagKind, allowing the editor to receive and manage diagnostics from multiple sources independently. [1] [2] [3] [4]
• Adjusted all usages and sending of diagnostics to include the new DiagKind parameter, ensuring correct routing and clearing of diagnostics for both compiler and lint results. [1] [2] [3]

Hook-Based Compile Notification System:

• Introduced a new trait CompileHook and implemented it for DiagHook, LintHook, PreviewHook, and ExportHook, enabling modular notification logic for different compile-time events (diagnostics, preview updates, export tasks).
• Refactored CompileHandlerImpl to accept and use a list of CompileHook objects, replacing inline notification logic with calls to these hooks for improved extensibility and separation of concerns. [1] [2] [3] [4] [5]

Project State and Feature Handling:

• Updated project state construction to properly handle preview and export features using the new hook-based architecture and state references.

These changes make the diagnostics system more robust, allow for future extensibility (e.g., adding more diagnostic sources), and improve the maintainability of compile-time notification logic.

[gemini-code-assist]

Summary of Changes

Hello @hongjr03, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the diagnostic reporting system to differentiate between compiler and lint diagnostics. By introducing new data structures and modifying the diagnostic publishing pipeline, the system can now handle and present these two types of issues separately, leading to a more organized and informative diagnostic experience for users.

Highlights

• Diagnostic Separation: Introduced a clear distinction between compiler-generated diagnostics and linting diagnostics throughout the system.
• New Data Structure for Diagnostics: A new DiagnosticsResult struct was added to crates/tinymist-query/src/check.rs to encapsulate both compiler and lint diagnostics, replacing the previous single DiagnosticsMap response type.
• Editor Actor Refactoring: The EditorActor in crates/tinymist/src/actor/editor.rs was updated to handle diagnostics based on their DiagKind (Compiler or Lint), using a new DiagKey to manage diagnostics from different sources more granularly.
• Granular Diagnostic Publishing: The push_diagnostics and related methods in crates/tinymist/src/project.rs now explicitly specify the DiagKind when sending diagnostics to the editor, allowing for independent management and display of compiler and lint issues.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively separates compiler and lint diagnostics, which is a great improvement for clarity. The changes are well-implemented across the affected crates. I've provided a couple of suggestions to enhance the code further: one to improve performance by avoiding an unnecessary collection and another to increase maintainability by refactoring duplicated code.