| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you reverse the order of uniques you get the core lint
error from the testcase. The testcase is copied from
tests/simplCore/should_compile/T10689a.hs.
The problem is that we would put type and kind variables ordered by
unique order, which happened to be the right order for this testcase to
pass under normal conditions.
I think it's enough to sort them with `sortQuantVars`, but I'm not
really sure if some more sophisticated dependency analysis isn't needed.
Test Plan: added a new testcase
Reviewers: simonpj, goldfire, simonmar, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1457
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1319
|
| | |
|
| |
|
|
|
|
|
|
| |
SpecConstr was generating a rule LHS with nested casts,
which the simplifier then optimised away. Result: unbound
template variables.
Easily fixed. See Note [SpecConstr call patterns]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we have an orphan rule in our database, don't apply it
unless the defining module is transitively imported by the
module we are processing. We do this by defining a new RuleEnv
data type which includes both the RuleBase as well as the set
of visible orphan modules, and threading this through the
relevant environments (CoreReader, RuleCheckEnv and ScEnv).
This is analogous to the instances fix we applied in #2182
4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES.
An important knock-on effect is that we can remove some buggy
code in LoadInterface which tried to avoid loading interfaces
that were loaded by plugins (which sometimes caused instances
and rules to NEVER become visible).
One note about tests: I renamed the old plugins07 test to T10420
and replaced plugins07 with a test to ensure that a plugin
import did not cause new rules to be loaded in.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, goldfire
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D950
GHC Trac Issues: #10420
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seed SpecConstr based on *local* calls as well as *RHS* calls.
See Note [Seeding top-level recursive groups]. The change here
is mentioned here:
NB: before Apr 15 we used (a) only, but Dimitrios had an example
where (b) was crucial, so I added that.
This is a pretty small change, requested by Dimitrios, that adds
SpecConstr call patterns from the rest of the module, as well as ones
from the RHS.
Still to come: #10346.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.
Reviewers: austin, jstolarek, hvr, goldfire
Reviewed By: austin, jstolarek
Subscribers: thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D621
GHC Trac Issues: #9986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces "SourceNote" tickishs that link Core to the
source code that generated it. The idea is to retain these source code
links throughout code transformations so we can eventually relate
object code all the way back to the original source (which we can,
say, encode as DWARF information to allow debugging). We generate
these SourceNotes like other tickshs in the desugaring phase. The
activating command line flag is "-g", consistent with the flag other
compilers use to decide DWARF generation.
Keeping ticks from getting into the way of Core transformations is
tricky, but doable. The changes in this patch produce identical Core
in all cases I tested -- which at this point is GHC, all libraries and
nofib. Also note that this pass creates *lots* of tick nodes, which we
reduce somewhat by removing duplicated and overlapping source
ticks. This will still cause significant Tick "clumps" - a possible
future optimization could be to make Tick carry a list of Tickishs
instead of one at a time.
(From Phabricator D169)
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
