Re: HLint in the GHC CI, an eight-months retrospective
Hi Richard, I am sorry, I have indeed forgotten one of the most important parts of my email. :) The Hadrian rules are lint:base lint:compiler You can invoke them as simply as: ./hadrian/build lint:base You need to have a recent version of HLint in your PATH. If you use ghc.nix, this should be taken care of for you. Hope it clarified things! Cheers, Hécate Le 25 mars 2021 21:39:15 Richard Eisenberg a écrit : Thanks for this update! Glad to know this effort is going well. One quick question: suppose I am editing something in `base`. My understanding is that my edit will be linted. How can I run hlint locally so that I can easily respond to trouble before CI takes a crack? And where would I learn this information (that is, how to run hlint locally)? Thanks! Richard On Mar 25, 2021, at 11:19 AM, Hécate wrote: Hello fellow devs, this email is an activity report on the integration of the HLint[0] tool in the Continuous Integration (CI) pipelines. On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code linting in the several components of the GHC code-base. It has served as a reference anchor for the Merge Requests (MR) that stemmed from it, and allowed us to refine our expectations and processes. If you are not acquainted with its content, I invite you to read the whole conversation. Subsequently, several Hadrian lint rules have been integrated in the following months, in order to run HLint on targeted components of the GHC repository (the base library, the compiler code-base, etc). Being satisfied with the state of the rules we applied to the code-base, such as removing extraneous pragmata and keywords, it was decided to integrate the base library linting rule in the CI. This was five months ago, in September[2], and I am happy to report that developer friction has been so far minimal. In parallel to this work on the base library, I took care of cleaning-up the compiler, and harmonised the various micro coding styles that have emerged quite organically during the decades of development that are behind us (I never realised how many variations of the same ten lines of pragmata could coexist in the same folders). Upon feedback from stakeholders of this sub-code base, the rules file was altered to better suit their development needs, such as not removing extraneous `do` keywords, as they are useful to introduce a block in which debug statements can be easily inserted. Since today, the linting of the compiler code-base has been integrated in our CI pipelines, without further burdening our CI times. Things seem to run smoothly, and I welcome comments and requests of any kind related to this area of our code quality process. Regarding our future plans, there has been a discussion about integrating such a linting mechanism for our C code-base, in the RTS. Nothing is formally established yet, so I would be grateful if people who have experience and wisdom about it can chime in to contribute to the discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/19437. And I would like to say that I am overall very thankful for the involvement of the people who have been giving us feedback and have been reviewing the resulting MRs. Have a very nice day, Hécate --- [0]: https://github.com/ndmitchell/hlint [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424 [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147 -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HLint in the GHC CI, an eight-months retrospective
Thanks for this update! Glad to know this effort is going well. One quick question: suppose I am editing something in `base`. My understanding is that my edit will be linted. How can I run hlint locally so that I can easily respond to trouble before CI takes a crack? And where would I learn this information (that is, how to run hlint locally)? Thanks! Richard > On Mar 25, 2021, at 11:19 AM, Hécate wrote: > > Hello fellow devs, > > this email is an activity report on the integration of the HLint[0] tool in > the Continuous Integration (CI) pipelines. > > On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code linting > in the several components of the GHC code-base. It has served as a reference > anchor for the Merge Requests (MR) that stemmed from it, and allowed us to > refine our expectations and processes. If you are not acquainted with its > content, I invite you to read the whole conversation. > > Subsequently, several Hadrian lint rules have been integrated in the > following months, in order to run HLint on targeted components of the GHC > repository (the base library, the compiler code-base, etc). > Being satisfied with the state of the rules we applied to the code-base, such > as removing extraneous pragmata and keywords, it was decided to integrate the > base library linting rule in the CI. This was five months ago, in > September[2], and I am happy to report that developer friction has been so > far minimal. > In parallel to this work on the base library, I took care of cleaning-up the > compiler, and harmonised the various micro coding styles that have emerged > quite organically during the decades of development that are behind us (I > never realised how many variations of the same ten lines of pragmata could > coexist in the same folders). > Upon feedback from stakeholders of this sub-code base, the rules file was > altered to better suit their development needs, such as not removing > extraneous `do` keywords, as they are useful to introduce a block in which > debug statements can be easily inserted. > > Since today, the linting of the compiler code-base has been integrated in our > CI pipelines, without further burdening our CI times. > Things seem to run smoothly, and I welcome comments and requests of any kind > related to this area of our code quality process. > > Regarding our future plans, there has been a discussion about integrating > such a linting mechanism for our C code-base, in the RTS. Nothing is formally > established yet, so I would be grateful if people who have experience and > wisdom about it can chime in to contribute to the discussion: > https://gitlab.haskell.org/ghc/ghc/-/issues/19437. > > And I would like to say that I am overall very thankful for the involvement > of the people who have been giving us feedback and have been reviewing the > resulting MRs. > > Have a very nice day, > Hécate > > --- > [0]: https://github.com/ndmitchell/hlint > [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424 > [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147 > > -- > Hécate ✨ > : @TechnoEmpress > IRC: Uniaika > WWW: https://glitchbra.in > RUN: BSD > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
HLint in the GHC CI, an eight-months retrospective
Hello fellow devs, this email is an activity report on the integration of the HLint[0] tool in the Continuous Integration (CI) pipelines. On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code linting in the several components of the GHC code-base. It has served as a reference anchor for the Merge Requests (MR) that stemmed from it, and allowed us to refine our expectations and processes. If you are not acquainted with its content, I invite you to read the whole conversation. Subsequently, several Hadrian lint rules have been integrated in the following months, in order to run HLint on targeted components of the GHC repository (the base library, the compiler code-base, etc). Being satisfied with the state of the rules we applied to the code-base, such as removing extraneous pragmata and keywords, it was decided to integrate the base library linting rule in the CI. This was five months ago, in September[2], and I am happy to report that developer friction has been so far minimal. In parallel to this work on the base library, I took care of cleaning-up the compiler, and harmonised the various micro coding styles that have emerged quite organically during the decades of development that are behind us (I never realised how many variations of the same ten lines of pragmata could coexist in the same folders). Upon feedback from stakeholders of this sub-code base, the rules file was altered to better suit their development needs, such as not removing extraneous `do` keywords, as they are useful to introduce a block in which debug statements can be easily inserted. Since today, the linting of the compiler code-base has been integrated in our CI pipelines, without further burdening our CI times. Things seem to run smoothly, and I welcome comments and requests of any kind related to this area of our code quality process. Regarding our future plans, there has been a discussion about integrating such a linting mechanism for our C code-base, in the RTS. Nothing is formally established yet, so I would be grateful if people who have experience and wisdom about it can chime in to contribute to the discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/19437. And I would like to say that I am overall very thankful for the involvement of the people who have been giving us feedback and have been reviewing the resulting MRs. Have a very nice day, Hécate --- [0]: https://github.com/ndmitchell/hlint [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424 [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147 -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
