ARM CPUs before v8.3-a doesn't support `ldapr` instruction which is generated from __atomic_load_n(ptr, __ATOMIC_ACQUIRE). And -march=armv8-a+norcpc disables this feature.

Apple doc says: "The platforms reserve register x18. Don’t use this register."
https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms

Another ios related doc says: x18 platform register (reserved, periodically zeroed by XNU)
https://github.com/Siguza/ios-resources/blob/master/bits/arm64.md

Add arbitraryHeapStart flag. It allows to allocate the memory block anywhere, not only above the 8 GB.
Without it we can get an inifite loop in osReserveHeapMemory because ios sometimes doesn't allocate memory below the 8 GB

return NULL in my_mmap in a case of darwin_HOST_OS to make it work on iOS. It allows more attempts for osTryReserveHeapMemory. On macos it succeeds on the first try but ios doesn't give 256GB (0x4000000000) to allocate

Zubin authored 1 year ago and Marge Bot committed 1 year ago

Document the permissibility introduced by
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst

Ben Bellick authored 1 year ago and Marge Bot committed 1 year ago

Addresses #19278

This commit deprecates the underspecified -ddump-json flag and
introduces a newer, well-specified flag -fdiagnostics-as-json.

Also included is a JSON schema as part of the documentation.

The -ddump-json flag will be slated for removal shortly after this merge.

Ben Bellick authored 1 year ago and Marge Bot committed 1 year ago

Addresses #19278

This commit deprecates the underspecified -ddump-json flag and
introduces a newer, well-specified flag -fdiagnostics-as-json.

Also included is a JSON schema as part of the documentation.

The -ddump-json flag will be slated for removal shortly after this merge.

Zubin authored 1 year ago and Marge Bot committed 1 year ago

This test has been flaky for some time and has been failing consistently on
i386-linux since 8e0446df landed.

See #24261

In the end the bindist creation logic copies them all into the bin
folder. There is no benefit to building a specific few binaries in the
lib/bin folder anymore.

This also removes the ad-hoc logic to copy the touchy and unlit
executables from stage0 into stage1. It takes <1s to build so we might
as well just build it.

Vladislav Zavialov authored 1 year ago and Marge Bot committed 1 year ago

The proposal is no longer available at the previous URL.

Ben Gamari authored 2 years ago and Marge Bot committed 1 year ago

Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.

However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:

            Thread A                             Thread B
            ---------                            ---------
    t=0     Enter t
      1     Push update frame
      2     Begin evaluation

      4     Pause thread
      5     t.indirectee=tso
      6     Release t.info=BLACKHOLE

      7     ... (e.g. GC)

      8     Resume thread
      9     Finish evaluation
      10    Relaxed t.indirectee=x

      11                                         Load t.info
      12                                         Acquire fence
      13                                         Inspect t.indirectee

      14    Release t.info=BLACKHOLE

Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.

Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.

We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.

See #23185.

Luite Stegeman authored 1 year ago and Marge Bot committed 1 year ago

This marks the spurious test failures on the JS platform as
js_fragile(24259), so we don't hold up merge requests while
fixing the underlying issues.

See #24259

Bryan R authored 1 year ago and Marge Bot committed 1 year ago

This changes nothing, it just makes the status quo explicit.

Zubin authored 1 year ago and Marge Bot committed 1 year ago

This prevents the tree from being dirtied when the file is modified.

Vladislav Zavialov authored 1 year ago and Marge Bot committed 1 year ago

Summary of changes

* Remove Language.Haskell.Syntax.Concrete
* Move all tokens into GhcPs extension fields (LHsToken -> EpToken)
* Create new TTG extension fields as needed
* Drop the MultAnn wrapper

Updates the haddock submodule.

Co-authored-by: Alan Zimmerman <alan.zimm@gmail.com>

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Previously ensureRoomForVariableEvent would truncate the desired size to
16-bits, resulting in #24197.

Fixes #24197.

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Previously we would keep plugging along, even if isn't enough room for
the event.

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Previously we failed to account for the NULL terminator `postString`
asserted that there is enough room in the buffer for the string.

Vladislav Zavialov authored 1 year ago and Marge Bot committed 1 year ago

Update the User's Guide and Release Notes to account for the recent
progress in the implementation of RequiredTypeArguments.

Moritz Angermann authored 1 year ago and Marge Bot committed 1 year ago

XCODE_VERSION calls out to `xcodebuild`, which is only available
when having `Xcode` installed. The CommandLineTools are not
sufficient. To install Xcode, you must have an apple id to download
the Xcode.xip from apple.

We do not use xcodebuild anywhere in our build explicilty. At best
it appears to be a proxy for checking the linker or the compiler.
These should rather be done with
```
xcrun ld -version
```
or similar, and not by proxy through Xcode. The CLR should be
sufficient for building software on macOS.

Oleg Grenrus authored 1 year ago and Marge Bot committed 1 year ago

Resolves #24190

Apparently the check was essentially always (as far as I can trace back: d0d47ba7),
and while it does catch some mismatches, the type-checker will catch
them too. OTOH, it prevents writing completely reasonable programs.