FWD » Core Development » Base Language

The following testcase shows the limits of this ambiguity.

From the header:

/* date literals can use a . (and -) as a separator; this can occur in ways that */
/* overlap with decimal usage (the same literal input can be both a date and a */
/* decimal; this testcase explores the limits of this behavior */

/* Months: */
/* can't just specify the month */
/* have to be between 1 and 12 inclusive */
/* can be zero padded, there seems to be no practical limit so this is probably dropped */
/* for literals, is always in the first (leftmost) position, no matter what the SESSION:DATE-FORMAT */

/* Days: */
/* have to be between 1 and the highest day of the corresponding month inclusive */
/* can be zero padded, there seems to be no practical limit so this is probably dropped */
/* for literals, is always in the second (middle if there is a year) position, no matter what the SESSION:DATE-FORMAT */

/* Year: */
/* this is optional */
/* for literals, is always in the third (last) position, no matter what the SESSION:DATE-FORMAT */
/* if present, then the date cannot be confused with a decimal literal, so we aren't testing those cases here */

/* most importantly: these "special" date forms can only be used inside a variable */
/* definition initializer!  when encountered in regular code, they are exclusively */
/* treated as decimal literals */

Updated version of the testcase plus the prepared fixes which are going into conversion testing now.

The core solution is about disabling date literal processing in these cases of a DIGITS.DIGITS- and always making it a decimal literal. Then in the var def initializer processing, we detect when this is a date var and we rewrite the decimal literals to be date literals.

Please note that this also includes many other fixes for date, num and dec literal processing. Included are improvements to removing zero padding like the 4GL does and better handling of 64-bit literals.

Fixed a stupid indexing error. Going back into conversion testing.

Another silly mistake, I didn't properly exclude num literals from the trailing zero removal. This updated version is back in conversion testing. I don't expect further problems.

How many times am I going to be wrong today? Majic compiled fine with the c update but there are still many unwanted removals of zero padding. This version resolves those cases. It has gone back into conversion testing.

Final version going through conversion testing now. There was an issue with removal of zeros from the year portion of a date (it affected 1 place in Majic).

Fix for empty string used as a date var initializer. It is being conversion tested now.

The only remaining problem was with char field initializers, which were not handled (it was parsers fault). The notes 113, 114, 116,199 in #2068:
- CA:

One more issue related to initializers. Following is valid in 4GL:

def temp-table tt1 field f1 as char init 0.

The places where we "coerce" incompatible types that are used in initializers are in:
1. progress.g in the initializer_constant rule
2. Variable.booleanManhandle()

- CA:

Actually, there is another place where this is done, for character variables: in fixups/variable_initializers. I've tested the date/int/dec/log/char cases (in both fields and vars) and the only problem was to char fields. The solution is to fix the progress.g's initializer_constant rule, to enclose the literal in quotes, if this is a char and the literal is not string or unknown_val. With this, we can remove the fixups in variable_initializers.

I'm putting this through conversion regression testing.

Correct, good letter, wrong date. Attached is the good one.