<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Richard,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 10. Feb. 2022 um 04:29 Uhr schrieb Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>[...]<br></div></blockquote><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>I
 do think there is a very happy resolution to all of this: put these 
lint checks in the testsuite. I believe that was Matthew's idea in 
yesterday's call, and I think that solves the problem very nicely. 
Errors get reported concurrently with other errors, a contributor can 
run the checks locally, and it seems possible to get the linters 
runnable even without a built GHC. (For example, even if the testsuite 
requires building GHC, the lint tests can call some lint-ghc script. 
But, of course, contributors can call lint-ghc directly, too.)</div><div><br></div><div>Would that satisfy our needs here?</div></div></blockquote><div><br></div></span><div>What
 do you think about the idea of having a Hadrian target ready-for-ci (or
 something like this) that would run all simple checks? That target 
should be executed before you push your changes. Of course, no one would
 force you to do so, but that way you could exchange local CPU cycles 
for CI waiting time... <br></div><div>What "simple" means would of course have to be discussed, I would count at least linters as simple and maybe ghc-in-ghci.<br></div><div><br></div><div>This
 idea is very similar to putting the linters into the testsuite. The 
difference is mainly the place where the checks are implemented and the 
UX.<br></div><div><br></div><div>Best regards,</div><div><br></div><div>Sven</div></div></div></div>