Re: the linters are killing me slowly

2022-02-10 Thread Norman Ramsey
 > 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? 

I *love* this idea!


Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: the linters are killing me slowly

2022-02-10 Thread Richard Eisenberg


> On Feb 10, 2022, at 3:25 AM, Sven Tennie  wrote:
> 
> 
> 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 could work. But my experience with the current linters is that local 
execution gives different results than the execution in CI. Somehow, the CI 
execution is clever enough to flag only new breakages (or breakages in files 
that have been touched, perhaps), whereas when I've run existing linters 
locally, I get a slew of reports that are unrelated to my work.

I suppose the same problem could come up if the linters are in the testsuite, 
though.

Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Where do I put the *definition* of a DFunId?

2022-02-10 Thread Erdi, Gergo via ghc-devs
PUBLIC


PUBLIC

Hi,

I'm trying to make a module out of thin air and register it to GHC so that 
other modules can import it. So far, I have had success with making a ModIface 
and a ModDetails, and then registering them using the following function:

registerModule :: (GhcMonad m) => ModIface -> ModDetails -> m ()
registerModule iface details = modifySession $ extendHpt . addModule
  where
mod_info = HomeModInfo iface details Nothing

mod = mi_module iface
modOrig = ModOrigin (Just True) [] [] True

addModule = modifyUnitState $ \us -> us
{ moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod 
modOrig) $ moduleNameProvidersMap us
}

extendHpt env = env
{ hsc_unit_env = let ue = hsc_unit_env env in ue
{ ue_hpt = hpt
}
}

  where
hpt = addToHpt (hsc_HPT env) (moduleName mod) mod_info


This worked when I was only _declaring_ functions and TyCons in these modules. 
However, now I would also like to add instances. And I'm hitting a problem 
here, because I don't know where to put the actual definitions of the instance. 
I'm completely lost here.

Here's what I'm doing in detail. First, I make a fresh DFunId from a fresh 
Unique:

let tag = occNameString . getDFunTyKey $ ty
occ = mkDFunOcc (occNameString (getOccName showClass) <> tag) False 
emptyOccSet
name = mkExternalName uniq mod occ loc
dfun = mkDictFunId name [] [] showClass [ty]

Then, I make a ClsInst that describes my instance:

return ClsInst
{ is_cls_nm = getName showClass
, is_tcs = [KnownTc $ getName tycon]
, is_dfun_name = getName dfun
, is_tvs = []
, is_cls = showClass
, is_tys = [ty]
, is_dfun = dfun
, is_flag = OverlapFlag (NoOverlap NoSourceText) False
, is_orphan = NotOrphan (getOccName $ getName tycon)
}

And then I add 'AnId dfun' to my ModDetails's type env in 'md_types',, add the 
instance to the 'md_insts', and fill the 'mi_decls' and 'mi_insts' of the 
ModIface accordingly. This gives me a ModIface/ModDetails pair just like before 
- but I never said what the definition of 'dfun' is!

When I try compiling a real source module that imports this synthetic module 
and tries to use the instance, it gets as far as the "Desugar (after 
optimization)" step, and then fails with:

ghc-mu-core-to-exp: panic! (the 'impossible' happened)
  GHC version 9.3.20211130:
lookupIdSubst

$fShowOrderPolicy
InScope {foo mapM_}
Call stack:
CallStack (from HasCallStack):
  callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in 
ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic
  pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in 
ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst


I'm not surprised that eventually it crashes and burns, because, again, I have 
only declared my DFunId ('$fShowOrderPolicy' in this case), but never defined 
it. Its definition would be a CoreExpr, right? So where would I put the pair of 
'(dfun, myCoreExprOfTheRightType)' for GHC to pick it up? Or is it the case 
that GHC would only need an 'Id's definition if it is trying to 
inline/specialize it, i.e. should I just attach the definition to the DFunId as 
an unfolding? Or is 'registerModule' already incomplete and it should put the 
'CoreProgram' of the module to somewhere deep in the GHC state?

Thanks,
Gergo

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, 
Standard Chartered Bank and their subsidiaries (the "Group"), information on 
the regulatory standards we adhere to and how it may affect you can be found in 
our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory 
Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and 
contains any market commentary, the market commentary has been prepared by the 
sales and/or trading desk of Standard Chartered Bank or its affiliate. It is 
not and does not constitute research material, independent research, 
recommendation or financial advice. Any market commentary is for information 
purpose only and shall not be relied on for any other purpose and is subject to 
the relevant disclaimers available at https: 
//www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains 
any research materials prepared by members of the team, the research material 
is for information 

Re: the linters are killing me slowly

2022-02-10 Thread Matthew Pickering
I think we could run the linters in the same step as the rest of the
builds. As long as  the hadrian-ghci job runs as the initial step to
weed out any obviously bad commits.

On Wed, Feb 9, 2022 at 7:15 PM Richard Eisenberg  wrote:
>
> Hi devs,
>
> Can we please, please not have the linters stop more useful output during CI? 
> Over the past few months, I've lost several days of productivity due to the 
> current design. Why several days? Because I typically end up with only 1.5-2 
> hours for GHC work in a day, and when I have to spend half of that recreating 
> test results (which, sometimes, don't work, especially if I use Hadrian, as 
> recommended), I often decide to prioritize other tasks that I have a more 
> reasonable chance of actually finishing.
>
> It was floated some time ago that "Draft" MRs could skip linters. But I 
> actually have a non-Draft MR now, and it failed the new Notes linter. (Why, 
> actually, is that even a separate pass? I thought there was a test case for 
> that, which I'm thrilled with.)
>
> It just feels to me that the current workflow is optimized for those of us 
> who work on GHC close to 100% of the time. This is not the way to get new 
> contributors.
>
> Frustrated,
> Richard
> ___
> 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: the linters are killing me slowly

2022-02-10 Thread Sven Tennie
Hi Richard,

Am Do., 10. Feb. 2022 um 04:29 Uhr schrieb Richard Eisenberg <
li...@richarde.dev>:

> [...]
>


> 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.)
>
> Would that satisfy our needs here?
>

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...
What "simple" means would of course have to be discussed, I would count at
least linters as simple and maybe ghc-in-ghci.

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.

Best regards,

Sven
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs