This chapter gives explanation for compiler diagnostics. For each error, an error number is provided along with a text of error message and an explanation. An error message can contain a format specifier in the form %d for a number or %s for a string. In this case, an argument (or arguments) is described on the next line.
In most cases the compiler prints a source line in which the error was found. The position of the error in the line is marked with a dollar sign placed directly before the point at which the error occurred.
All characters within the Modula-2 or Oberon-2 character sets are acceptable. Control characters in the range 0C to 37C are ignored. All other characters, e.g. % are invalid.
This error is reported if a closing comment bracket is omitted for a comment started at the given line.
This error is reported in the following cases:
This error usually occurs if a closing quote is omitted or does not match the opening quote. Note that a string literal is limited to a single line and its size cannot exceed 256 characters. In Modula-2, string concatenation may be used to build long literal strings.
Input file ends before end of a module.
Length of an identifier exceeds compiler limit (127 characters).
A read error occurs while reading source text.
The meaning of this message is obvious.
This error is reported if a structure of conditional IF statements is broken, e.g. there is no IF for an END, ELSE, or ELSIF clause or there is no END for an IF.
IF, ELSIF, ELSE, END or identifier expected.
This error is reported if a closing bracket "*>" is omitted for a pragma started at the given line.
Input file ended while the compiler was skipping source text according to the conditional compilation statement. It may be a result of a missed <* END *> clause. Check the pragma at the given line.
Check the manual for the pragma syntax.
The compiler expects an identifier at the indicated position.
The compiler expects the given symbol at the indicated position. The symbol may be one of the following:
| ; : . [ ] := ( ) { } , = .. DO END OF THEN TO UNTIL IMPORT MODULE
The compiler expects start of factor at the indicated position, i.e. an identifier, literal value, aggregate, left parenthesis, etc. See the syntax of the language for more information.
The compiler expects start of declaration at the indicated position, i.e. one of the keywords: "CONST", "VAR", "TYPE", "PROCEDURE", "BEGIN", or "END".
The compiler expects start of a type at the indicated position. See the syntax of the language for more information.
The compiler expects expression at the indicated position.
The compiler expects start of a statement at the indicated position. See the syntax of the language for more information.
The given identifier has no definition in the current scope.
An identifier being declared as a type shall not be used in declaring that type, unless that type is a new pointer type or a new procedure type. This error will be reported for the following example
TYPE Rec = RECORD next: POINTER TO Rec; END;
use the following declarations instead:
TYPE Ptr = POINTER TO Rec; Rec = RECORD next: Ptr; END;
An identifier being declared is already known in the current context (the name used has some other meaning). If a file name and text position of previous definition are known, the compiler reports error 022 otherwise 028.
A forward declaration of a procedure is followed by a declaration of a code procedure.
A module imports itself. Example:
MODULE xyz; IMPORT xyz; END xyz.
An object exported from a local object is not defined there. Example:
MODULE M; (* local module *) EXPORT Foo; END M;
An identfier cannot be used in its own declaration, like in:
CONST c = 1; PROCEDURE proc; CONST c = c + 1; END proc;
An identifier denoting module cannot be used at the indicated position.
The compiler reports this error in the following cases:
The compiler reports error 29 if it can display incompatible types and error 30 otherwise.
An identifier denoting a type is expected at the indicated position.
The compiler expects a scalar type (real, integer, cardinal, range, enumeration, CHAR, or BOOLEAN).
The compiler expects a value, variable, or type designator of ordinal type, i.e. CHAR, BOOLEAN, enumeration, integer, or cardinal type or a subrange of one of those types.
According to the language definition this combination of parameters in a call of the standard procedure VAL is not valid.
A call to NEW is treated as a call to ALLOCATE (or DYNALLOCATE for open arrays). The required procedure is not visible in this scope. It must be either imported or implemented.
Note: In XDS, the default memory managemet routines may be enabled by setting the STORAGE option ON.
A call to DISPOSE is treated as a call to DEALLOCATE (or DYNDEALLOCATE for open arrays). The required procedure is not visible in this scope. It must be either imported or implemented.
Note: In xds, the default memory managemet routines may be enabled by setting the STORAGE option ON.
In Modula-2, calls of NEW and DISPOSE are substituted by calls of ALLOCATE and DEALLOCATE (for dynamic arrays by calls of DYNALLOCATE and DYNDEALLOCATE). The error is reported if one of those procedures is declared as a function.
In Modula-2, calls of NEW and DISPOSE are substituted by calls of ALLOCATE and DEALLOCATE (for dynamic arrays by calls of DYNALLOCATE and DYNDEALLOCATE). The error is reported if a number of parameters in the declaration of a substitution procedure is wrong.
In Modula-2, calls of NEW and DISPOSE are substituted by calls of ALLOCATE and DEALLOCATE (for dynamic arrays by calls of DYNALLOCATE and DYNDEALLOCATE). The error is reported if the kind (variable or value) of the given parameter in the declaration of a substitution procedure is wrong.
In Modula-2, calls of NEW and DISPOSE are substituted by calls of ALLOCATE and DEALLOCATE (for dynamic arrays by calls of DYNALLOCATE and DYNDEALLOCATE). The error is reported if a type of the given parameter in the declaration of a substitution procedure is wrong.
In an Oberon-2 type test (v IS T) or type quard (v(T)), T should be an extension of the static type of v.
A type cannot be a result type of a function procedure (language or implementation restriction).
A result type of a procedure does not match those of a forward definition or definition of an overriden method.
Open arrays (ARRAY OF) usage is restricted to pointer base types, element types of open array types, and formal parameter types.
The number of actual parameters in a procedure call is less than the number of formal parameters.
The number of actual parameters in a procedure call is greater than the number of formal parameters.
The only valid types of a sequence parameter are SYSTEM.BYTE and SYSTEM.LOC.
The compiler expects an object of the given type at the indicated position.
The compiler expects a variable (designator) at the indicated position.
The compiler expects a procedure designator at the indicated position.
A call of a super method (type-bound procedure bound to a base type) is valid only in a redifinition of that method:
PROCEDURE (p: P) Foo; BEGIN p.Foo^ END Foo.
In a call of a super method (type-bound procedure bound to a base type) p.Foo^ either Foo is not defined for a base type of p or there is no base type.
The Oberon-2 compiler reports this error in the following cases:
In Oberon-2, a pointer base type must be an array or record type. For instance, the declaration TYPE P = POINTER TO INTEGER is invalid.
The second parameter of the LEN function is either negative or larger than the maximum dimension of the given array.
The Oberon-2 compiler reports this error in the following cases:
A base type of an open array aggregate (ARRAY OF T{}) cannot be a record or array type.
A procedure bound to a record type should be declared in the same module as the record type.
A receiver type for an exported type-bound procedure should also be exported.
The receiver parameter of this type-bound procedure is of a pointer type, hence it cannot be called from a designator of a record type. Note that if a receiver parameter is of a record type, such type-bound procedure can be called from a designator of a pointer type as well.
A mode of receiver type in a type-bound procedure redefinition does not match the previous definition.
A (object of) non-Oberon type (imported from a non-Oberon module or declared with direct language specification) cannot be used in specific Oberon-2 constructs (type-bound procedures, type guards, etc).
A type-bound procedure for an extended type is defined before a type-bound procedure with the same name for a base type.
A redefined type-bound procedure should be exported if both its receiver type and redefining procedure are exported.
A function procedure has no RETURN statement and so cannot return a result.
The compiler expects an expression at the indicated position.
Standard functions SIZE and TSIZE cannot be used to evaluate size of an open array designator or type in the standard mode. If language extensions are enabled, the compiler allows to apply SIZE to an open array designator, but not type.
The compiler cannot evaluate this expression at compile time. It should be constant according to the language definition.
An identifier at the end of a procedure or module does not match the one in the procedure or module header. The error may occur as a result of incorrect pairing of ENDs with headers.
An exported procedure or forward procedure is not declared. This error often occurs due to comment misplacement.
A function is called as a proper procedure. It must be called in an expression. A function result can be ignored for procedures defined as "C", "Pascal", "StdCall" or "SysCall" only. See Direct language specification.
A proper procedure is called in an expression.
The error is reported for a language feature that can not be used in definition module, including:
The error is reported for a language feature that can be used in definition module only, i.e. read-only variables and record fields (extended Modula-2).
The error is reported for a language feature that can be used only in the global module scope, including:
An opaque type declared in a definition module must be elaborated in the implementation module.
A type T can be introduced in a declaration of a pointer type as in:
TYPE Foo = POINTER TO T;
This type T must then be declared at the same scope.
The error is reported for a language feature that can be applied to value parameter only (not to VAR parameters), such as a read-only parameter mark.
In Oberon-2, the RETURN statement is not allowed in a module body.
In Oberon-2. all constants, types and variables in one declaration sequence must be declared before any procedure declaration.
The error is reported for a language feature that can be used only if language extensions are switched on. See options M2EXTENSIONS and O2EXTENSIONS.
The error reported if a value of a (constant) expression cannot be negative, including:
A forward type T (declared as TYPE Foo = POINTER TO T) cannot be elaborated as an opaque type, i.e. declared as TYPE T = <opaque type>).
Wrong number of elements in an array constructor.
A repetition counter in an array constructor must be of a whole number type.
The error is reported if a record constructor does not contain an expression for the given field.
The error is reported if a record constructor for a record type with variant part does not have a variant for the given value of a record tag and the ELSE clause is omitted.
A type-bound procedure has the same name as a field already declared in that type or one of its base types.
The given field is not exported, put export mark into the declaration of the record type.
A record type can be defined as an extension of another type, only if it is an Oberon-2 record type.
A record with variant parts cannot be declared as an Oberon-2 record.
This is considered an error because garbage collector does not trace non-Oberon records and reference to an object may be lost.
A type designator cannot be used in a statement position.
A value which can be checked at compile-time is out of range.
A designator marked as read-only cannot be used in a position where its value may be changed.
A lower bound of a range is greater than high bound.
An EXIT statement specifies termination of the enclosing LOOP statement. This EXIT is not within any LOOP.
In a CASE statement all labels must have different values. The label at the indicated position is alfeady used in this CASE statement.
A control variable of a FOR loop must be declared locally in the procedure or module which body contains the loop.
In a record constructor there are more expressions than there are fields in the record type (or in this variant of a variant record type).
In a FOR statement, the step cannot be equal to zero.
If language extensions are OFF, the standard procedure HIGH can be applied to open arrays only, otherwise to any array designator.
The compiler restricts length of a base type of set (MAX(base)-MIN(base)+1). Note, that the limit does not depend on the low bound, so the following set types are valid:
SET OF [-256..-5]
SET OF [MAX(INTEGER)-512..MAX(INTEGER)]
The compiler expects a parameter of this standard procedure to be a value of an unsigned type.
The compiler expects a parameter of this standard procedure to be a value of a pointer type. Note: the SYSTEM.ADDRESS type is defined as POINTER TO LOC.
The compiler expects a parameter of this standard procedure to be a type designator.
The compiler must know the size of a value in the given context. A numeric constant cannot be used at the indicated position.
The ISO standard requires an "entire designator" in this context, e.g. as a parameter of the SIZE function. It may be either a variable (which may be a formal parameter) or a field of a record variable within a WITH statement that applies to that variable.
Oberon compilers from ETH implements so-called interrupt procedures, marked by the symbol "+".
PROCEDURE + Foo;
In XDS, this feature is not implemented.
A Modula-2 opaque type cannot be elaborated as an Oberon-2 pointer. See Chapter Multilanguage programming.
The compiler reports this error for language features that are vaild in Modula-2 but not in Oberon-2, including:
In an Oberon-2 type test v IS T or a type guard v(T), both v and T must be either pointers or records.
According to ISO Modula-2, a control variable in a FOR statement cannot be a formal parameter (either VAR or value).
A variable used as a control variable in a FOR statement or an Oberon-2 WITH statement cannot be exported.
A control variable of a FOR statement or an Oberon-2 WITH statement has been threatened inside the body of the statement, or in a nested procedure called from the body. Threatening actions include assignment and passing as a VAR parameter to a user-defined or standard procedure (ADR, INC, DEC, etc). The compiler also reports the error 158 to indicate the exact place of threatening.
A procedure body can not contain a finalization part.
This RETRY statement is outside an exceptional part of a block.
A value must be either one of the strings ("Modula", "Oberon", "C","Pascal", "SysCall", or "StdCall") or the corresponding integer value. We recommend to use strings, integer values are preserved for backward compatibility.
The compiler expects a variable of an integer type.
Two procedure types have different calling conventions. The error can reported in the following cases:
A procedure heading must have the same number of parameters, the same parameter modes (variable or value) and the same types as in the previous declaration. A previous declaration may be one of the following:
The compiler reports error 154 if it can show incompatible types and error 155 otherwise.
A designator which appears to be called (e.g. Foo(...)) does not denote a procedure.
A control variable of a FOR statement or an Oberon-2WITH statement is threatened at the indicated position. It means that its value may be changed. See also error 147.
An object which appears to be an aggregate (e.g. Foo{...}) begins with an identifier which is not a set, record, or array type.
Only one special kind of variable parameter is implemented: VAR [NIL]. It means that NIL may be passed to this parameter.
A parameter of the SYSTEM.VALID function must be a VAR [NIL] parameter.
This error is reported for a wrong setting of ALIGNMENT, ENUMSIZE, or SETSIZE equation.
A control variable of a FOR statement cannot be marked as volatile. See the VOLATILE option.
This language feature is not implemented yet.
This error is to be reported if a real overflow (underflow) occurs during evaluation of a constant expression.
The compiler uses 64-bits (signed) arithmetics for whole numbers. The error is reported if an overflow occurs during evaluation of a constant expression. In the following example, an error will be reported for the assignment statement, while constant definition is valid.
MODULE Test; CONST VeryBigConstant = MAX(CARDINAL)*2; (* OK *) TooBigConstant = VeryBigConstant*VeryBigConstant; (* OK *) END Test.
The second operand of a DIV, MOD, REM, or "/" operator is zero.
The array length is either negative or exceeds implementation limit.
The error is reported if a case select expression can be evaluated at compile-time and there is no variant corresponding to its value, and the ELSE clause is omitted. If not constantly evaluated, this CASE statement would cause the caseSelectException exception at run-time.
The compiler (more precisely, run-time support) puts a limit on the number of nested open array types (or dimensions). Note, that there is no limit for arrays with specified length, because such arrays do not require special support in run-time system.
The run-time system puts a limit on the level of record extensions. It is required for efficient implementaion of type tests and type guards.
The compiler puts a limit on the number of procedures nested inside each other. When modules are nested inside procedures, only the level of procedure declarations is counted.
A type-bound procedure cannot be assigned to a variable of procedure type.
A procedure local to another one cannot be assigned to a variable of procedure type.
A code procedure and external procedure cannot be assigned to a variable of procedure type.
A symbol file for the given module is corrupted. Recompile it.
The given symbol file is generated by a different version of the compiler. Recompile the respecitve source or use compatible versions of the compiler and/or symbol file.
The error occurs if an interface of some module is changed but not all its clients (modules that imports from it) were recompiled. For example, let A imports from B and M; B in turn imports from M:
DEFINITION MODULE M; DEFINITION MODULE B; MODULE A; IMPORT M; IMPORT M,B; END M. END B. END A.
Let us recompile M.def, B.def and then M.def again. The error will be reported when compiling A.mod, because version keys of module M imported through B is not equal to the version key of M imported directly.
To fix the problem modules must be compiled in appropriate order. We recommend to use the XDS compiler make facility, i.e. to compile your program in the MAKE or PROJECT operation mode. If you always use the make facility this error will never be reported.
The Oberon-2 compiler creates a temporary symbol file every time a module is compiled, compares that symbol file with the existing one and overwrites it with the new one if necessary. When the CHANGESYM option is OFF (by default), the compiler reports an error if the symbol file (and hence the module interface) had been changed and does not replace the old symbol file.
Note: if the M2CMPSYM option is set ON, the same applies to compilation of a Modula-2 definition module, i.e., the CHANGESYM option should be set if the module interface has been changed.
A module name used in an IMPORT clause must be equal to the actual name of the module, written in the module heading.
The symbol file for the given module is generated by another XDS compiler. Native code compilers can read symbol files generated by XDS-C on the same platform, but not vice versa.
This section lists internal compiler errors. In some cases such a error may occur as a result of inadequate recovery from previous errors in your source text. In any case we recommend to provide us with a bug report, including:
In many cases a warning may help you to find a bug or a serious drawback in your source text. We recommend not to switch warnings off and carefully check all of them. In many cases warnings have helped us to find and fix bugs very quickly (note that XDS compilers are written in XDS Oberon-2 and Modula-2).
Warnings described in this section are reported by both XDS-C and Native XDS. Each of these products may report additional warnings. Native XDS compilers fulfil more accurate analysis of the source code and report more warnings.
This variable is of no use, it is not exported, assigned, passed as a parameter, or used in an expression. The compiler will not allocate space for it.
This parameter is not used in the procedure.
The current version of the compiler does not report this warning.
This procedure is not exported, called or assigned. The compiler will not generate it.
This warning is reported if a value of the variable may be undefined at the indicated position. Note, that it is just a warning. The compiler may be mistaken in complex contexts. In the following example, "y" will be assigned at the first iteration, however, the compiler will report a warning, because it does not trace execution of the FOR statement.
PROCEDURE Foo; VAR x,y: INTEGER; BEGIN FOR x:=0 TO 2 DO IF x = 0 THEN y:=1 ELSE INC(y) (* warning is reported here *) END; END; END Foo;
This warning is not reported for global variables.
The current version of the compiler does not report this warning.
Execution of this loop (LOOP, WHILE or REPEAT) will not terminate normally. It means that statements after the loop will never be executed and the compiler will not generate them. Check that the loop was intentionally made infinite.
This code cannot be executed and the compiler will not generate it (dead code elimination). It may be statements after a RETURN, ASSERT(FALSE), HALT, infinite loop, statements under constant FALSE condition (IF FALSE THEN), etc.
It may be a loop like
FOR i:=1 TO 1 DO ... END;
or
LOOP ...; EXIT END;
Check that you wrote it intentionally.
The compiler was able to determine the run-time value of the given variable (due to constant propagation) and will use it instead of accessing the variable. For the following example
i:=5; IF i = 5 THEN S END;
the compiler will generate:
i:=5; S;
This warning is not reported for global variables.
The compiler knows that a value of a pointer variable is NIL (due to constant propagation), e.g:
p:=NIL;
p^.field:=1;
The code will be generated and will cause "invalidLocation" exception at run-time.
This warning is not reported for global variables.
This warning is reported in order to simplify porting your program to other Modula-2 compilers.
A variable parameter of a pointer type is used as a control variable in an Oberon-2 WITH statement. The compiler cannot check that it is not changed inside WITH. In the the following example "ptr" and, hence, "p" becomes NIL inside WITH:
VAR ptr: P; PROCEDURE proc(VAR p: P); BEGIN WITH p: P1 DO ptr:=NIL; p.i:=1; END; END proc; BEGIN proc(ptr); END
We recommend to avoid using variable parameters of pointer types in WITH statements.
The FOR statement is redundant (and not generated) if its low and high bounds can be evaluted at compile-time and it would be executed zero times, or if its body is empty.
An undeclared option is used. Its value is assumed to be FALSE.
An undeclared equation is used. Its value is undefined.
The option (equation) is already defined, second declaration is ignored.
The syntax used is obsolete. The next release of the compiler will not understand it. We recommend to rewrite the clause using the new syntax.
This warning is reported if a program fragment does not influence to the program execution, e.g:
i:=1;
i:=2;
The first assignemnt is redundant and will be deleted.
The same as W900, but the redundant code is preserved because it can raise an exception, e.g.:
i:=a DIV b; (* raises exception if b <= 0 *)
i:=2;
The warning is reported if a boolean condition can be evaluated at run-time, e.g.
IF (i=1) & (i=1) THEN (* the second condition is TRUE *)
or
j:=2;
IF (i=1) OR (j#2) THEN (* the second condition is FALSE *)
The compiler ignores function result, like in:
IF Foo() THEN END;
A warning from this group is reported if the compiler determines that the exception will be raised in the code corresponding to this program fragment. In this case the fragment is omitted and the compiler generates a call of a run-time procedure which will raise this exception.
This section describes errors reported by a native code generator (back-end). The code generator is invoked only if no errors were found by a language parser.
The compiler cannot generate your module. Try to increase COMPILERHEAP or try to compile this module separately (not in the MAKE or PROJECT mode). Almost any module may be compiled if COMPILERHEAP is set to 16MB. Exceptions are very big modules or modules containing large procedures (more than 500 lines). Note that the amount of memory required for the code generator depends mostly on sizes of procedures, not of the module.
The compiler cannot generate this expression, it is too complex. Simplify the expression.
The compiler cannot generate this type conversion.
The compiler have to generate a type cast which may be unportable. Check that the generated code is correct or pay some attention to your C compiler warnings.
Options NOHEADER and ??? have meaning only for modules defined as "C", "StdCall" or "SysCall". See Direct language specification
The generated code contains a dependance cycle. It means that some declaration A depends on B and vice versa. It is not an error. The generated code may be valid.