| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
If the union of dependencies of imported modules change, the `mi_deps`
field of the interface files should change as well. Because of that, we
need to check for changes in this in recompilation checker which we are
not doing right now. This adds a checks for that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid having to `panic` any time a TTG extension constructor is
consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
that in every extension constructor's type family instance where it
is appropriate. This also introduces a 'noExtCon' function which
eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
a 'Void'.
I also renamed the existing `NoExt` type to `NoExtField` to better
distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
code churn resulting from this.
Bumps the Haddock submodule. Fixes #15247.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is important as in hard link mode shake makes all such files
read only to avoid accidentally modifying cache files via the
hard link. It turns out, many Hadrian rules attempt read access
to such files and hence fail in the hard link mode. These
rules could be refactored to avoid write access, but using
copy instead of hard link a much simpler solution.
|
| | |
|
| |
|
|
|
|
|
|
| |
Attach the `SrcSpan` of the first pattern synonym binding involved in
the recursive group when throwing the corresponding error message,
similarly to how it is done for type synonyms.
Fixes #16900.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The relative URLs were a workaround to let most contributors fork from
Github due to a weakness in the haskell.org server.
This workaround is no longer needed. And relative submodule URLs are
an impediment to forking which makes contributions harder than they
should be.
The URLs are chosen to clone from https, because this makes sure that
anybody, even not a registered Gitlab user, can clone a fork
recursively.
|
| |
|
|
|
|
|
|
|
| |
Adds stripStgTicksTopE which only returns the stripped expression.
So far we also allocated a list for the stripped ticks which was
never used.
Allocation difference is as expected very small but present.
About 0.02% difference when compiling with -O.
|
| |
|
|
|
|
|
|
| |
Ticket #16247 showed that we were discarding an implication
constraint that had empty ic_wanted, when we still needed to
keep it so we could check whether it had a bad telescope.
Happily it's a one line fix. All the rest is comments!
|
| |
|
|
|
|
|
|
|
|
|
| |
In dumpCensus we switch/case on doHeapProfile twice. The second switch
tries to barf on unknown doHeapProfile modes but HEAP_BY_CLOSURE_TYPE is
checked by the first switch and not included in the second.
So when trying to pass -hT to the profiling rts it barfs.
This commit simply merges the two switches into one which fixes this
problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the eager unifier, when unifying (tv1 ~ tv2),
when we decide to swap them over, to unify (tv2 ~ tv1),
I'd forgotten to ensure that tv1's kind was fully zonked,
which is an invariant of uUnfilledTyVar2.
That could lead us to build an infinite kind, or (in the
case of #16902) update the same unification variable twice.
Yikes.
Now we get an error message rather than non-termination,
which is much better. The error message is not great,
but it's a very strange program, and I can't see an easy way
to improve it, so for now I'm just committing this fix.
Here's the decl
data F (a :: k) :: (a ~~ k) => Type where
MkF :: F a
and the rather error message of which I am not proud
T16902.hs:11:10: error:
• Expected a type, but found something with kind ‘a1’
• In the type ‘F a’
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this refactoring:
* DerivInfo for data family instances was returned from tcTyAndClassDecls
* DerivInfo for data declarations was generated with mkDerivInfos and added at a
later stage of the pipeline in tcInstDeclsDeriv
After this refactoring:
* DerivInfo for both data family instances and data declarations is returned from
tcTyAndClassDecls in a single list.
This uniform treatment results in a more convenient arrangement to fix #16731.
|
| | |
|
| |
|
|
|
| |
This is to mimic what `Scav.c` does. This should fix a crash in
the printer.
|
| | |
|
| |
|
|
|
|
|
| |
Commit cef80c0b9edca3d21b5c762f51dfbab4c5857d8a debuted a breaking
change to `template-haskell`, so in order to guard against it
properly with CPP, we need to bump the `template-haskell` version
number accordingly.
|
| |
|
|
|
|
|
| |
Previously we used the deb9-debug job which used the `validate` build
flavour which disabled `BUILD_SPHINX_PDF`. Fix this.
Fixes #16890.
|
| |
|
|
|
|
|
| |
This adds support for constructing vector types from Float#, Double# etc
and performing arithmetic operations on them
Cleaned-Up-By: Ben Gamari <ben@well-typed.com>
|
| |
|
|
|
| |
This is a temporary workaround shake not supporting symlinks
when using cloud/cached builds.
|
| | |
|
| |
|
|
|
| |
just use the test to show the defective behaviour, so we can see
the difference, when it gets fixed
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As such the internal linker will fail for them. The alternative
would be to implement them as stubs in the linker and have them
barf when called.
> Not all operations are supported by all target processors. If a
particular operation cannot be implemented on the target processor,
a warning is generated and a call an external function is
generated. The external function carries the same name as the
built-in version, with an additional suffix ‘_n’ where n is the size
of the data type.
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html)
|
| | |
|
| |
|
|
|
|
|
| |
This adds lookup logic for _GLOBAL_OFFSET_TABLE_ as well as
relocation logic for R_ARM_BASE_PREL and R_ARM_GOT_BREL which
the gnu toolchain (gas, gcc, ...) prefers to produce. Apparently
recent llvm toolchains will produce those as well.
|
| |
|
|
|
| |
I'm not entirely sure we are careful about ensuring this; this is a
last-ditch check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here the following changes are introduced:
- A read barrier machine op is added to Cmm.
- The order in which a closure's fields are read and written is changed.
- Memory barriers are added to RTS code to ensure correctness on
out-or-order machines with weak memory ordering.
Cmm has a new CallishMachOp called MO_ReadBarrier. On weak memory machines, this
is lowered to an instruction that ensures memory reads that occur after said
instruction in program order are not performed before reads coming before said
instruction in program order. On machines with strong memory ordering properties
(e.g. X86, SPARC in TSO mode) no such instruction is necessary, so
MO_ReadBarrier is simply erased. However, such an instruction is necessary on
weakly ordered machines, e.g. ARM and PowerPC.
Weam memory ordering has consequences for how closures are observed and mutated.
For example, consider a closure that needs to be updated to an indirection. In
order for the indirection to be safe for concurrent observers to enter, said
observers must read the indirection's info table before they read the
indirectee. Furthermore, the entering observer makes assumptions about the
closure based on its info table contents, e.g. an INFO_TYPE of IND imples the
closure has an indirectee pointer that is safe to follow.
When a closure is updated with an indirection, both its info table and its
indirectee must be written. With weak memory ordering, these two writes can be
arbitrarily reordered, and perhaps even interleaved with other threads' reads
and writes (in the absence of memory barrier instructions). Consider this
example of a bad reordering:
- An updater writes to a closure's info table (INFO_TYPE is now IND).
- A concurrent observer branches upon reading the closure's INFO_TYPE as IND.
- A concurrent observer reads the closure's indirectee and enters it. (!!!)
- An updater writes the closure's indirectee.
Here the update to the indirectee comes too late and the concurrent observer has
jumped off into the abyss. Speculative execution can also cause us issues,
consider:
- An observer is about to case on a value in closure's info table.
- The observer speculatively reads one or more of closure's fields.
- An updater writes to closure's info table.
- The observer takes a branch based on the new info table value, but with the
old closure fields!
- The updater writes to the closure's other fields, but its too late.
Because of these effects, reads and writes to a closure's info table must be
ordered carefully with respect to reads and writes to the closure's other
fields, and memory barriers must be placed to ensure that reads and writes occur
in program order. Specifically, updates to a closure must follow the following
pattern:
- Update the closure's (non-info table) fields.
- Write barrier.
- Update the closure's info table.
Observing a closure's fields must follow the following pattern:
- Read the closure's info pointer.
- Read barrier.
- Read the closure's (non-info table) fields.
This patch updates RTS code to obey this pattern. This should fix long-standing
SMP bugs on ARM (specifically newer aarch64 microarchitectures supporting
out-of-order execution) and PowerPC. This fixes issue #15449.
Co-Authored-By: Ben Gamari <ben@well-typed.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #16857.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is important that `heapCensus` and `LdvCensusForDead` traverse the
same areas.
`heapCensus` increases the `not_used` counter which tracks how many
closures are live but haven't been used yet.
`LdvCensusForDead` increases the `void_total` counter which tracks how
many dead closures there are.
The `LAG` is then calculated by substracting the `void_total` from
`not_used` and so it is essential that `not_used >= void_total`. This
fact is checked by quite a few assertions.
However, if a program has low maximum residency but allocates a lot in
the nursery then these assertions were failing (see #16753 and #15903)
because `LdvCensusForDead` was observing dead closures from the nursery
which totalled more than the `not_used`. The same closures were not
counted by `heapCensus`.
Therefore, it seems that the correct fix is to make `LdvCensusForDead`
agree with `heapCensus` and not traverse the nursery for dead closures.
Fixes #16100 #16753 #15903 #8982
|
| |
|
|
|
| |
It is possible that void_total is exactly equal to not_used and the
other assertions for this check for <= rather than <.
|
| |
|
|
|
|
|
|
|
| |
This implements the correct fix for #11627 by skipping over the slop
(which is zeroed) rather than adding special case logic for LARGE
ARR_WORDS which runs the risk of not performing a correct census by
ignoring any subsequent blocks.
This approach implements similar logic to that in Sanity.c
|
| | |
|
| |
|
|
|
|
| |
This allows us to run (but ignore the result of) fragile testcases.
Hopefully this should allow us to more easily spot when a fragile test
becomes un-fragile.
|
| | |
|
| |
|
|
| |
This is the same as T5611 but with an unsafe call to sleep.
|
| |
|
|
|
| |
The original issue, #5611, was concerned with safe calls. However, the
test inexplicably used an unsafe call. Fix this.
|
| | |
|
| |
|
|
|
| |
The test seems to have been missing the name of its script and didn't
build with HEAD. How it made it through CI is beyond me.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit partly reverts e69619e923e84ae61a6bb4357f06862264daa94b
commit by reintroducing Sf_SafeInferred SafeHaskellMode.
We preserve whether module was declared or inferred Safe. When
declared-Safe module imports inferred-Safe, we warn. This inferred
status is volatile, often enough it's a happy coincidence, something
which cannot be relied upon. However, explicitly Safe or Trustworthy
packages won't accidentally become Unsafe.
Updates haddock submodule.
|
| |
|
|
|
| |
Metric Increase:
haddock.Cabal
|
