REBOL3 tracker
  0.9.12 beta
Ticket #0001594 User: anonymous

Project:



rss
TypeBug Statustested Date4-May-2010 20:15
Versionalpha 97 CategorySyntax Submitted byCarl
PlatformAll Severityminor Priorityhigh

Summary In header, incorrect error message for unterminated string
Description There's something wrong with how we transcode script headers that causes them to produce the wrong error message for bad strings. See example.
Example code
REBOL [
	Title: "test
]

print "test"
halt

;Results in this incorrect error message:

** Syntax error: missing "[" at "end-of-block"
** Where: to unless either if load either either do begin do
** Near: (line 2) ]

; More diagnostics
>> transcode/error to-binary {REBOL [^/^-Title: "test^/]^/^/print "test"^/halt}
== [REBOL [
        Title: make error! [
            code: 200
            type: 'Syntax
            id: 'invalid
            arg1: "string"
            arg2: {"test}
            arg3: none
            near: {(line 2) Title: "test}
            where: [transcode]
        ]
    ]
    make error! [
        code: 201
        type: 'Syntax
        id: 'missing
        arg1: "end-of-block"
        arg2: "["
        arg3: none
        near: "(line 3) ]"
        where: [transcode]
    ] #{0D0A0D0A7072696E7...

But, without /error it works fine:

>> transcode to-binary {["test^/]} 
** Syntax error: invalid "string" -- {"test}

Assigned ton/a Fixed inalpha 108 Last Update20-Oct-2010 03:36


Comments
(0002308)
BrianH
4-May-2010 21:21

Added TRANSCODE/error usage to the example code for diagnostics. The correct error is found, but so are all of the other errors that result from the outer blocks. It looks like TRANSCODE without /error is returning the last error discovered, not the first. This should be an easy fix.

Note: Added to the example code rather than here due to the lack of indent handling for code snippets in comments.
(0002318)
Carl
5-May-2010 21:05

This is a very basic problem in the /error refinement and not an easy fix (because it's related to block nesting.)

TRANSCODE without /error returns the correct error. But, with /error, TRANSCODE is not exiting correctly from an error in a sub-block.

;; Ok:
>> transcode to-binary {["test^/]}
** Syntax error: invalid "string" -- {"test} ; correct error

;; Ok:
>> transcode/error to-binary {"test^/}
== [make error! [
code: 200
type: 'Syntax
id: 'invalid
arg1: "string"
arg2: {"test}
arg3: none
near: {(line 1) "test}
where: [transcode]
] #{0A}]

;; Problem:
>> transcode/error to-binary {["test^/]}
(0002327)
BrianH
6-May-2010 02:41

The problem is that it's the behavior of TRANSCODE that is a problem; TRANSCODE/error is fine, and returns valuable information to those who need it. However, it would be best if when TRANSCODE triggers an error, it would trigger the first error it generates, not the last.

I don't consider this to be a high priority at this point unless it is an easy fix. The behavior of TRANSCODE and TRANSCODE/error that the mezzanine code relies on works great, particularly the LOAD function. Not returning the right error on TRANSCODE isn't such a high priority when you can just double-check with TRANSCODE/error.
(0002521)
Carl
22-Sep-2010 00:41

Fixed in A108 -- watch out for for side effects.

Date User Field Action Change
20-Oct-2010 03:36 BrianH Status Modified built => tested
22-Sep-2010 00:41 carl Status Modified reviewed => built
22-Sep-2010 00:41 carl Fixedin Modified => alpha 108
22-Sep-2010 00:41 carl Comment : 0002521 Added -
6-May-2010 02:43 BrianH Comment : 0002327 Modified -
6-May-2010 02:41 BrianH Comment : 0002327 Added -
5-May-2010 21:13 carl Comment : 0002318 Modified -
5-May-2010 21:07 carl Comment : 0002318 Modified -
5-May-2010 21:06 carl Code Modified -
5-May-2010 21:05 carl Comment : 0002318 Added -
4-May-2010 21:27 BrianH Code Modified -
4-May-2010 21:26 BrianH Code Modified -
4-May-2010 21:24 BrianH Comment : 0002308 Modified -
4-May-2010 21:22 BrianH Status Modified submitted => reviewed
4-May-2010 21:22 BrianH Code Modified -
4-May-2010 21:22 BrianH Comment : 0002308 Modified -
4-May-2010 21:21 BrianH Comment : 0002308 Added -
4-May-2010 20:15 carl Ticket Added -