From aa4ce11c8ad9323e308e1d81c3f9b2c857934fb0 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Mon, 14 Sep 2026 15:03:21 -0700 Subject: add the ability for magic comments to happen in immediate mode but, don't do them, though, they aren't ready yet. for reasons described in the code. they're harmless, they don't cause crashes or incorrect output, they just don't cause any output at all. Force-Push: yes Change-Id: I5e45adc60f4e01e7bc54d9da8aa4fa5f8b708ddb --- transform.e | 62 +++++++++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 44 insertions(+), 18 deletions(-) (limited to 'transform.e') diff --git a/transform.e b/transform.e index c53a40a..1d6d830 100644 --- a/transform.e +++ b/transform.e @@ -5163,10 +5163,10 @@ allocate-transformation-state s" transformation-state" variable key dup { ~ The third byte is not 0. dup 0x20 = { - ~ The special test succeeded, so we want to insert a call to - ~ hex-tilde-replacement. First, though, we must save the rest of - ~ the comment body so we can provide it to the replacement at - ~ runtime. + ~ The special test succeeded, so we want to either compile or + ~ execute a call to hex-tilde-replacement. First, though, we + ~ must save the rest of the comment body so we can provide it to + ~ the replacement at runtime. ~ ~ This is the rare case in the transforms where we want to get ~ into the nitty-gritty of lexing. Normally we rely on the @@ -5175,21 +5175,47 @@ allocate-transformation-state s" transformation-state" variable ~ transforms every time there's a new syntax feature. Here, ~ however, we've got a syntax that only has meaning to the ~ transform, so there's no choice. - ~ - ~ Fortunately, we can pack the string directly into the output - ~ buffer, so we don't need to mess around with - ~ accumulate-string. drop - s" lit" find entry-to-execution-token , - has-non-space-this-input-line@ , - s" litstring" find entry-to-execution-token , - here @ - key { dup dup 0x0a != && } { - pack8 key - } while drop - 0 pack8 - 8 packalign here ! - ' hex-tilde-replacement entry-to-execution-token , + interpreter-flags @ 0x01 & { + ~ We're in compile mode. + ~ + ~ Fortunately, we can pack the string directly into the + ~ output buffer, so we don't need to mess around with + ~ accumulate-string. + s" lit" find entry-to-execution-token , + has-non-space-this-input-line@ , + s" litstring" find entry-to-execution-token , + here @ + key { dup dup 0x0a != && } { + pack8 key + } while drop + 0 pack8 + 8 packalign here ! + ' hex-tilde-replacement entry-to-execution-token , + } { + has-non-space-this-input-line@ + + swap-transform-variables here @ swap-transform-variables + + key { dup dup 0x0a != && } { pack8 key } while drop + 0 pack8 + 8 packalign + + swap-transform-variables + here @ swap here ! + swap-transform-variables + + transformation-state transformation-state-output-metadata @ + hex-output-metadata-latest-output-point @ + hex-tilde-replacement + ~ TODO this doesn't work yet + ~ the problem with running this in immediate mode during the + ~ label transform is that the latest output point is 0, + ~ because it's running as part of loading the copy of the + ~ compiler that sits directly inside the hex transform, not as + ~ part of reading the code to be compiled, which is inside + ~ the inner transforms. + } if-else } { ~ The third byte is not 0 or 0x20. 0x0a = { -- cgit 1.4.1