-
-
Notifications
You must be signed in to change notification settings - Fork 390
Speed up hls-hlint-plugin-tests #4144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -125,6 +125,11 @@ import System.Environment (setEnv, | |
#endif | ||
import Development.IDE.Core.PluginUtils as PluginUtils | ||
import Text.Regex.TDFA.Text () | ||
import qualified Language.LSP.Protocol.Message as LSP | ||
import qualified Language.LSP.Server as LSP | ||
import GHC.TypeLits (KnownSymbol) | ||
import qualified Development.IDE.Types.Options as Options | ||
|
||
-- --------------------------------------------------------------------- | ||
|
||
data Log | ||
|
@@ -140,7 +145,7 @@ instance Pretty Log where | |
LogShake log -> pretty log | ||
LogApplying fp res -> "Applying hint(s) for" <+> viaShow fp <> ":" <+> viaShow res | ||
LogGeneratedIdeas fp ideas -> "Generated hlint ideas for for" <+> viaShow fp <> ":" <+> viaShow ideas | ||
LogUsingExtensions fp exts -> "Using extensions for " <+> viaShow fp <> ":" <+> pretty exts | ||
LogUsingExtensions fp exts -> "Using extensions for " <+> viaShow fp <> ":" <> line <> indent 4 (pretty exts) | ||
LogGetIdeas fp -> "Getting hlint ideas for " <+> viaShow fp | ||
LogResolve msg -> pretty msg | ||
|
||
|
@@ -189,12 +194,12 @@ instance NFData GetHlintDiagnostics | |
type instance RuleResult GetHlintDiagnostics = () | ||
|
||
-- | Hlint rules to generate file diagnostics based on hlint hints | ||
-- | This rule is recomputed when: | ||
-- | - A file has been edited via | ||
-- | - `getIdeas` -> `getParsedModule` in any case | ||
-- | - `getIdeas` -> `getFileContents` if the hls ghc does not match the hlint default ghc | ||
-- | - The client settings have changed, to honour the `hlintOn` setting, via `getClientConfigAction` | ||
-- | - The hlint specific settings have changed, via `getHlintSettingsRule` | ||
-- This rule is recomputed when: | ||
-- - A file has been edited via | ||
-- - `getIdeas` -> `getParsedModule` in any case | ||
-- - `getIdeas` -> `getFileContents` if the hls ghc does not match the hlint default ghc | ||
-- - The client settings have changed, to honour the `hlintOn` setting, via `getClientConfigAction` | ||
-- - The hlint specific settings have changed, via `getHlintSettingsRule` | ||
rules :: Recorder (WithPriority Log) -> PluginId -> Rules () | ||
rules recorder plugin = do | ||
define (cmapWithPrio LogShake recorder) $ \GetHlintDiagnostics file -> do | ||
|
@@ -208,8 +213,16 @@ rules recorder plugin = do | |
liftIO $ argsSettings flags | ||
|
||
action $ do | ||
files <- getFilesOfInterestUntracked | ||
void $ uses GetHlintDiagnostics $ Map.keys files | ||
files <- Map.keys <$> getFilesOfInterestUntracked | ||
Shake.ShakeExtras{ideTesting = Options.IdeTesting testing, lspEnv} <- Shake.getShakeExtras | ||
let signal :: KnownSymbol s => Proxy s -> Action () | ||
signal msg = when testing $ liftIO $ Shake.mRunLspT lspEnv $ | ||
LSP.sendNotification (LSP.SMethod_CustomMethod msg) $ | ||
toJSON $ map fromNormalizedFilePath files | ||
|
||
signal (Proxy @"kick/start/hlint") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we do this generically? Like, for every rule, send custom method notifications for starting and finishing? It seems like many (most?) tests want this sort of thing, just having a generic signal when rules start or finish would be quite handy. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think only diagnostic tests need it, but yeah, we can definitely generalise it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I support it, since we are already tracing the action any way, see There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could add a log handler that intercepts rule start/finish logs and sends the custom messages, like we do for sending |
||
void $ uses GetHlintDiagnostics files | ||
signal (Proxy @"kick/done/hlint") | ||
|
||
where | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it work if we are using the combination of
nonTrivialKickDone
andnonTrivialKickDone
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pardon, I think you wrote the same function twice 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, one of them is
nonTrivialKickStart
. But never mind, I think it won't work anyway.To make sure it works we would have to customize a signal for every rule. But It should only turned on if we enable it(Provide a switch as we did for ideTesting🤔), otherwise there would be too many rules being logged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't even need to change the method name, we could put the information about what rule it was in the method parameters.
Or we could just use
$/logTrace
, which we don't use at all at the moment and is maybe quite suited to this?