| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, as described in Note [Primop wrappers], `hasNoBinding` would
return False in the case of `PrimOpId`s. This would result in eta
expansion of unsaturated primop applications during CorePrep. Not only
did this expansion result in unnecessary allocations, but it also meant
lead to rather nasty inconsistencies between the CAFfy-ness
determinations made by TidyPgm and CorePrep.
This fixes #16846.
|
| |
|
|
|
| |
The debugging involved in finding #16846 wouldn't have been necessary
had the consistentCafInfo check been enabled. However, :wq
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".
Fix requires for Llvm detection and some code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes three infelicities related to the programs that are
(and aren't) accepted with `UnliftedNewtypes`:
* Enabling `UnliftedNewtypes` would permit newtypes to have return
kind `Id Type`, which had disastrous results (i.e., GHC panics).
* Data family declarations ending in kind `TYPE r` (for some `r`)
weren't being accepted if `UnliftedNewtypes` wasn't enabled,
despite the GHC proposal specifying otherwise.
* GHC wasn't warning about programs that _would_ typecheck if
`UnliftedNewtypes` were enabled in certain common cases.
As part of fixing these issues, I factored out the logic for checking
all of the various properties about data type/data family return
kinds into a single `checkDataKindSig` function. I also cleaned up
some of the formatting in the existing error message that gets
thrown.
Fixes #16821, fixes #16827, and fixes #16829.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously in the case where GHC was dynamically linked we would load
static objects one-by-one by linking each into its own shared object and
dlopen'ing each in order. However, this meant that the link would fail
in the event that the objects had cyclic symbol dependencies.
Here we fix this by merging each "run" of static objects into a single
shared object and loading this.
Fixes #13786 for the case where GHC is dynamically linked.
|
| |
|
|
|
|
|
|
|
| |
Previously we would hackily evaluate a textual code snippet to compute
actions to disable I/O buffering and flush the stdout/stderr handles.
This broke in a number of ways (#15336, #16563).
Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
the needed actions. We can then easily refer to these via `Orig` names.
|
| |
|
|
|
|
|
|
|
| |
As noted in #16841, there are currently a variety of bugs in the
unloading logic. These only affect Windows since code unloading is
disabled on Linux, where we build with `GhcDynamic=YES` by default.
In the interest of getting the tree green on Windows disable code
unloading until the issues are resolved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new kind of plugin, Hole fit plugins. These plugins
can change what candidates are considered when looking for valid hole
fits, and add hole fits of their own. The type of a plugin is relatively
simple,
```
type FitPlugin = TypedHole -> [HoleFit] -> TcM [HoleFit]
type CandPlugin = TypedHole -> [HoleFitCandidate] -> TcM [HoleFitCandidate]
data HoleFitPlugin = HoleFitPlugin { candPlugin :: CandPlugin
, fitPlugin :: FitPlugin }
data TypedHole = TyH { tyHRelevantCts :: Cts
-- ^ Any relevant Cts to the hole
, tyHImplics :: [Implication]
-- ^ The nested implications of the hole with the
-- innermost implication first.
, tyHCt :: Maybe Ct
-- ^ The hole constraint itself, if available.
}
This allows users and plugin writers to interact with the candidates and
fits as they wish, even going as far as to allow them to reimplement the
current functionality (since `TypedHole` contains all the relevant
information).
As an example, consider the following plugin:
```
module HolePlugin where
import GhcPlugins
import TcHoleErrors
import Data.List (intersect, stripPrefix)
import RdrName (importSpecModule)
import TcRnTypes
import System.Process
plugin :: Plugin
plugin = defaultPlugin { holeFitPlugin = hfp, pluginRecompile = purePlugin }
hfp :: [CommandLineOption] -> Maybe HoleFitPluginR
hfp opts = Just (fromPureHFPlugin $ HoleFitPlugin (candP opts) (fp opts))
toFilter :: Maybe String -> Maybe String
toFilter = flip (>>=) (stripPrefix "_module_")
replace :: Eq a => a -> a -> [a] -> [a]
replace match repl str = replace' [] str
where
replace' sofar (x:xs) | x == match = replace' (repl:sofar) xs
replace' sofar (x:xs) = replace' (x:sofar) xs
replace' sofar [] = reverse sofar
-- | This candidate plugin filters the candidates by module,
-- using the name of the hole as module to search in
candP :: [CommandLineOption] -> CandPlugin
candP _ hole cands =
do let he = case tyHCt hole of
Just (CHoleCan _ h) -> Just (occNameString $ holeOcc h)
_ -> Nothing
case toFilter he of
Just undscModName -> do let replaced = replace '_' '.' undscModName
let res = filter (greNotInOpts [replaced]) cands
return $ res
_ -> return cands
where greNotInOpts opts (GreHFCand gre) = not $ null $ intersect (inScopeVia gre) opts
greNotInOpts _ _ = True
inScopeVia = map (moduleNameString . importSpecModule) . gre_imp
-- Yes, it's pretty hacky, but it is just an example :)
searchHoogle :: String -> IO [String]
searchHoogle ty = lines <$> (readProcess "hoogle" [(show ty)] [])
fp :: [CommandLineOption] -> FitPlugin
fp ("hoogle":[]) hole hfs =
do dflags <- getDynFlags
let tyString = showSDoc dflags . ppr . ctPred <$> tyHCt hole
res <- case tyString of
Just ty -> liftIO $ searchHoogle ty
_ -> return []
return $ (take 2 $ map (RawHoleFit . text . ("Hoogle says: " ++)) res) ++ hfs
fp _ _ hfs = return hfs
```
with this plugin available, you can compile the following file
```
{-# OPTIONS -fplugin=HolePlugin -fplugin-opt=HolePlugin:hoogle #-}
module Main where
import Prelude hiding (head, last)
import Data.List (head, last)
t :: [Int] -> Int
t = _module_Prelude
g :: [Int] -> Int
g = _module_Data_List
main :: IO ()
main = print $ t [1,2,3]
```
and get the following output:
```
Main.hs:14:5: error:
• Found hole: _module_Prelude :: [Int] -> Int
Or perhaps ‘_module_Prelude’ is mis-spelled, or not in scope
• In the expression: _module_Prelude
In an equation for ‘t’: t = _module_Prelude
• Relevant bindings include
t :: [Int] -> Int (bound at Main.hs:14:1)
Valid hole fits include
Hoogle says: GHC.List length :: [a] -> Int
Hoogle says: GHC.OldList length :: [a] -> Int
t :: [Int] -> Int (bound at Main.hs:14:1)
g :: [Int] -> Int (bound at Main.hs:17:1)
length :: forall (t :: * -> *) a. Foldable t => t a -> Int
with length @[] @Int
(imported from ‘Prelude’ at Main.hs:5:1-34
(and originally defined in ‘Data.Foldable’))
maximum :: forall (t :: * -> *) a. (Foldable t, Ord a) => t a -> a
with maximum @[] @Int
(imported from ‘Prelude’ at Main.hs:5:1-34
(and originally defined in ‘Data.Foldable’))
(Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)
|
14 | t = _module_Prelude
| ^^^^^^^^^^^^^^^
Main.hs:17:5: error:
• Found hole: _module_Data_List :: [Int] -> Int
Or perhaps ‘_module_Data_List’ is mis-spelled, or not in scope
• In the expression: _module_Data_List
In an equation for ‘g’: g = _module_Data_List
• Relevant bindings include
g :: [Int] -> Int (bound at Main.hs:17:1)
Valid hole fits include
Hoogle says: GHC.List length :: [a] -> Int
Hoogle says: GHC.OldList length :: [a] -> Int
g :: [Int] -> Int (bound at Main.hs:17:1)
head :: forall a. [a] -> a
with head @Int
(imported from ‘Data.List’ at Main.hs:7:19-22
(and originally defined in ‘GHC.List’))
last :: forall a. [a] -> a
with last @Int
(imported from ‘Data.List’ at Main.hs:7:25-28
(and originally defined in ‘GHC.List’))
|
17 | g = _module_Data_List
```
This relatively simple plugin has two functions, as an example of what
is possible to do with hole fit plugins. The candidate plugin starts by
filtering the candidates considered by module, indicated by the name of
the hole (`_module_Data_List`). The second function is in the fit
plugin, where the plugin invokes a local hoogle instance to search by
the type of the hole.
By adding the `RawHoleFit` type, we can also allow these completely free
suggestions, used in the plugin above to display fits found by Hoogle.
Additionally, the `HoleFitPluginR` wrapper can be used for plugins to
maintain state between invocations, which can be used to speed up
invocation of plugins that have expensive initialization.
```
-- | HoleFitPluginR adds a TcRef to hole fit plugins so that plugins can
-- track internal state. Note the existential quantification, ensuring that
-- the state cannot be modified from outside the plugin.
data HoleFitPluginR = forall s. HoleFitPluginR
{ hfPluginInit :: TcM (TcRef s)
-- ^ Initializes the TcRef to be passed to the plugin
, hfPluginRun :: TcRef s -> HoleFitPlugin
-- ^ The function defining the plugin itself
, hfPluginStop :: TcRef s -> TcM ()
-- ^ Cleanup of state, guaranteed to be called even on error
}
```
Of course, the syntax here is up for debate, but hole fit plugins allow
us to experiment relatively easily with ways to interact with
typed-holes without having to dig deep into GHC.
Reviewers: bgamari
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5373
|
| |
|
|
| |
This matches GHC itself getting the target platform from there.
|
| |
|
|
|
|
|
| |
ghc-pkg needs to be aware of platforms so it can figure out which
subdire within the user package db to use. This is admittedly
roundabout, but maybe Cabal could use the same notion of a platform as
GHC to good affect too.
|
| |
|
|
|
|
|
|
|
|
|
| |
* Added Note [Quantified varaibles in partial type signatures]
in TcRnTypes
* Kill dVarSetElemsWellScoped; it was only called in
one function, quantifyTyVars. I inlined it because it
was only scopedSort . dVarSetElems
* Kill Type.tyCoVarsOfBindersWellScoped, never called.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partial type sigs had grown hair. tcHsParialSigType was
doing lots of unnecessary work, and tcInstSig was cloning it
unnecessarily -- and the result didn't even work: #16728.
This patch cleans it all up, described by TcHsType
Note [Checking parital type signatures]
I basically just deleted code... but very carefully!
Some refactoring along the way
* Distinguish more explicintly between "anonymous" wildcards "_"
and "named" wildcards "_a". I changed the names of a number
of functions to make this distinction much more apparent.
The patch also revealed that the code in `TcExpr`
that implements the special typing rule for `($)` was wrong.
It called `getRuntimeRep` in a situation where where was no
particular reason to suppose that the thing had kind `TYPE r`.
This caused a crash in typecheck/should_run/T10846.
The fix was easy, and actually simplifies the code in `TcExpr`
quite a bit. Hooray.
|
| |
|
|
|
|
|
|
|
| |
The substition invariant relies on keeping the in-scope
set in sync, and we weren't always doing so, which means that
a DEBUG compiler crashes sometimes with an assertion failure
This patch fixes a couple more cases. Still not validate
clean (with -DEEBUG) but closer!
|
| |
|
|
|
|
|
|
|
|
|
| |
Not doing this right caused #16608. We now properly trim IdInfos of
DFunIds and PatSyns.
Some further refactoring done by SPJ.
Two regression tests T16608_1 and T16608_2 added.
Fixes #16608
|
| |
|
|
|
|
| |
("Continuation BlockIds" is referenced in CmmProcPoint)
[skip ci]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mkSplitUniqSupply was lazy on the boxed char.
This caused a bunch of issues:
* The closure captured the boxed Char
* The mask was recomputed on every split of the supply.
* It also caused the allocation of MkSplitSupply to happen in it's own
(allocated) closure. The reason of which I did not further investigate.
We know force the computation of the mask inside mkSplitUniqSupply.
* This way the mask is computed at most once per UniqSupply creation.
* It allows ww to kick in, causing the closure to retain the unboxed
value.
Requesting Uniques in a loop is now faster by about 20%.
I did not check the impact on the overall compiler, but I added a test
to avoid regressions.
|
| |
|
|
| |
Fixes #16689.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #15862 demonstrated examples of type constructors on which
`TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
constraint solver in `ClsInst` (in particular, `doTyConApp`) would
try to generate `Typeable` evidence for anyway, resulting in
disaster. This incongruity was caused by the fact that `doTyConApp`
was using a weaker validity check than `tyConIsTypeable` to determine
if a type constructor warrants `Typeable` evidence or not. The
solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
`doTyConApp` instead.
To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
out `tyConIsTypeable` into its own module, `TcTypeableValidity`.
Fixes #15862.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously shiftRule would rewrite as invalid shift like
```
let x = I# (uncheckedIShiftL# n 80)
in ...
```
to
```
let x = I# (error "invalid shift")
in ...
```
However, this breaks the let/app invariant as `error` is not
okay-for-speculation. There isn't an easy way to avoid this so let's not
try. Instead we just take advantage of the undefined nature of invalid
shifts and return zero.
Fixes #16742.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0013-unlifted-newtypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
Issues: #15219, #1311, #13595, #15883
Implementation Details:
Note [Implementation of UnliftedNewtypes]
Note [Unifying data family kinds]
Note [Compulsory newtype unfolding]
This patch introduces the -XUnliftedNewtypes extension. When this
extension is enabled, GHC drops the restriction that the field in
a newtype must be of kind (TYPE 'LiftedRep). This allows types
like Int# and ByteArray# to be used in a newtype. Additionally,
coerce is made levity-polymorphic so that it can be used with
newtypes over unlifted types.
The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
getInitialKind is more liberal, introducing a unification variable to
return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
When kind-checking a data constructor with kcConDecl, we attempt to
unify the kind of a newtype with the kind of its field's type. When
typechecking a data declaration with tcTyClDecl, we again perform a
unification. See the implementation note for more on this.
Co-authored-by: Richard Eisenberg <rae@richarde.dev>
|
| | |
|
| |
|
|
| |
Fixes #16696
|
| |
|
|
|
|
|
| |
Previously we would pass flags intended for the C compiler to the C++
compiler (see #16738). This would cause, for instance, `-std=gnu99` to
be passed to the C++ compiler, causing spurious test failures. Fix this
by maintaining a separate set of flags for C++ compilation invocations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the presence of source notes could hide nested applications
of `unpackFoldrCString#` from our constant folding logic. For instance,
consider the expression:
```haskell
unpackFoldrCString# "foo" c (unpackFoldrCString# "baz" c n)
```
Specifically, ticks appearing in two places can defeat the rule:
a. Surrounding the inner application of `unpackFoldrCString#`
b. Surrounding the fold function, `c`
The latter caused the `str_rules` testcase to fail when `base` was built
with `-g3`.
Fixes #16740.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #16331, the GHCI macro, defined through 'ghci' flags
in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
whether GHC is built with support for an internal interpreter, that runs in
the same process. It is however overloaded in a few places to mean
"there is an interpreter available", regardless of whether it's an internal
or external interpreter.
For the sake of clarity and with the hope of more easily being able to
build stage 1 GHCs with external interpreter support, this patch splits
the previous GHCI macro into 3 different ones:
- HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
- HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
- HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, simonpj
Reviewed By: simonpj
Subscribers: hvr, simonpj, mpickering, rwbarton, carter
GHC Trac Issues: #15838
Differential Revision: https://phabricator.haskell.org/D5285
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
It shouldn't be needed these days, and those primops are "highly
deprecated" anyways.
This fits with my plans because it removes one bit of target-dependence
of the builtin primops, and this is the hardest part of GHC to make
multi-target.
CC @carter
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were actually two bugs fixed here:
1. candidateQTyVarsOfType needs to be careful that it does not
try to zap metavariables from an outer scope as "naughty"
quantification candidates. This commit adds a simple check
to avoid doing so.
2. We weren't bumping the TcLevel in kcHsKindSig, which was used
only for class method sigs. This mistake led to the acceptance
of
class C a where
meth :: forall k. Proxy (a :: k) -> ()
Note that k is *locally* quantified. This patch fixes the
problem by using tcClassSigType, which correctly bumps the
level. It's a bit inefficient because tcClassSigType does other
work, too, but it would be tedious to repeat much of the code
there with only a few changes. This version works well and is
simple.
And, while updating comments, etc., I noticed that tcRnType was
missing a pushTcLevel, leading to #16767, which this patch also
fixes, by bumping the level. In the refactoring here, I also
use solveEqualities. This initially failed ghci/scripts/T15415,
but that was fixed by teaching solveEqualities to respect
-XPartialTypeSignatures.
This patch also cleans up some Notes around error generation that
came up in conversation.
Test case: typecheck/should_fail/T16517, ghci/scripts/T16767
|
| |
|
|
|
|
|
|
|
|
| |
Package DB directories with trailing separator (provided via
GHC_PACKAGE_PATH or via -package-db) resulted in incorrect calculation of
${pkgroot} substitution variable. Keep the trailing separator while
resolving as directory or file, but remove it before dropping the last
path component with takeDirectory.
Closes #16360.
|
| | |
|
| |
|
|
|
| |
Previously log and exp were primitives yet log1p and expm1 were FFI
calls. Fix this non-uniformity.
|
| |
|
|
|
|
| |
[skip ci]
This should really be caught by the linters! (#16711)
|
