I've had some CI failures because of invalid Haddock comments. What
is the best way to detect such issues locally, early? I tried setting
environment variable GHC_FLAGS to "-Winvalid-haddock", which should
have told `./hadrian/ghci` to issue a warning. But for some reason,
no warning was
!5 on the Haddock mirror, and it's on the same branch as
GHC's !7442 (wip/backend-as-record). Do I need to do anything else to
get Gitlab to re-run CI on !7442? (As of 30 minutes ago, CI was
failing because Haddock would not compile.)
Norman
> Le 19/04/2022 à 19:28, Norman Ramsey a écrit :
GHC merge request !7442 changes the GHC API in a way that requires
a one-line change in `utils/haddock`. What should I do with this?
I can create an MR for the Haddock people, but I don't know how to
mark it as something that should be applied at exactly the same
time that Haddock transitions to
> Is there a way I can get Hadrian to build the documentation for
> just that module?
Here's more detail about what I'm facing. I'm trying to fine-tune the
Haddock documentation of a module that I intend to put into an MR for
GHC Central. This means I need to be able to re-run Haddock so I
I'm fine-tuning the Haddock documentation for just one module
that sits in the $GHC/compiler/GHC subtree. Is there a way I can
get Hadrian to build the documentation for just that module?
Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
Does anyone know why the continuations of CmmCall and CmmForeignCall
are not considered successors for the purpose of `mapSuccessors`?
Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
but I probably wouldn't
> > personally invest much energy in this direction.
> >
> > Richard
> >
> > > On Mar 22, 2022, at 2:10 PM, Norman Ramsey wrote:
> > >
> > > A blog post of lexi-lambda's recently put me onto Matt Noonan's
> >
A blog post of lexi-lambda's recently put me onto Matt Noonan's
technique "Ghosts of Departed Proofs" [1], which appeared in the 2018
Haskell Symposium. One example that intrigued me was a safe `Map`,
which uses the type system to guarantee that lookup does not fail.
Maps are used pretty
> It looks like this may be fall-out from !7511, presumably because lld
> apparently disallows text relocations by default. This is presumably
> Linux; which distribution are you using?
Debian 11 (bullseye).
I'll check out the MR you mentioned, and I'll open that ticket.
N
I recently pulled to bring my local copy of GHC HEAD up to
67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem
to get it to build.
I'm following these steps:
git pull --ff-only --prune --recurse-submodules --force
rm -r _build
./boot
./configure
./hadrian build -j
The
If I understand correctly, the way Hadrian works is that all of the
.conf files, binaries, and so on in _build/stage0 are built with the
bootstrap compiler. I need to write client code that uses the ghc
library built from GHC HEAD (so ghc-9.3), but I'd prefer to use the
bootstrap compiler. (The
> 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
I've been assigned a few merge requests to review on gitlab. One I've
completed and approved. One I've completed and have decided that
somebody else needs to approve it; I'm not qualified. Two I've not
yet started.
Is there any way to tell gitlab, "I'm done with these two"?
Norman
I have an MR currently under review. Review has already identified a
change I need to make, and I have made it in my local repository.
Do I push the change now, or do I wait for a more complete review?
And if I push it now, do I force-push or do I push the changes as a
separate commit?
Norman
Is there a way for me to run the GHC linter on my GHC source tree,
without having to push an MR out to CI?
Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > [Finding the locations of compiler errors after a change]
>
> This is the typical use case for a language server.
> I have haskell-language-server installed and use it extensively on GHC
> for stuff like jump to definition and immediate compilation feedback.
>
> There's also "jump to
> The Binary runGet issue usually means that your build tree is out of date.
> It's probably worth deleting and building from scratch again.
For those who may come after me: if ./hadrian/ghci barfs with a Binary
runGet issue, the build tree that needs to be deleted is
`.hadrian_ghci`, not
> The Binary runGet issue usually means that your build tree is out of date.
> It's probably worth deleting and building from scratch again.
Brilliant! Definitely working much better!
And @Sebastian I start to see the productivity gains. Remove all
redundant imports with one click!
Norman
> This is the typical use case for a language server.
> I have haskell-language-server installed and use it extensively on GHC
> for stuff like jump to definition and immediate compilation feedback.
I would *love* to be doing this. I have had HLS installed on my
machine for months, and have
> My recommendation: ./hadrian/ghci.
Richard, this suggestion has been so useful that I would like to
follow it up.
I'm about to change a type definition. This change may wreak havoc in
many parts of GHC, and this is exactly what I want: I'm looking for
type-error messages that will tell me
I've opened a very, very preliminary MR. The Commentary instructs me
to tag it "WIP: ", but gitlab seems to suggest that in order to
prevent it from being merged, I need "Draft: ". When a merge
request is both WIP and Draft, how should it be titled?
(The MR in question is
I was chatting with a colleague who asked "How big is GHC's run-time
system." In the spirit of "look and find out," I found this:
nr@homedog ~/.ghcup> ls -hl **HSrts.a
-rw-r--r-- 1 nr nr 8.7M Sep 27 16:13 ghc/8.10.7/lib/ghc-8.10.7/rts/libHSrts.a
-rw-r--r-- 1 nr nr 8.8M Sep 27 16:36
> My recommendation: ./hadrian/ghci. The first time you run it, it may spin
> for a little while, but it will eventually deliver you to a GHCi prompt,
> with all of GHC loaded. (You can e.g. `:type splitTyConApp_maybe`, after
> `import GHC.Core.Type`.) At that point, :reload will be your dear
I'm currently doing some refactoring of the GHC sources, which
involves moving definitions between modules. As a sanity check
I want to compile often, so if I've broken anything (or have inadvertently
created circular imports) I can find out quickly. I'm currently using
./hadrian/build -j
> > I'm trying to use the retrie refactoring tool..
> >
> For what it's worth, Norman has reported this issue upstream as
> https://github.com/facebookincubator/retrie/issues/41
Turns out the tool wants `=` in the rule, not `==`.
And if you have a ' in your function name, the tool barfs
I'm trying to use the retrie refactoring tool, but I'm getting a
mysterious error message:
nr@homedog ~/a/g/compiler [1]> retrie --adhoc "forall x . not
(backendNeedn'tLink x) == backendNeedsLink x"
parseAdhocs:1:80: error: parse error on input ‘#-}’
retrie: user error (parse
For testing purposes, I created the following Cmm program:
myswitch (bits32 n) {
switch [0 .. 4] n {
case 0, 1: { foreign "C" A(); }
case 2: { foreign "C" B(); }
case 4: { foreign "C" C(); }
default: { foreign "C" D(); }
}
return (666);
}
I find myself wanting to define instances of Semigroup (and Monoid)
in a file that also imports GHC.Utils.Outputable and its `<>` operation
on SDocs. At the moment I am dealing with the incompatibility by
hiding the Outputable version and instead of writing `s1 <> s2` I write
`hcat [s1, s2]`.
> Which I guess mostly depends on how much mileage we get out of the
> numbering... I rarely have lost sleep over the overhead of looking
> things up in IntMaps.
Thank you!! I found your analysis very helpful. I will stick with
the IntMaps until and unless things reach a stage where they
Reverse postorder numbering is a superpower for control-flow analysis
and other back-end things. For example,
- In a reducible flow graph, a node Q is a loop header if and only if
it is targeted by an edge P -> Q where Q's reverse postorder
number is not greater than P's.
- If a
> > I'm emitting code in which I want to prettyprint the contents
> > of a Cmm Block as a comment, by which I mean putting `--` to the left
> > of *each* line of the rendered Cmm Block. Using GHC.Utils.Outputable,
> > is this even possible? How would I tackle it? (The Haddock page
> > does
I'm emitting code in which I want to prettyprint the contents
of a Cmm Block as a comment, by which I mean putting `--` to the left
of *each* line of the rendered Cmm Block. Using GHC.Utils.Outputable,
is this even possible? How would I tackle it? (The Haddock page
does not suggest any obvious
> On a tip from Ben, I'm using Chrome to review a large patch (!7033 for the
> curious). It is qualitatively better than Firefox, my usual tool.
And to follow up from this morning, I fear that Magit is not going to
be useful as a tool for reviewing: it seems unable to access the
"conversation"
I'm trying to figure out how to persuade GHC to generate an
irreducible control-flow graph (so I can test an algorithm to convert
it to structured control flow).
The attached image shows (on the left) the classic simple irreducible
CFG: there is a loop between nodes A and B, but neither one
At present, Cmm dataflow analysis works only on Cmm code. I'd like
to do a dataflow analysis on native code. Details at
https://gitlab.haskell.org/ghc/ghc/-/issues/20725
where I'd love an extra set of eyes from the Cmm/Dataflow/Hoopl crowd.
Norman
> I'm struggling to figure out how to get from a CLabel found in a
> CmmProc to a Label used to key the blocks in the control-flow graph
> (CmmGraph) for the CmmProc.
I figured it out---this is the wrong problem. I need to take the
`g_entry` BlockId straight out of the CmmGraph.
Norman
I'm struggling to figure out how to get from a CLabel found in a
CmmProc to a Label used to key the blocks in the control-flow graph
(CmmGraph) for the CmmProc. The code generator needs such a function,
so it must be around somewhere, but I have not yet found it.
I've poked around the
one
can suggest another idea?
Is there a command-line option to Hadrian that will get it to show
every external command ("builder"?) as it is executed?
Norman
> Le 18/11/2021 à 21:06, Norman Ramsey a écrit :
> > In service of #20528, I'm trying to clean up some Haddock
> > docum
In service of #20528, I'm trying to clean up some Haddock
documentation in the GHC sources. The only command I know is
./hadrian/build -j _build/docs/html/index.html
It turns out that if I change Haddock comments in one file
(GHC/Tc/Gen/Foreign.hs), rebuilding the HTML takes a minute
and a
I'd like it to be easier to extend GHC with support for new species of
foreign calls. Existing support makes it easy to *replace* GHC's
implementation of foreign calls but not to *extend* it.
Details in #20693 (https://gitlab.haskell.org/ghc/ghc/-/issues/20693).
I'd welcome comments, especially
> Looking at the code, it seems like it does return an actual `Linkable`
> when we are in interpreted mode:
Oy. I don't know how I missed that. Thanks.
Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
All,
It appears that `runHscBackendPhase` returns a tuple that include an
element of type `Maybe Linkable` but that in practice is always
`Nothing`. I'm thinking of removing this element from the tuple,
which would also entail simplifying the type of value constructor
`T_HscBackend` for the
> Norman Ramsey writes:
>
> > On x86, GHC can translate 8-bit and 16-bit operations directly
> > into the 8-bit and 16-bit machine instructions that the hardware
> > supports. But there are other platforms on which the smallest
> > unit of arithm
On x86, GHC can translate 8-bit and 16-bit operations directly
into the 8-bit and 16-bit machine instructions that the hardware
supports. But there are other platforms on which the smallest
unit of arithmetic may be 32 or even 64 bits. Is there a central
module in GHC that can take care of
> Norman Ramsey writes:
>
> > What is the Hadrian equivalent of
> >
> > make show VALUE=BOOT_PKGS
> >
> I don't believe there is currently a command-line equivalent. The list
> itself is known as Settings.Default.stage0Packages.
>
&
I'm trawling the GHC wiki looking for things that will help
me understand how the build system works and what might need
to change for cross-compilation. I stumbled across
https://gitlab.haskell.org/ghc/ghc/-/wikis/design/build-system
which git helpfully tells me dates from 2008. I assume that
What is the Hadrian equivalent of
make show VALUE=BOOT_PKGS
?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Perhaps it would be too niche of a resource, but what about collecting
> these options either in a Wiki page in GHC
In the interests of "done now is better than perfect later," I have
added a note about these options to
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian.
This is
> As I refresh my memory about Cmm, I'm thinking of converting the
> existing comments to Haddock comments. The only downside I can think
> of is that the Haddock pages may appear more cluttered.
> Is there any reason I should refrain?
After sending email, I realized that I should make an
The definitions of the Cmm data structures are richly commented in
the source code, but the comments are not Haddock comments, so the
information doesn't make it into the Haddock documentation.
As I refresh my memory about Cmm, I'm thinking of converting the
existing comments to Haddock comments.
All,
I'm looking at the paragraph starting on line 271 of GHC.StgToCmm.Monad,
which purports to explain ReturnKind. But the labels mentioned in the
paragraph don't seem to match the preceding code example. Also, I don't
understand why only one branch of the `case` expression seems to
be
> Unfortunately yesterday gitlab.haskell.org yet again ran out of disk
> space. It is currently being migrated to another machine and in the
> meantime things may be a bit flaky. Many apologies for the
> inconvenience. More updates will be coming as the situation develops.
I see that gitlab
I spent the afternoon spelunking through some code and the Commentary,
and I'm wondering how a CAF becomes unreachable. I gather it might
have to do with GHC floating a static expression out of a context
until it becomes a CAF, but I'm still not seeing how a CAF could
at one point be reachable,
> In general #haskell-language-server on libera is a good place to
> ask these questions.
Can you recommend an IRC client? I tried using the web-based client,
got limited response, and then the client destroyed all history.
> > - When a project is compiled against a Stage 1 `base`
Where is the place to go to talk details of the Haskell Language Server?
I'm using the HLS with the GHC I have compiled from HEAD, and I am
sitting on a number of difficulties:
- When a project is compiled against a Stage 1 `base` library (as
opposed to the one shipped with the bootstrap
> Speaking for myself: I have not validated locally for quite a while. I just
> rely on CI.
I've confirmed that a fresh checkout doesn't validate. Is anyone else
willing to try? If it's a problem that only I have, I'm reluctant to
open an issue.
> You can mark an MR as a "Draft" to avoid
I've made a minor change to GHC, and before submitting a PR, I'd like to
validate the change. But I don't really know how to interpret the output
of the `validate` script. Mine runs for about 40 minutes and then ends
in an error:
# We are installing wrappers to programs by searching
Type StgOp and its constructors are exported from module
GHC.Stg.Syntax. But the prettyprinting function pprStgOp is not
exported. I'm thinking of exporting the function and also
of defining an instance of Outputable. Is there any reason not to?
If this sounds OK to people, I'll make a PR.
> The code worked in the 9.0 API, but using the 9.3 API causes a panic:
>
> sandbox: panic! (the 'impossible' happened)
> GHC version 9.3.20210918:
> unsafeGetHomeUnit: No home unit
SOLVED: I was getting an `HscEnv` by using `newHscEnv` with a `DynFlags`.
Turns out I'm not
> > 1. If my bootstrap compiler changes (e.g., from 8.10.5 to 9.0.1), is
> > Hadrian smart enough to rebuild everything? If not, how do I
> > force it to start over?
>
> (1), I would hope so. If not, that's a bug.
I have confirmed that when the bootstrap compiler changes, Hadrian
I've traced some troubles to a problem with GHC's response
to the -clear-package-db and -package-db flags. I would very much
like to know if others can duplicate this issue.
All that is needed is for you to try the following commands, or
whatever variations may be appropriate for whatever ghc
Followup: I managed to get things configured to work with `cabal v2-build`,
and with this build, the app dumps STG code as expected. I am
unblocked!
Norman
> nr@homedog ~/a/sandbox> cabal v1-build
> Resolving dependencies...
> Configuring sandbox-0.1.0.0...
> Preprocessing
All,
I tried Alfredo's suggestion of building with the stage1 compiler.
(Sticking with the bootstrap compiler for HLS support, which seems
to be working OK.) I've gotten a bit further.
I have a small app that loads .hs files, translates to STG,
and dumps the results. It also dumps the
.
> ```
>
> As you can see that's exactly what you are doing, modulo the fact I was
> using the `stage1` (where _build is the default directory for Hadrian
> builds).
>
> Hope this helps in some way!
>
> A.
>
>
>
>
> On Fri, 24 Sept 202
> I suspect that the stages are getting mixed up here. Would it be
> possible to post a full reproducer?
I think so. I'm thinking a source tree for my client, plus step-by-step
instructions. Would that do the job?
Norman
___
ghc-devs mailing list
> in addition to what Ben already said: is there any particular reason you
> wanted to use the stage0 compiler?
Yes! I want to use the Haskell Language Server with my code. I am
given to understand that HLS does not work with GHC HEAD, so if I want
to use HLS with my own code, it needs to be
> Hi Norman,
>
> I think you are overcomplicating things quite a bit.
>
> 1. Build a HEAD (9.3) compiler
> 2. Setup a normal cabal project to depend on the `ghc` library
> 3. Use the cabal -w option to point to your HEAD compiler to build the
> project (`cabal build -w /path/to/head`)
>
I'm writing client code against the GHC API in HEAD (version 9.3),
using 9.0.1 as my bootstrap compiler. To make it possible to build
this code, I've set up cabal using
cabal v1-configure \
--package-db clear \
--package-db $STAGE0/lib/package.conf.d/ # stage0 libraries
In
I've got two questions about building:
1. If my bootstrap compiler changes (e.g., from 8.10.5 to 9.0.1), is
Hadrian smart enough to rebuild everything? If not, how do I
force it to start over?
2. At the moment I'm not installing my GHC; I'm using elements
directly from the build
69 matches
Mail list logo
