- ghc-devs - Haskell.org

Understanding the restrictions on instance head shapes
by Amélia Liao 26 Feb '24

26 Feb '24

Dear ghc-devs, Prompted by a toot by Conor McBride [1], I got sent on a rabbit-chase down the hole that are the restrictions on instance head shapes. Re-assembling the relevant parts, Conor's trouble arises from code of the form data Nat data CdB (p :: Nat -> *) (m :: Nat) :: * where type Shown (p :: Nat -> *) = forall n. Show (p n) instance Shown p => Shown (CdB p) where show = ... After some shallow investigation, a similar issue came up as #13267, whose fix adds a note mentioning that the "show is not a method" error pops up in the renamer, and so is a bit tricky to improve. However, even after expanding Conor's type synonyms, the type checker now complains that an instance head can not have a forall. I do understand the reasons behind forbidding 'forall's in instance heads, but I don't see a good reason to forbid instances headed by a type synonym --- the original concern, writing an instance for a constraint tuple, is (now) forbidden regardless of whether 'checkValidInstance' uses 'splitTyConApp_maybe', by the call to 'checkValidInstanceHead'. Would a patch allowing instances headed by a type synonym be welcome, or would this need to go through a proposal? I think that it would be mostly straightforward, though laborious, to implement this; Essentially, changing 'rnMethodBinds' to annotate method bindings with a set of /all possible/ method 'Name's that match what the user wrote, together with their classes, and only deciding on the actual 'Name' in 'tcMethods', where we know the actual class name for the instance head. If this work would be welcome, I'd appreciate some pointers on dealing with TTG before I write a massive pull request that wastes everyone's time. In particular, my immediate thought for storing the extra information needed is to change the type of 'cid_binds' for 'ClsInstDecl' in *'GhcRn' only*, but trying this out locally causes quite a bit of breakage. It might make more sense to add a 'MethodBind' constructor to 'HsBindLR' which is inserted by the renamer, like 'VarBind', and removed by the type checker; but this /also/ requires quite a bit of code motion. I'm happy to open an issue on GitLab if discussing possible implementation ideas would be easier over there. Of course, simply allowing instances headed by a type synonym wouldn't fix Conor's original example, since having 'forall' in an instance head would still be forbidden. It's my understanding that the reason those are forbidden is due to nasty interactions with ScopedTypeVariables, where instance forall a. C a => forall b. D a b where brings 'b' into scope in the methods' RHSes, whereas the RHS of a top-level function with the same signature would /not/ have 'b' in scope. But given that a higher-ranked type synonym would not bring the variables it quantifies over into scope /anyway/, is there a reason to forbid it then? Cheers, Amélia [1]: https://types.pl/@pigworker/111975161248256507

2 1

Modifying the "StgHeader" struct
by Adithya Kumar 26 Feb '24

26 Feb '24

Hello, I want to add a field for collecting information about the number of GCs a particular heap object survived. I've done the following to implement this: - Add a field "StgWord gc_id" to struct "StgHeader" and "StgThunkHeader" - Update "SET_HDR" macro in "ClosureMacros.h" to update the "gc_id" - Update the "closureTypeHeaderSize" function in "Heap/ClosureTypes.hs" to account for that 1 extra word. Compilation leads to a segmentation fault. The stage 2 compiler is built. But usage of it leads to a segmentation fault. Build output: ``` chmod +x inplace/bin/ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -hide-all-packages -package-env - -i -iutils/check-api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils/check-api-annotations/dist-install/build -iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -Iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -optP-include -optPutils/check-api-annotations/dist-install/build/check-api-annotations/autogen/cabal_macros.h -package-id Cabal-3.2.1.0 -package-id base-4.14.3.0 -package-id containers-0.6.5.1 -package-id directory-1.3.6.0 -package-id ghc-8.10.7.20240224 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir utils/check-api-annotations/dist-install/build -c utils/check-api-annotations/./Main.hs -o utils/check-api-annotations/dist-install/build/Main.dyn_o utils/check-api-annotations/ghc.mk:18: recipe for target 'utils/check-api-annotations/dist-install/build/Main.dyn_o' failed make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Segmentation fault (core dumped) Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 ``` Is there any other place I've missed follow-up modifications? I appreciate any help provided. Best, Adithya

4 4

Gitlab Account
by Eli F-F 24 Feb '24

24 Feb '24

Hello! I'm requesting my account be approved. I put my username down as HexTheDragon Eli F-F

