- Jun 19, 2023
-
-
Reinier Maas authored
-
- Jun 12, 2023
-
-
Reinier Maas authored
-
Reinier Maas authored
-
- Jun 11, 2023
-
-
Reinier Maas authored
-
Reinier Maas authored
-
davide authored
-
Duncan Coutts authored -
Duncan Coutts authored
And refer to it from the various places involved in the scheme.
-
Duncan Coutts authored
-
Duncan Coutts authored
Add a sub-subsection in the chapter on GHC extensions to the FFI, under the existing Memory Allocation subsection. Explain that it's permitted to have {Mutable}ByteArray# outside the heap and the tricky associated constraints. Mention the new primop placeByteArray#. -
Duncan Coutts authored
Closes issue #17747 Test that we can allocate ByteArray#s outside of the HEAP_ALLOCED() address space without upsetting the GC. To be extra sure we attach weak pointers with C finalizers to the ByteArray#s. We keep them alive and run a major GC so that the GC has to trace the live ByteArray#s. Prior to the first patch in this series, doing this would upset the GC because the GC does not expect heap objects with closure type ARR_WORDS to exist outside the GC heap. > internal error: evacuate(static): strange closure type 42 Finally we allow everything to be GC'd again, and check that the C finalizers did run. This feature also required a change to the isByteArrayPinned# which itself required a CMM implementation of the HEAP_ALLOCED system. So we also add a check that the CMM and C implementations of HEAP_ALLOCED agree with each other.
-
Duncan Coutts authored
The isByteArrayPinned# primop works by looking up the block descriptor for the byte array to see if it lives in a pinned area or not. This of course cannot work for byte arrays that are not HEAP_ALLOCATED since they don't have block descriptors. The solution is to check if it is HEAP_ALLOCATED first. Since this is done in CMM code we make use of the new HEAP_ALLOCATED support for CMM. It is a bit awkward since it does not have a uniform interface.
-
Duncan Coutts authored
Allow rts/sm/HeapAlloc.h to be #included by CMM code and have it provide a suitable implementation of HEAP_ALLOCED. The HEAP_ALLOCED system has three implementations, the large address space case, two fallbakc impls, one for 32bit and one for 64bit. The first two are simple enough that we can provide a HEAP_ALLOCED macro that can be used in a CMM expression context. The 64bit fallback case is rather more tricky. We provide a different interface to HEAP_ALLOCED for this case, which has to be called in a statement/"callish" style.
-
Duncan Coutts authored
It places a byte array heap object header at the given address, which must be outside the heap. It also sets the byte array size.
-
Duncan Coutts authored
In the GC, evacuate() is prepared to deal with some heap objects that are not in the HEAP_ALLOCED() memory space. These are mainly the heap objects that GHC puts into the data sections of object files. It is also useful however to allow ByteArray# and MutableByteArray# heap objects to appear outside of the HEAP_ALLOCED() memory space. These have the ARR_WORDS closure type and contain no pointer should be easy to deal with. Indeed evacuate() already deals with closure types for constructors containing no pointers by doing nothing. So we just tack the ARR_WORDS case into this group of closure types that are permitted outside the HEAP_ALLOCED area but otherwise ignored.
-
- Jun 10, 2023
-
-
-
-Wterm-variable-capture wasn't accordant with type variable scoping in associated types, in type classes. For example, this code produced the warning: k = 12 class C k a where type AT a :: k -> Type I solved this issue by reusing machinery of newTyVarNameRn function that is accordand with associated types: it does lookup for each free type variable when we are in the type class context. And in this patch I use result of this work to make sure that -Wterm-variable-capture warns only on implicitly quantified type variables.
-
- Jun 09, 2023
-
-
-
This broke the sdist generation. Fixes #23489
-
Ticket #23454 explained it was possible to implement unsafeCoerce because SNat was lacking a role annotation. As these are supposed to be singleton types but backed by an efficient representation the correct annotation is nominal to ensure these kinds of coerces are forbidden. These annotations were missed from https://github.com/haskell/core-libraries-committee/issues/85 which was implemented in 532de368. CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/170 Fixes #23454
-
Introduce a `-ddump-spec-constr` flag which debugs specialisations from `SpecConstr`. These are no longer shown when you use `-ddump-spec`.
-
By returning a complete HscEnv from upsweep the logger (as introduced by withDeferredDiagnostics) was escaping the scope of withDeferredDiagnostics and hence we were losing error messages. This is reminiscent of #20981, which also talks about writing errors into messages after their scope has ended. See #23305 for details.
-
Ticket #23305 reports an error where we were attempting to use the logger which was created by withDeferredDiagnostics after its scope had ended. This problem would have been caught by this patch and a validate build: ``` +*** Exception: Use after free +CallStack (from HasCallStack): + error, called at compiler/GHC/Driver/Make.hs:<line>:<column> in <package-id>:GHC.Driver.Make ``` This general issue is tracked by #20981
-
This fixes the behaviour of -keep-tmp-files when used in an OPTIONS_GHC pragma for files with module level scope. Instead of simple not deleting the files, we also need to remove them from the TmpFs so they are not deleted later on when all the other files are deleted. There are additional complications because you also need to remove the directory where these files live from the TmpFs so we don't try to delete those later either. I added two tests. 1. Tests simply that -keep-tmp-files works at all with a single module and --make mode. 2. The other tests that temporary files are deleted for other modules which don't enable -keep-tmp-files. Fixes #23339
-
We were checking that TH-spliced data declarations do not look like this: ```hs data D :: Type = MkD Int ``` But we were only doing so for `data` declarations' data constructors, not for `newtype`s, `data instance`s, or `newtype instance`s. This patch factors out the necessary validity checks into its own `cvtDataDefnCons` function and uses it in all of the places where it needs to be. Fixes #22559.
-
As of !9475, the RTS now links against `ucrt` instead of `msvcrt` on Windows, which means that the RTS no longer needs to declare stubs for the `__mingw_*` family of symbols. Let's remove these stubs to avoid confusion. Fixes #23309.
-
This partially reverts some of the changes in !9475 to make `base` and `ghc-prim` depend on the `mingwex` library on Windows. It also restores the RTS's stubs for `mingwex`-specific symbols such as `_lock_file`. This is done because the C runtime provides `libmingwex` nowadays, and moreoever, not linking against `mingwex` requires downstream users to link against it explicitly in difficult-to-predict circumstances. Better to always link against `mingwex` and prevent users from having to do the guesswork themselves. See ghc/ghc!10360 (comment 495873) for the discussion that led to this.
-
- Jun 08, 2023
-
-
-
Simon Peyton Jones authored
This fixes #23323 See (RC4) in Note [Tracking redundant constraints]
-
- Jun 07, 2023
-
-
This reverts commit f3556d6c.
-
This reverts commit 5d1f2411.
-
This reverts commit b7a640ac.
-
This reverts commit 5aef5658.
-
This reverts commit 69563c97.
-
This reverts commit 7872e2b6.
-
This reverts commit 0e85099b.
-
This reverts commit a0048866.
-
This reverts commit 09d93bd0.
-
This reverts commit 3ded9a1c.
-
This reverts commit 41b41577.
-
