Never tick primitive string literals
Needs RevisionPublic

Authored by bgamari on Feb 2 2017, 1:36 PM.



This is a more aggressive approach to the problem initially solved in
f5b275a239d2554c4da0b7621211642bf3b10650, where top-level primitive string
literals were being wrapped by ticks. This breaks the Core invariant descirbed
in Note [CoreSyn top-level string literals]. However, the previous approach was
incomplete and left several places where inappropriate ticks could sneak in.

This commit kills the problem at the source: we simply never tick any primitive
string literal expression. The assumption here is that these expressions are
destined for the top-level, where they cannot be ticked, anyways. So even if
they haven't been floated out yet there is no reason to tick them.

This partially reverts commit f5b275a239d2554c4da0b7621211642bf3b10650.

Test Plan

Validate with -g

bgamari updated this revision to Diff 10896.Feb 2 2017, 1:36 PM
bgamari retitled this revision from to Never tick primitive string literals.
bgamari updated this object.
bgamari edited the test plan for this revision. (Show Details)
bgamari updated this revision to Diff 10902.Feb 2 2017, 2:18 PM
bgamari edited edge metadata.

Fix syntax error

Does this look better?

bgamari added a subscriber: simonmar.

@simonmar, @simonpj any objection to this?

simonmar added inline comments.Feb 9 2017, 5:23 AM

Hmm, I'm not sure about this. What about an HPC tick? We lose the information about whether this subexpression was used. The right thing to do would be to leave the tick behind when we float out the string.

dfeuer requested changes to this revision.Feb 22 2017, 6:02 PM
dfeuer added a subscriber: dfeuer.

Requesting changes per @simonmar's comment.

This revision now requires changes to proceed.Feb 22 2017, 6:02 PM
austin resigned from this revision.Nov 9 2017, 11:33 AM