2 1

[ANNOUNCE] GHC 9.8.2 is now available
by Zubin Duggal 23 Feb '24

23 Feb '24

The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_8_2.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html This release is primarily a bugfix release addressing many issues found in the 9.8 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083) * Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370) * Fixes for some memory leaks in GHCi (#24107, #24118) * Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778) * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * And many more fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html

1 0

Diagnosing excessive memory usage / crash when compiling - 9.8.1
by Justin Bailey 22 Feb '24

22 Feb '24

Hi! I'm trying to upgrade our (large) codebase to use 9.8.1. (I'm on an M2). When building with -01, memory on the GHC process climbs until it reaches the limit of my machine (64G) and then crashes with a segfault. With -00, that does not happen. How would I go about diagnosing what's happening? Using RTS flags to limit the heap to 32G produced the same behavior, just faster. Strangely, `-v5` does not produce any more output in the console (passed via cabal's --ghc-options). Maybe I'm doing it wrong? Pointers to existing issues or documentation welcome! Thank you! Justin

5 8

Who is in charge for approve the gitlab.haskell.org registration request?
by Evan Greenup 19 Feb '24

19 Feb '24

I have successfully signed up for a <gitlab.haskell.org> account for code contribution and bug report. But when I try to login with this account, it said that my account need to be approved by administrator of this GitLab instance. How can I get in touch with this administrator. And what procedures do I need to take to get my account be approved?

2 1

git rerere considered helpful
by Norman Ramsey 18 Feb '24

18 Feb '24

Today I learned that git has a feature that will replay resolutions of conflicts you've already resolved in a previous merge or rebase. When I was working on GHC and frequently rebasing on master, I would have killed for this feature. https://git-scm.com/book/en/v2/Git-Tools-Rerere Norman

1 0

Trouble with package imports
by Matthías Páll Gissurarson 09 Feb '24

09 Feb '24

Hey all! I’m in the process of updating PropR from 8.10 to 9.8, which uses the GHC API extensively. Before, I could simply add a package to DynFlags, then setSessionDynFlags and the packages would be recognized and imported, provided I had `cabal install --lib <package>` before. However, after the update, it doesn’t seem to find packages, even when I manually point the package database to one with the package in question! Is there some additional loading that must be done? The package is picked up in GHCi and normal compilation, but not from within `runGhc` in the API. I’m using GHC via ghcup if that’s relevant. Thanks for any pointers you can provide! Best regards, Matthías Páll Gissurarson.

1 0

HEAD breakage
by Simon Peyton Jones 08 Feb '24

08 Feb '24

I have rebased a patch onto HEAD, and I'm getting this Reading interface for ghc-internal:GHC.Exception.Type; reason: Need decl for SomeException ...not found updating EPS /home/simonpj/code/HEAD-12/_build/stage1/inplace/../libraries/ghc-internal/build/GHC/Err.hi Declaration for errorWithoutStackTrace Unfolding of errorWithoutStackTrace: SomeException ErrorWithoutFlag Failed to load interface for ‘GHC.Exception.Type’. There are files missing in the ‘ghc-internal-0.1.0.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. forkM failed: Unfolding of errorWithoutStackTrace IOEnv failure } ending fork (badly) Unfolding of errorWithoutStackTrace Cannot continue after interface file error Does anyone have any idea what is going on? I have made no changes to GHC.Err or exceptions etc. Thanks Simon

2 1

Re: Help implementing Multiline String Literals
by Matthew Pickering 08 Feb '24

08 Feb '24

