- ghc-devs - Haskell.org

"Extensible interface files" work and ANN pragmas
by Ömer Sinan Ağacan 23 Apr '20

23 Apr '20

The "extensible interface files" [1, 2] work has been discussed at GHC calls a few times and the conclusion was we were going to document why current annotation mechanism (ANN pragmas) are insufficient and we need yet another way to put stuff into interfaces. Unfortunately the MR was merged before that's done and so it's currently undocumented and it's still unclear what's insufficient about ANN pragmas or how the new mechanism differs. I'm currently working on an interface files related patch (#16885) so I have to maintain both of these features now. It'd be good to know why both is necessary. If ANN is no longer useful or needed could we deprecate it in favor of the new mechanism and remove it in a few releases? That's help maintaining the code in the future. Could people involved in this design and patch please document the thought process here? Thanks, Ömer [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2948 [2]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Extensible-Interface-Files

3 2

GHC documentation outdated
by Wolfgang Jeltsch 20 Apr '20

20 Apr '20

Hi! the URL https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html seems to still point to the GHC 8.8.3 documentation. All the best, Wolfgang

3 3

T13456
by Simon Peyton Jones 20 Apr '20

20 Apr '20

I'm getting this failure (below) from validate fairly consistently. It is often silenced by adding an empty file ghci/should_run/T13456.stderr But it's troubling. Does anyone else see this? How can I debug it? Thanks Simon Framework failures: /tmp/ghctest-31oxzmog/test spaces/ghci/should_run/T13456.run T13456 [Traceback (most recent call last): File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 996, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1094, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1213, in ghci_script return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1638, in simple_run stderr=read_stderr(name), File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1808, in read_stderr return in_testdir(name, 'run.stderr').read_text(encoding='UTF-8') File "/usr/lib/python3.6/pathlib.py", line 1196, in read_text with self.open(mode='r', encoding=encoding, errors=errors) as f: File "/usr/lib/python3.6/pathlib.py", line 1183, in open opener=self._opener) File "/usr/lib/python3.6/pathlib.py", line 1037, in _opener return self._accessor.open(self, flags, mode) File "/usr/lib/python3.6/pathlib.py", line 387, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/ghctest-31oxzmog/test spaces/ghci/should_run/T13456.run/T13456.run.stderr' ] (ghci)

2 1

Object unloading confusion
by Ömer Sinan Ağacan 16 Apr '20

16 Apr '20

Hi Simon, I'm looking at object unloading code in CheckUnload.c. My understanding of how unloading works is: - When unloading of an object is requested the object is added to `unloaded_objects`. - When `unloaded_objects` is not empty, after GC, we scan the heap for any references to objects. This is done in `searchHeapBlocks` called by `checkUnload`. - When `searchHeapBlocks` finds a reference to an object code it marks the object code. - After scanning the heap any objects in `unloaded_objects` that are not marked are unloaded. Does this sound right so far? What I'm confused about is `searchHeapBlocks`. As far as I can see it just skips all objects other than stacks. For example here's the code for scanning a constructor: case CONSTR: case CONSTR_NOCAF: case CONSTR_1_0: case CONSTR_0_1: case CONSTR_1_1: case CONSTR_0_2: case CONSTR_2_0: size = sizeW_fromITBL(info); break; So if I see a constructor with a reference to an object code in its payload I'll not mark the object code. This looks wrong to me. I don't understand why we only care about stacks and nothing else. Could you comment on this? Thanks, Ömer

2 2

T13456
by Simon Peyton Jones 16 Apr '20

16 Apr '20

Ben, Omer I find that when running the testsuite, I get the garbage below, for ghci/should_run/T13456. Adding an empty file T13456.stderr seems to fix it in one of my trees, but not in another. Very strange. Any ideas? Simon Framework failures: T13456.run T13456 [Traceback (most recent call last): File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 996, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1094, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1213, in ghci_script return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1638, in simple_run stderr=read_stderr(name), File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1808, in read_stderr return in_testdir(name, 'run.stderr').read_text(encoding='UTF-8') File "/usr/lib/python3.6/pathlib.py", line 1196, in read_text with self.open(mode='r', encoding=encoding, errors=errors) as f: File "/usr/lib/python3.6/pathlib.py", line 1183, in open opener=self._opener) File "/usr/lib/python3.6/pathlib.py", line 1037, in _opener return self._accessor.open(self, flags, mode) File "/usr/lib/python3.6/pathlib.py", line 387, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [Errno 2] No such file or directory: 'T13456.run/T13456.run.stderr' ] (ghci)

1 0

TcTypeNats
by Simon Peyton Jones 14 Apr '20

14 Apr '20

Sylvain TcTypeNats still exists in compiler/typecheck/ An omission? Simon

2 1

HsTick and HsBinTick
by Simon Peyton Jones 14 Apr '20

14 Apr '20

Friends I think HsTick and HsBinTick are added (only) by GHC.HsToCore.Coverage So I think the cannot occur in HsExpr GhcPs or HcExpr GhcRn If so we should change the data type decl to say this explicitly. Can anyone confirm or deny and add a ticket if so? Simon

3 2

scavenge_one failures on BCO objects
by chessai . 10 Apr '20

10 Apr '20

Hi devs, A coworker is experiencing sporadic failures when reloading our project in GHCi, with ``` ghc: internal error: scavenge_one: strange object 23 (GHC version 8.6.5 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: repl failed for mercury-web-backend-0.0.0. The build process terminated with exit code -6 ``` upon a quick inspection it seems that scavenge_one inspects the type of the object, but has no case for BCO (which is 23). I'm guessing there's something weird going on here since this doesn't happen deterministically. I don't have a good intuition for how this scavenging should work for BCO's, or if it should even be possible for BCO's to appear here (i.e. this is a symptom of some other bug). Any thoughts? Thanks

2 1

hadrian.settings recipes
by Ben Gamari 10 Apr '20

10 Apr '20

Hi everyone, As you may know, Hadrian's analogue to the make build system's mk/build.mk is hadrian.settings file. While the new mechanism is quite flexible, I often find myself having to look up recipes from previous builds to accomplish common tasks. To try to improve this situation I've started collecting the snippets I need most often on the Wiki [1]. I would invite anyone else who has something to add to do so. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#hadriansettings

1 0

Safe primops
by Simon Peyton Jones 09 Apr '20

09 Apr '20

Andreas, Simon, and other back-end-knowledgeable devs Can I draw your attention to this question? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3011#note_264584 It's about identifying which primops execute in-line without GC, and without thread-switching. Thanks Simon

1 0