Don't tick floated top-level primitive strings
AbandonedPublic

Authored by niteria on Feb 19 2018, 10:45 AM.

Details

Reviewers
simonpj
simonmar
bgamari
Trac Issues
#14779
Summary

This fixes f5b275a2 where the intent was to never produce
top-level ticked strings.
The meaning of the top_lvl parameter here doesn't align
with the intent, as explained in a new comment.

As a side note, I don't know where we guarantee that the
string literals get floated to the very top. I think that's
the only kind of floating that the simplifier does, but I
couldn't find any comment on that.

Test Plan

GHC HEAD now builds with -g
I added 2 new tests that previously reproduced.

niteria created this revision.Feb 19 2018, 10:45 AM

Thank you for doing this, @niteria!

bgamari accepted this revision.Feb 19 2018, 8:04 PM

As a side note, I don't know where we guarantee that the string literals get floated to the very top. I think that's the only kind of floating that the simplifier does, but I couldn't find any comment on that.

IIRC, this falls out naturally from the usual SetLevels logic: lvlMFE will float lifted things and things that satisfy exprIsTopLevelBindable (which liiteral strings do). lvlBind has some logic to ensure that primitive strings are only floated to the top-level.

compiler/simplCore/Simplify.hs
449

Good catch.

testsuite/tests/simplCore/should_compile/T14779a.hs
12

Shouldn't these be in a OPTIONS_GHC as well?

This revision is now accepted and ready to land.Feb 19 2018, 8:04 PM

I'm not sure this the right fix. Can you look at Trac Trac #14779 comment:10?

Can we nail this? See comment:12 of Trac #14779