StaticPointers support in GHCi

Currently GHCi does not support -XStaticPointers, which is quite annoying for those of us who actually use -XStaticPointers in day-to-day development. It would be great if GHCi could grow support for this extension.

Trac metadata

Trac field	Value
Version	8.0.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related	#12000 (closed)
Blocking
CC
Operating system
Architecture

mentioned in issue #12000 (closed)

changed milestone to %8.2.1

changed weight to 5

added Tfeature request Trac import labels

there are a few notes on the current state of things on StaticPointers/Old and #12000 (closed).

Facundo, do you suppose you could describe what is currently missing to get proper StaticPointers support in GHCi?

When compiling a module, the FloatOut pass puts StaticPtrs in the top level and the tidy-core pass generates a C constructor function which inserts the top-level bindings in the static pointer table (SPT) when the module is loaded.

In GHCi, I guess that bindings could be inserted in the SPT when they are linked. I don't know if the FloatOut pass is used when compiling code in GHCi, if not, floating the static pointer values to the top-level would need to be accomplished otherwise.

Trac metadata

Trac field	Value
Related	#12000 (closed) → #9878 (closed), #12000 (closed)

I have the beginnings of an implementation of this in D2504.

Trac metadata

Trac field	Value
Differential revisions	- → D2504

One particularly hairy problem that arises here is that of breakpoint ticks interacting with FloatOut. Currently we disallow any floating through breakpoint ticks. However, static pointer support requires that we float out static expressions to the top level. I can see two options here,

1. Allow floating of StaticPtr values through breakpoints as a special case.
2. Disable breakpoint production while -XStaticPointers is enabled.

Given that (1) may give rise to some rather surprising behavior in the face of recursive groups (e.g. a recursive group with one StaticPtr and a bunch of other bindings; the whole group will need to be floated, killing breakpoint support for all floated code), I suspect that (2) is the only sensible option.

assigned to @bgamari

D2504 adds limited support for StaticPointers in GHCi. While expressions entered at the REPL still cannot contain static expressions, modules loaded into the interpreter may. This should recover the majority of the convenience that one previously lost with StaticPointers. Note, however, that there is a bit of a memory leak as static expressions will necessarily never be unloaded, even after the module that introduced them goes out of scope.

mentioned in commit eedb3df0

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in issue #13481 (closed)

reopened

RyanGlScott points out that this patch inadvertently added a pprTrace which blurts out in GHCi. D3663 fixes this.

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved
Differential revisions	D2504 → D2504, D3663

mentioned in commit 84cf095d