1. Push a branch to the haddock repo https://gitlab.haskell.org/ghc/haddock 2. Update the submodule on your tree to point to this branch < work on your patch > When it is time to merge. 3. Rebase your haddock branch onto ghc-head 4. Modify your GHC patch to point to this branch in the haddock submodule 5. Make sure CI passes, when it does, assign to marge both AND fast-forward merge your haddock patch into ghc-head (it is important this is atomic) If you do things this way you don't need to rebase your patch after merging your changes into the haddock ghc-head branch. On Thu, Feb 8, 2024 at 4:04 PM Brandon Chinn <brandonchinn178(a)gmail.com> wrote: > > hm okay, thanks. I'll try combining both approaches: modify the lexer (to handle escape characters correctly), but also put multiline strings in a separate HsLit constructor. > > Followup question: when I did this before, I added ITmultilinestring to the lexer, but then I had to add it to haddock-api as well. How do I merge the change in both the ghc repo and the haddock repo and change them both at the same time? I don't see how I can make either change first without a compiler error. > > On Thu, Feb 8, 2024, 7:55 AM Matthew Pickering <matthewtpickering(a)gmail.com> wrote: >> >> I don't think that is the right way to go. >> >> They are different syntactic forms so they should be distinguished in >> the syntax tree. >> >> If I want to generate HsSyn directly, and print it out, how does the >> compiler know whether I meant to print a normal string literal or a >> multi line string literal? What about if the compiler tries to print >> out an expression containing a string literal in an error message, >> multi or normal? >> >> Matt >> >> On Thu, Feb 8, 2024 at 3:35 PM Brandon Chinn <brandonchinn178(a)gmail.com> wrote: >> > >> > Thanks Sebastian and Matt! >> > >> > Matt - can you elaborate, I don't understand your comment. A multiline string is just syntax sugar for a normal string, so if the lexer does the post processing, it can be treated as a normal string the rest of the way. Why does anything else in the compiler need to know if the string was written as a multiline string? >> > >> > Or, to rephrase, a multiline string _should_ be semantically indistinguishable from a normal string with \n characters typed in. >> > >> > On Thu, Feb 8, 2024, 7:09 AM Matthew Pickering <matthewtpickering(a)gmail.com> wrote: >> >> >> >> I would imagine you modify the lexer like you describe, but it's not >> >> clear to me you want to use the same constructor `HsString` to >> >> represent them all the way through the compiler. >> >> >> >> If you reuse HsString then how to you distinguish between a string >> >> which contains a newline and a multi-line string for example? It just >> >> seems simpler to me to explicitly represent a multi-line string.. >> >> perhaps `HsMultiLineString [String]` rather than trying to shoehorn >> >> them together and run into subtle bugs like this. >> >> >> >> Matt >> >> >> >> On Thu, Feb 8, 2024 at 2:45 PM Sebastian Graf <sgraf1337(a)gmail.com> wrote: >> >> > >> >> > Hi Brandon, >> >> > >> >> > I'm not following all of the details here, but from my naïve understanding, I would definitely tweak the lexer, do the post-processing and then have a canonical string representation rather than waiting until desugaring. >> >> > If you like 1.4 best, give it a try. You will seen soon enough if some performance regression test gets worse. It can't hurt to write a few yourself either. >> >> > I don't think that post-processing the strings would incur too much a hit compared to compiling those strings and serialise them into an executable. >> >> > I also bet that you can get rid some of the performance problems with list fusion. >> >> > >> >> > Cheers, >> >> > Sebastian >> >> > >> >> > ------ Originalnachricht ------ >> >> > Von: "Brandon Chinn" <brandonchinn178(a)gmail.com> >> >> > An: ghc-devs(a)haskell.org >> >> > Gesendet: 04.02.2024 19:24:19 >> >> > Betreff: Help implementing Multiline String Literals >> >> > >> >> > Hello! >> >> > >> >> > I'm trying to implement #24390, which implements the multiline string literals proposal (existing work done in wip/multiline-strings). I originally suggested adding HsMultilineString to HsLit and translating it to HsString in renaming, then Matthew Pickering suggested I translate it in desugaring instead. I tried going down this approach, but I'm running into two main issues: Escaped characters and Overloaded strings. >> >> > >> >> > Apologies in advance for a long email. TL;DR - The best implementation I could think of involves a complete rewrite of how strings are lexed and modifying HsString instead of adding a new HsMultilineString constructor. If this is absolutely crazy talk, please dissuade me from this :) >> >> > >> >> > ===== Problem 1: Escaped characters ===== >> >> > Currently, Lexer.x resolves escaped characters for string literals. In the Note [Literal source text], we see that this is intentional; HsString should contain a normalized internal representation. However, multiline string literals have a post-processing step that requires distinguishing between the user typing a newline vs the user typing literally a backslash + an `N` (and other things like knowing if a user typed in `\&`, which currently goes away in lexing as well). >> >> > >> >> > Fundamentally, the current logic to resolve escaped characters is specific to the Lexer monad and operates on a per-character basis. But the multiline string literals proposal requires post-processing the whole string, then resolving escaped characters all at once. >> >> > >> >> > Possible solutions: >> >> > >> >> > (1.1) Duplicate the logic for resolving escaped characters >> >> > * Pro: Leaves normal string lexing untouched >> >> > * Con: Two sources of truth, possibly divergent behaviors between multiline and normal strings >> >> > >> >> > (1.2) Stick the post-processed string back into P, then rerun normal string lexing to resolve escaped characters >> >> > * Pro: Leaves normal string lexing untouched >> >> > * Con: Seems roundabout, inefficient, and hacky >> >> > >> >> > (1.3) Refactor the resolve-escaped-characters logic to work in both the P monad and as a pure function `String -> String` >> >> > * Pro: Reuses same escaped-characters logic for both normal + multiline strings >> >> > * Con: Different overall behavior between the two string types: Normal string still lexed per-character, Multiline strings would lex everything >> >> > * Con: Small refactor of lexing normal strings, which could introduce regressions >> >> > >> >> > (1.4) Read entire string (both normal + multiline) with no preprocessing (including string gaps or anything, except escaping quote delimiters), and define all post-processing steps as pure `String -> String` functions >> >> > * Pro: Gets out of monadic code quickly, turn bulk of string logic into pure code >> >> > * Pro: Processes normal + multiline strings exactly the same >> >> > * Pro: Opens the door for future string behaviors, e.g. raw string could do the same "read entire string" logic, and just not do any post-processing. >> >> > * Con: Could be less performant >> >> > * Con: Major refactor of lexing normal strings, which could introduce regressions >> >> > >> >> > I like solution 1.4 the best, as it generalizes string processing behavior the best and is more pipeline-style vs the currently more imperative style. But I recognize possible performance or behavior regressions are a real thing, so if anyone has any thoughts here, I'd love to hear them. >> >> > >> >> > ===== Problem 2: Overloaded strings ===== >> >> > Currently, `HsString s` is converted into `HsOverLit (HsIsString s)` in the renaming phase. Following Matthew's suggestion of resolving multiline string literals in the desugar step, this would mean that multiline string literals are post-processed after OverloadedStrings has already been applied. >> >> > >> >> > I don't like any of the solutions this approach brings up: >> >> > * Do post processing both when Desugaring HsMultilineString AND when Renaming HsMultilineString to HsOverLit - seems wrong to process multiline strings in two different phases >> >> > * Add HsIsStringMultiline and post process when desugaring both HsMultilineString and HsIsStringMultiline - would ideally like to avoid adding a variant of HsIsStringMultiline >> >> > >> >> > Instead, I propose we throw away the HsMultilineString idea and reuse HsString. The multiline syntax would still be preserved in the SourceText, and this also leaves the door open for future string features. For example, if we went with HsMultilineString, then adding raw strings would require adding both HsRawString and HsMultilineRawString. >> >> > >> >> > Here are two possible solutions for reusing HsString: >> >> > >> >> > (2.1) Add a HsStringType parameter to HsString >> >> > * HsStringType would define the format of the FastString stored in HsString: Normal => processed, Multiline => stores raw string, needs post-processing >> >> > * Post processing could occur in desugaring, with or without OverloadedStrings >> >> > * Pro: Shows the parsed multiline string before processing in -ddump-parsed >> >> > * Con: HsString containing Multiline strings would not contain the normalized representation mentioned in Note [Literal source text] >> >> > * Con: Breaking change in the GHC API >> >> > >> >> > (2.2) Post-process multiline strings in lexer >> >> > * Lexer would do all the post processing (for example, in conjunction with solution 1.4) and just return a normal HsString >> >> > * Pro: Multiline string is immediately desugared and behaves as expected for OverloadedStrings (and any other behaviors of string literals, existing or future) for free >> >> > * Pro: HsString would still always contain the normalized representation >> >> > * Con: No way of inspecting the raw multiline parse output before processing, e.g. via -ddump-parsed >> >> > >> >> > I'm leaning towards solution 2.1, but curious what people's thoughts are. >> >> > >> >> > ===== Closing remarks ===== >> >> > Again, sorry for the long email. My head is spinning trying to figure out this feature. Any help would be greatly appreciated. >> >> > >> >> > As an aside, I last worked on GHC back in 2020 or 2021, and my goodness. The Hadrian build is so much smoother (and faster!? Not sure if it's just my new laptop though) than what it was last time I touched the codebase. Huge thanks to the maintainers, both for the tooling and the docs in the wiki. This is a much more enjoyable experience. >> >> > >> >> > Thanks, >> >> > Brandon >> >> > >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs(a)haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0