[ivy]<Satterthwaite>clrm>CompilerMessagesDoc.tioga!1

CompilerMessagesDoc.tioga
Satterthwaite, January 7, 1986 10:14:34 am PST
COMPILER ERROR MESSAGES
CEDAR 6.0 — FOR INTERNAL XEROX USE ONLY
Compiler Error Messages
What the compiler is really trying to tell you
Ed Satterthwaite
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: An attempt to provide some aid and comfort in interpreting the error messages produced by the compiler.
Created by: Ed Satterthwaite
Maintained by: Ed Satterthwaite <Satterthwaite.pa>
Keywords: Cedar, Compiler, Errors
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
1. Introduction
1.1. Using this Document
This document lists all the error messages generated by the current (January 1986) version of the Cedar compiler. In most cases, it also provides an explanatory note that goes beyond the rather cryptic text appearing in the message itself or gives hints about unobvious ways of provoking the error.
The remainder of this section provides a little information about how the compiler is organized and the consequences for error reporting and recovery. Section 2 briefly discusses lexical and syntactic errors, and section 3, which is the meat of this note, documents so-called semantic errors. Section 4 can be treated as an Appendix. It provides some background on the view of types taken by the once proposed Cedar Kernel language. Whether or not you like this view, the compiler is increasingly using it internally, so some familiarity with it will help you understand some common kinds of type errors and how they are reported.
The strategies used in the Cedar compiler for reporting and recovering from errors will continue to evolve over time. Major changes will result in new versions of this document. Your feedback can help too; let me know of your frustrations and wishes in this area.
1.2. Phase Structure and Error Recovery
The Cedar compiler is organized as five phases (six counting a final phase that just writes the BCD file). If you run the compiler locally, you will probably notice some kind of feedback window in which a sequence of dots appears to indicate the progress of the compilation. One dot appears as each phase is started. Lexical and syntactic errors are detected by the first phase. Most semantic errors are found in the third phase, but some are detected by all the other phases as well.
Errors are reported on a phase-by-phase basis; currently, there is no collation of messages issued by different phases. Thus all messages about syntax errors appear before, e.g., messages about type mismatches. The compiler attempts to report errors as early as possible and to maximize the amount of useful information per attempted compilation. It does not always succeed. Currently, the strategy is to continue through phase 3 unless phase 1 detects a syntactic error for which it cannot find an acceptable recovery. Thereafter, compilation terminates after any phase that detects an error.
The compiler will not generate code for a program in which it finds errors. In that situation, it will not create a new BCD file and will make its best effort to delete any existing BCD files with the same name.
Caution: If such a BCD file is locked, it won't be deleted. Thus it's possible to have a valid BCD file corresponding to some older version of the source even after an attempted compilation of the current version has failed.
1.3. Compiler Failures
If you compile big programs, you will probably run out of storage from time to time. The message reporting this has the following form:
Storage overflow in Pass <n>
There are a few tricks for getting a program that is near the borderline to compile without overflow; see a wizard if this seems vitally important to you. Otherwise, the best strategy is to split the offending module.
Either of the following messages indicates some sort of internal compiler error:
FATAL COMPILER ERROR
unimplemented construct
If you get one of these messages, please save the input and as much of the environment as possible and notify a compiler maintainer. Both messages indicate that the compiler has encountered an unexpected situation. In the case of a fatal error, the consistency of the compiler's code and global state is suspect; you should rollback before attempting further compilations.
2. Lexical and Syntactic Errors
These errors are detected by the first pass of the compiler and are reported as suggested by the following examples:
i ← j + 1%;
^ invalid character [163]
i, j: NAT,
^ syntax error [126]
Text deleted is: ,
Text inserted is: ;
In each case, the error log contains the text of the offending line, a pointer (^) to the offending position within the line, and the index in the source file of the character in that position. Unfortunately, the ^ will seldom align correctly unless you are using a fixed-pitch font to view the error log; however, you can use the Position command in Tioga's Places submenu to scroll to and select the character corresponding to the index.
Hint: Since editing will change the absolute indices of characters, it's easier to deal with multiple errors if you work through the error log from back to front.
A lexical error occurs when the compiler cannot convert the input stream to a sequence of valid tokens. The following lexical errors are currently recognized:
invalid numberill-formed or too large for 32 bits
string unterminated or too longmaximum length is 2000 characters
invalid character
invalid atomfollowing "$"
invalid escape sequencefollowing "\"
The compiler recovers by ignoring an invalid character or the internal structure of an invalid literal.
A syntax error occurs when the compiler cannot accept the next token of the input stream as part of a syntactically correct program. The compiler attempts to recover by deleting and/or inserting tokens in the vicinity of the error until the insertions and a reasonable number of additional tokens from the input stream are the prefix of a valid program. The insertions and deletions are reported as part of the error message. The compiler does not attempt to evaluate the semantic plausibility of such a prefix. There are a few pecuiliarities of the Cedar language, such as the notation for discriminated record types and for subrange types, that sometimes allow a highly implausible recovery and create a cascade of subsequent errors. In such cases, it's often most productive to fix the first error and recompile.
Caution: For historical reasons, the compiler ignores any text following a well-formed program. This can cause strange behavior when the sequence "END ." or its equivalent is misplaced.
3. Semantic Errors
These errors are reported as suggested by the following example:
k is undeclared, at Test[170]:
i ← j + k;
The error log displays the text of the line containing the start of the offending construct. The number in brackets is an index in the source file. In most cases, it's the index of the first token in the smallest declaration or statement containing the error. This is not terribly helpful when the error occurs inside a very long expression.
As indicated in the list that follows, many messages begin with a reconstructed version of some Cedar expression (e.g, "k" in the example above). The reconstruction is done by unparsing an intermediate representation. The second and third passes of the compiler try not to lose information and can usually report errors in terms of the original source code, perhaps with some embellishment or canonicalization. Later passes attempt a certain amount of compile-time evaluation and optimization that can lose structure; it's unfortunately not too uncommon for the fourth pass to report an offending value in terms of its internal representation, expressed as a decimal or octal number.
The unparser does not fully expand deeply nested expressions; omitted subexpressions are indicated by "...". There are also a few constructs not currently handled by the unparser; the reconstructed text is either missing or is replaced by "..." in these cases.
Warning messages begin with the character string "warning: ". The next two subsections list all the error and warning messages respectively. Within each subsection, the order is alphabetical according to the first non-bracketed, non-blank character of the message. The portions of the message that appear within brackets (<...>) are replaced by unparsed text as explained above and vary from instance to instance of the message.
3.1. Errors
attempt to access private fields
In a constructor or extractor, even if the fields aren't mentioned and have defaults.
Alternatively, discriminating a variant record with a private tag field or locking a MONITORED record with a private lock field. Note that the lock field is declared implicitly and inherits the default visibility attribute of the record type.
body or catch phrase nested too deeply
Nesting depth exceeds 15, where the depth is 1 at the module level and increases by one for each (non-inline) procedure body or catch phrase.
Note: This error can be triggered by the expansion of an inline procedure containing local procedure declarations or catch phrases.
<id> cannot be defaulted
Omitted keyword in a keyword constructor, but the corresponding field has no default value.
<id> cannot be defaulted or voided
Omitted expression in a positional constructor or argument list, but the field in the corresponding position does not allow a default. The identifier is the field name and is omitted for anonymous fields or array components.
<id> cannot be opened
BCD file containing the included module cannot be opened, usually because it cannot be found in the current working directory. Alternatively, the file was found but does not have the internal passwords used by the compiler for validity checks (file incomplete, damaged, or produced by an older and incompatible version of the compiler).
An included module can reference other modules not explicitly mentioned in the DIRECTORY of the program being compiled. In some circumstances, the compiler must access such an implicitly included module and will attempt to open it, possibly failing with this message. The circumstances requiring such access are not easy to characterize precisely. Usually, the compiler needs information about the internal structure of an enumeration or record type defined in the implicitly referenced module.
This error frequently has the unfortunate side effect of producing a cascade of messages about undefined and misused identifiers.
<id> cannot have a specified position
Explicitly specified field positions are used in defining a record type that is not declared to be MACHINE DEPENDENT.
compilation aborted
User-requested abort. Compilation terminates cleanly between phases.
default return of anonymous value
An explicit RETURN or RESUME that defaults the returned values to be the formal result variables, when those variables are unnamed and have undefined values. Alternatively, an implicit RETURN at the end of a procedure with such formal result variables.
Note: The compiler suppresses this message for an implicit RETURN if it can discover that such a RETURN is unreachable. Its flow analysis is incomplete and conservative; sometimes this message appears because the compiler has not recognized that a case analysis is exhaustive (put an ERROR on the ENDCASE to fix this), that a loop cannot terminate normally, etc.
<expr> does not allow an argument list
But is followed by a bracketed list of expressions.
<expr> does not allow indirect reference
Does not designate a variable and cannot be used as the operand of @ or similar operator. Alternatively, designates an unaligned record field or a packed array element, for which the implementation does not support explicit address generation.
<id> does not name a variant
In the naming of a disciminated type, or as a case label in a discriminating SELECT.
<expr> exceeds addressing limits
If the expression is the identifier of a variable, that variable causes the size of a local frame to exceed 212-1 (4095) words. If the expression is a field name, that field causes the size of a record to exceed 212-1 (4095) words. Note that variables and fields are not necessarily allocated in lexical order.
If the expression is a procedure identifier, allocation of compiler generated temporaries for that procedure causes the size of a local frame to exceed 212-1 (4095) words. If the expression is a STRING literal, allocation of space for that string causes the overflow.
<expr> explicit selection not permitted
In a (non-copying) WITH ... SELECT discrimination, an explicit selector is supplied for a variant record that does not have a COMPUTED tag.
FATAL COMPILER ERROR
Internal consistency failure. See section 1.3. Rollback before attempting further compilations.
<id> found in wrong version
When the compiler requires a specific version of a BCD file.
For explicitly included modules, the compiler uses whatever version of the corresponding file is found in the working directory. An included module can reference other modules not explicitly mentioned in the DIRECTORY of the program being compiled. In some circumstances, the compiler must access such an implicitly included module and must find the exact version referenced. The circumstances requiring such access are not easy to characterize precisely. Usually, the compiler needs information about the internal structure of an enumeration or record type defined in the implicitly referenced module.
Currently, there is no good way of finding the chain of dependencies that leads to a particular implicit reference. In puzzling cases, you or, more likely, a wizard can use the SymbolLister in a rather awkward and painful way to get this information. Listing the symbols of the explicitly included modules (possibly iterating until closure) generates a list of all possible references and the reference paths.
<expr> has a size exceeding implementation limits
Assignment, comparison or allocation (using NEW) of an object with size exceeding 216-1 words. Alternatively, indexing of an array or sequence with components having a size exceeding 216-1 words.
<id> has a type illegal for a tag
Not an enumerated type for a variant tag, or not an index type for a sequence tag.
<expr> has a type with no <operator> operation
Operator missing from the cluster of the type. See section 4.
<expr> has an invalid default
Specifying a TRASH (NULL) default for a type that would inherit a default initial value not including TRASH as an alternative.
Alternatively, using the special form (bracketed expression) that allocates a STRING body as a default specification or as an initial value in NEW.
Alternatively, a formal result variable of an INLINE procedure that is unnamed but has a (non-TRASH) default initial value (implementation shortcoming).
<expr> has incorrect or ambiguous length
Usually, a LOOPHOLE to a type with a size not equal to the size of its operand, or an operation such as comparison on sequences or undiscriminated variant records in which different variants have different sizes.
Alternatively, assorted size problems, including
. an access to a variable or field with zero size (i.e., an empty subrange or array)
. a conditional expression in which not all alternatives have the same sizes
. incorrect size of a state vector (wizards only).
<expr> has incorrect type
Usually, a type that is not compatible with, and cannot be coerced to, some target type implied by the context. See section 4.
Note: The default safety attribute of a proc or signal type depends upon whether CEDAR appears in the header of the module defining the type; type constructors that look identical can differ in the value of this attribute and can cause puzzling instances of this message.
Alternatively, a long (32 bit) value as a test selecting a case arm, when the value of the corresponding case selector is short (Implementation shortcoming).
Alternatively, a catchall for assorted type errors including the following:
. a conditional expression in which the alternatives have incompatible types
. no NARROW operation for a value requiring narrowing to the target type
. a list constructor when the target type is not a list or REF ANY type
. extraction from a value that does not have a record type
. a catch label that does not have a signal or error type
. a qualifier of NEW or FREE that is not a zone
. a READONLY operand of FREE
. incorrect pairing of base and relative pointers
. OPEN of an object that does not have an interface or record type.
<id> has invalid field width or alignment
Violation of assorted restrictions in the definition of a MACHINE DEPENDENT record with explicitly specified field positions:
. a record bigger than a word but not an integral number of words
. a (non-variant) field bigger than a word but not an integral number of words or not word aligned
. a tag field not at the beginning of a variant or sequence part
. size of a variant part not equal to the size of the biggest variant
. size of a sequence part not equal to that of the sequence with zero items
. indexable part of a sequence not word aligned
<id> has no exportable value
An exported procedure with an INLINE body, or an exported variable with "=" initialization to a constant.
<expr> has no <operator> operation
Its value (a type) does not have the indicated attribute or operator in its cluster. See section 4.
<expr> has no variants
In a (non-copying) WITH ... SELECT discrimination, the selector does not designate a variant record.
<expr> has nonconstant value
In a context in which the language definition requires an expression with a value that can be computed statically by the compiler. Note that a default specified as part of a type (not procedure) declaration in a DEFINITIONS module must be constant.
Note: In an expression used as part of a subrange type definition or as the size of an opaque type, calls of INLINE procedures are not allowed. In other contexts, the expansions of such procedures are used in determining whether a value is constant, but you should not count on the compiler's eliminating any but the simplest forms of INLINE bodies.
<expr> has signed/unsigned ambiguity
Operands in the expression are neither both signed nor both unsigned (according to the rather arcane rules used by Cedar). Alternatively, a subrange or interval with such endpoints.
This is an error for those operators in which the resulting bit pattern is dependent upon the representation assumed (e.g., /, <); otherwise it is a warning.
<id> has unknown or ill-defined size
Declaration or allocation of a variable or field with a type having no well-defined size (e.g., a sequence or a size-unknown opaque type).
Alternatively, a recursive type definition or chain of definitions giving a type with indeterminate or impossible constraints on its size (e.g., by mentioning T.SIZE within the definition of T).
illegal index type
Use of a long (32 bit) index type in defining an array or sequence type (implementation shortcoming).
illegal initialization to body
Binding or assigning a procedure body to an identifier that does not have a proc type or that has a proc type with ANY as domain or range.
illegal initialization to MACHINE CODE
Binding a MACHINE CODE body to an identifier that does not have a proc type.
illegal REJECT or RESUME
Not within a catch phrase; alternatively, a RESUME in a catch phrase for ANY, for an ERROR, or for multiple SIGNALs with different types.
illegal RETURN
In a catch phrase or PROGRAM body; alternatively, RETURN WITH ERROR in a catch phrase.
illegal STOP
Not in a main PROGRAM body, or in a PROGRAM body that returns a result.
implicit system call
Use of a language primitive that is implemented by out-of-line code. This error is enabled only by the y compilation switch (for wizards only, and probably not even for them anymore).
improper use of an unsafe block
An UNCHECKED block as the body of a procedure with a SAFE type, as the arm of a catch phrase for a signal with a SAFE type, or as a statement in a CHECKED block.
Use TRUSTED if you want to suppress the compiler's checking in these situations. Note that the default safety attributes of proc types and the default checking attributes of blocks both depend upon whether CEDAR appears in the module header.
<id> improperly defined for a DEFINITIONS module
Initialization of a procedure to a body that is not INLINE, or initialization of a variable with ← or with an expression that does not have a constant value.
Alternatively, a named import, or a procedure declaration nested within an INLINE body.
incorrect discrimination
Various intermixings of features from the old (non-copying) and new (copying) forms of WITH ... SELECT discrimination.
index or interval type must be ordered
In defining an array or subrange type, or specifying an interval.
instruction has incorrect length
More than eight bytes grouped as a single instruction in a MACHINE CODE body (wizards only).
interval bounds are out of range
End points of nested subrange types don't nest; alternatively, the base type of subrange is REAL.
invalid attribute combination
Mutually incompatible attributes in a type constructor:
. MONITORED + MACHINE DEPENDENT
. SEQUENCE with * as a tag type
. OVERLAID SEQUENCE
. COMPUTED SEQUENCE, if components are reference-containing
<id> is a misused INTERNAL
Called from other than the body of an ENTRY or INTERNAL procedure, or forked within such a body.
<id> is ambiguous without discrimination
Use of a name that occurs in more than one arm of an OVERLAID variant record, when that use is outside a SELECT arm for a single variant.
<expr> is an improper control variable
Not a simple variable, or a simple variable declared in another module and imported.
<expr> is an incorrectly used inline
In an assignment or comparison requiring a proc value, as the alternative of a proc-valued conditional, in ← initialization, or in a LOOPHOLE.
Also, a fork of an INLINE procedure, or a call of one through a POINTER TO FRAME.
<id> is an unmatched implicit import
No principal instance of an implicitly imported interface when it is needed to bind objects (inlines or variables) imported indirectly by another imported interface. Either there are multiple explicitly imported instances of the needed interface, or there are none but adding the name of that interface to the IMPORTS list would create a name conflict. This situation can arise only when importing an interface that itself imports other interfaces and uses inlines, variables, etc. from them.
Alternatively, no principal instance of an interface when it is required by so-called object notation, because the number of explicitly imported instances of that interface is not exactly one.
Note: These errors arise from the interactions of some language misfeatures and some implementation shortcomings. If you are importing multiple instances of an interface and encounter problems, consult a wizard.
<expr> is being assigned out of scope
Into a variable that potentially outlives the nested procedure, signal or error (i.e., one declared within another procedure body). Alternatively, forking a nested procedure, or supplying a nested procedure as an argument of a forked procedure. These are flagged as errors in CHECKED regions only.
<expr> is discriminated unsafely
Old (non-copying) form of WITH ... SELECT discrimination applied to a reference-containing record. This is flagged as an error in CHECKED regions only.
<id> is exported with incorrect attributes
As a length-specified opaque type, when the concrete type has a default initial value or has a nonstandard implementation of assignment or equality (includes all REF and reference- containing types and most variant record types).
<id> is exported with incorrect SAFE attribute
For an exported value with a proc or signal type. Always accompanied by another message about exporting the name with incorrect type, even if the safety attribute is the only problem.
Note: The default safety attribute of such a type depends upon whether CEDAR appears in the header of the module defining the type; type constructors that look identical can differ in the value of this attribute.
<id> is exported with incorrect type
For an interface procedure, the type of the exported item is not compatible with the type of the interface item. For an interface variable, the type of the exported item is not equivalent to the type of the interface item. For an interface type, the type of the exported item is not TYPE.
Alternatively, a variable with "=" initialization exported to an item that is not READONLY, or an exported type that is itself opaque (implementation shortcoming).
<id> is followed by a gap
In the definition of a MACHINE DEPENDENT record type with explicitly specified field positions, the field does not extend to be contiguous with the next field or, for the last field, to the required alignment boundary.
<id> is INLINE and recursive
Discovered in the process of expanding the inline.
<id> is multiply defined
In a single declaration sequence or USING list.
Note that the formals, results, and outermost locals in a procedure body are considered a single declaration sequence for the purpose of this check. Also, the tag field in a variant record or sequence is considered part of the enclosing declaration sequence.
<id> is multiply defined
As labels in an EXITS or REPEAT clause.
Note that such names form a space entirely disjoint from the name space of normal declarations. See the manual for the details of the exact scope rules for these names.
<id> is not a legal variant tag
In the label of a variant case in a record type definition.
<id> is not a module name
The interface name specified in a DIRECTORY entry does not match the module identifier in the corresponding included file.
Note that the interface name to be matched is the one following "TYPE" in the DIRECTORY entry if that name is present; otherwise, the one preceding the colon.
<id> is not a type
Where the context demands a type.
<expr> is not a variable
Does not designate a variable and cannot be used as the destination of an assignment, as the operand of WAIT, NOTIFY or BROADCAST, or as a monitor lock.
<expr> is not address (@) of a variable
The FREE operation for a counted zone requires an address of a REF variable, explicitly generated using @, as its operand.
<expr> is not importable/exportable
A module importing or exporting itself, or a DEFINITIONS module importing a PROGRAM module.
<id> is not valid as a field selector
Following a dot.
This message often means that the identifier has been omitted from the corresponding USING list. Confusingly, the qualified procedure names in so-called object notation must appear in corresponding USING lists (if present), despite the fact that identifiers of record fields and the like must not.
Note: When referencing an included module, the compiler cannot always distinguish between names that are undeclared and those that are private. Also, a failure to open the BCD file containing an included module can give an unfortunate cascade of these messages.
<id> is not valid as a key
In a keyword constructor.
<id> is out of order
In the definition of a MACHINE DEPENDENT enumeration, the lexical order and the order implied by the representation specification are different.
<expr> is out of range
Compile-time bounds fault.
<id> is private
In the scope of an OPEN or in a field designator, constructor, extractor, etc. Alternatively, in the USING list for an included module.
<id> is repeated as a key
In a keyword constructor.
<id> is undeclared
In the current scope, or in the included module (for a USING clause), or in an enumeration (for $id as a literal). See the manual for details of the rather confusing scope rules applicable to ENABLE clauses, EXITS, etc.
This message often is a symptom of a mistake in a USING list or OPEN clause.
Note: When referencing an included module, the compiler cannot always distinguish between names that are undeclared and those that are private. Also, a failure to open the BCD file containing an included module can give an unfortunate cascade of these messages.
<id> is undeclared
As the destination of a GOTO.
Note that such labels constitute a naming space entirely disjoint from the name space of normal declarations. See the manual for the details of the exact scope rules for these labels
keywords not permitted
In various forms that look like procedure calls or record constructors but aren't (indexing, etc.).
<id> labels multiple variants
In the labels of multiple variant cases in a record type definition
<expr> lacks a tag needed for discrimination
Missing selector expression in discriminating a variant record with COMPUTED tag. Alternatively, narrowing such a record.
<id> leads to a circular type definition
Recursive type definition or chain of definitions gives a type with infinite size.
MACHINE CODE cannot be CHECKED
Use TRUSTED.
misplaced catch phrase
In various forms that look like procedure calls but aren't (indexing, constructors, etc.); alternatively, attached to RETURN WITH ERROR.
misplaced EXIT or LOOP
Not within DO ... ENDLOOP brackets (which must be within the same procedure body).
misplaced opaque type declaration
Not at the top level of a DEFINITIONS module.
misplaced RETRY or CONTINUE
In a declaration or an OPEN clause (where these forms are illegal).
misused DESCRIPTOR
In defining a type.
misused LONG
In defining a type.
misused RELATIVE
Base type is not a pointer type, or offset type is neither a pointer nor a descriptor type.
misused VAR
For other than the declaration of an exported variable in a DEFINITIONS module (where either VAR or READONLY is recommended).
mixed explicit and implicit field positions
In defining a record type.
Note: The positions of the variant part and its tag must be specified in a MACHINE DEPENDENT variant record if positions are specified for fields in the common part.
<expr> must be in MDS
Has an address involving a long pointer or ref (currently such an address is disallowed only for a PORT used in a coroutine transfer).
<id> must come from an imported interface
Procedure (including an INLINE) or variable is defined in an included module but is not taken from an imported instance of that module. Note that this can happen either because the module is not imported at all or because the interface type and instance are given different names by the IMPORTS clause and the former is used.
<expr> must have an interface type
In IMPORTS, EXPORTS or SHARES.
<expr> overflows
Compile-time overflow, using the same rules that would be used at runtime if there were complete runtime checking (which there isn't).
Note the interaction with the somewhat unfortunate language rules for lengthening operands. 256*256 overflows, even in a context that eventually requires a long number; 256.LONG*256 does not.
<id> overlaps another field
In the definition of a MACHINE DEPENDENT record type with explicitly specified field positions.
procedure used as a statement returns a value
Also for SIGNAL, JOIN, etc. Prefix "[ ] ←" to discard the value.
<id> required for lock
ENTRY or INTERNAL procedure does not have a formal parameter matching in name and type that of the formal specified in the LOCKS ... USING clause.
<id> requires a base value
Unqualified reference to a field of a record in the specification of a default initial value for a field or type defined within the same record type.
<id> requires an initial value
Declaration or allocation of a variable with a type that requires an explicit initial value.
<expr> requires explicit type
Because context does not supply enough target information for disambiguation (constructors, NARROW, VAL, etc.).
Anomaly: The constructor of a discriminated variant record requires pieces of the type identifier to appear in two different places. The undiscriminated type is written before the opening bracket of the entire constructor and can be omitted when implied by context. The identifier of the particular variant is written before the bracket opening the variant part and can never be omitted, even when it is implied by context.
Another anomaly: For VAL and ALL, you can't supply the type explicitly but must introduce and initialize a variable or use some similar artifice.
<expr> specifies an inadmissable test
In a WITH ... SELECT discrimination, the label of a case arm is not a literal or does not test for simple equality.
state vector has improper offset
State vector is not a local variable or was assigned too large an offset for the instructions that save and restore processor state (wizards only).
string literals not permitted in DEFINITIONS
Implementation shortcoming.
<number> too few elements in list
Usually in a positional argument list or constructor; alternatively, in the operand lists of assorted builtin operations that use funtion-like notation.
Note: The compiler will have used any available defaults to lengthen the list before issuing this message.
<number> too many elements in list
Usually in a positional argument list or constructor; alternatively, in the operand lists of assorted builtin operations that use funtion-like notation.
<number> too many exported variables
More than 64 variables exported from a single PROGRAM module.
<number> too many interface items
A total of more than 2048 (non-INLINE) procedures, signal, errors, variables and opaque types declared in a single DEFINITIONS module.
<number> too many procedure or signal definitions
More than 127 (non-INLINE) procedures or more than 128 signal and error CODEs declared in a single PROGRAM module.
type must be MACHINE DEPENDENT
Representation specifications are used in defining an enumerated type.
unimplemented construct
Internal consistency failure that leaves the compiler in a clean state. See section 1.3. Occasionally a side effect of previous errors.
Alternatively, attempted use of some partially implemented new features related to PAINTED and VAR types.
unmonitored ENTRY or INTERNAL
Not in a MONITOR.
unmonitored WAIT or NOTIFY
Not in the body of an ENTRY or INTERNAL procedure.
unrecognizable type constructor
Application of FRAME to a non-proc, non-program value, or compiler confusion (perhaps because of other errors).
<expr> uses an unsafe operation
Usually, calling an UNSAFE procedure or raising an UNSAFE signal. Alternatively, assorted constructs invoking unsafe builtin operations, including
. port call or JOIN
. indexing an array descriptor
. dereferencing a relative pointer
. loading or storing processor state (wizards only)
These are flagged as errors in CHECKED regions only. Note that the default safety attribute of a proc or signal type depends upon whether CEDAR appears in the header of the module defining the type.
<expr> uses an unsafe <operator> operation
Note that field selection, indexing or procedure application can force automatic dereferencing of the left operand. If such dereferencing is unsafe, the operator reported is the implicit ^. These errors are flagged in CHECKED regions only.
variable or field too large
A type with size greater than 228-1 words or 212-1 words (maximum depends on context).
3.2. Warnings
<id> appears uninitialized
Value of the variable appears to be used before the variable is initialized. This warning is enabled only by the u compilation switch.
Note: The compiler does a very simplistic data- and control-flow analysis to generate these warnings. The absence of a warning is no guarantee of proper initialization, nor is the presence of this warning proof that there is a genuine initialization error.
<id> cannot be opened
For module replacement, the BCD file containing the old version of the module. Otherwise, this is an error.
discrimination on opaque types is unimplemented
Implementation shortcoming. If T is an opaque type and x is a REF to an object with the corresponding concrete type, then ISTYPE[x, REF T] will usually be FALSE; also, NARROW and discriminating selection will usually fail.
Unless you are a wizard, treat this warning as an error.
<id> has been padded
In the definition of a MACHINE DEPENDENT record type without explicitly specified field positions, the number of bits allocated to a field because of alignment or boundary constraints exceeds the number required for the minimal representation.
<id> has global strings preventing replacement
Either STRING literals or STRING bodies in the global frame (for users of the System Modeller only).
<id> has incompatible attributes for replacement
A global procedure does not have a compatible type and the same entry point index in old and new versions of a compiled module, or a global variable does not have the same type and offset in both versions (for users of the System Modeller only).
Note: If the attributes of a large number of objects change, this warning appears only for the first few that the compiler notices. Unless you use the ~s compilation switch, small changes in the pattern of referencing global objects can cause large changes in their addresses (because of sorting done by the compiler).
<expr> has signed/unsigned ambiguity
Operands in the expression are neither both signed nor both unsigned (according to the rather arcane rules used by Cedar). This is a warning for those operators in which the resulting bit pattern is independent of the representation assumed (e.g., +, =); otherwise it is an error.
<expr> has zero length
Forming a descriptor of an empty array.
instruction has incorrect length
An instruction in a MACHINE CODE body does not have the number of operand bytes expected by the compiler (wizards only).
<id> is never referenced
A local variable, a global variable that is not PUBLIC, or a label that is declared but not otherwise referenced.
Alternatively, an entry in the DIRECTORY clause that supplies no items to the including module, or a name mentioned in a USING list that is never referenced.
<id> is private but matches an export
Has a name and type matching an item in one of the interfaces exported by a PROGRAM module but is not PUBLIC.
Caution: There is no corresponding check that every PUBLIC identifier in a PROGRAM module is exported to some interface.
<id> matches a constant in an exported interface
Is public and has a name matching an item in one of the interfaces exported by a PROGRAM module, but that interface item is a constant and will not be affected by the export.
multiple initialization with a pointer
In a declaration of multiple pointer, REF or descriptor variables, the same non-constant value is assigned to more than one variable.
Note: This warning is dubious and probably obsolescent. It was originally provided to draw attention to the sharing of any space allocated for the bodies of STRING variables by such declarations.
<id> receives no exported values
For an exported interface.
<id> referenced in different versions
References to two included modules with the same module identifier, say Z, but different version stamps. Frequently, one or both references arise indirectly; e.g., the module being compiled doesn't mention Z but includes X and Y, both of which depend upon Z.
This is not necessarily an error; the compiler has no way of knowing whether one of the versions is obsolete or just intentionally different. In the former case, a type error can occur if the checker attempts to match a type from X.Z with the corresponding type from Y.Z. This warning is issued to alert you to the possiblity of such otherwise baffling error messages.
Currently, there is no good way of finding the chain of dependencies that leads to a particular implicit reference. In puzzling cases, you or, more likely, a wizard can use the SymbolLister in a rather awkward and painful way to get this information. Listing the symbols of the explicitly included modules (possibly iterating until closure) generates a list of all possible references and the reference paths.
<id> supplies no imported values
For an imported interface.
unreachable code
Obvious cases in which all syntactic predecessors are RETURNs, ERRORs or GOTOs. Also, an alternative in a WITH ... SELECT following one in which the discrimination always succeeds.
<expr> will use unsigned comparison
An unsigned comparison with a suspicious and perhaps unintended constant operand (e.g., x < 0).
4. The Compiler's View of Types
Many of the semantic errors encountered in practice are consequences of the type checking done by the compiler. The Cedar Kernel takes the view that a type is a pair consisting of
a predicate, which is a function from values to BOOL
a cluster, which is a collection of name-value pairs, where the values are normally the attributes and operations associated with the type.
Every expression e has a syntactic type denoted by e. The syntactic type of an identifier is established by its declaration; that of a literal, by the syntactic form of that literal. Other expressions are viewed as the results of applying procs, either primitive or user-defined. The syntactic type of the result is determined by the range type of the proc in the outermost application, and most type checking consists of assuring that each argument has a type compatible with the corresponding formal domain type.
Cedar clusters allow the use of "object notation" to provide convenient and concise overloading of operator names. There are two cases:
If e = TYPE, e.n has the value associated with n in the cluster of e.
Otherwise, e.n[args] usually is shorthand for (e.n)[e, args]. In other words, n is bound in the cluster of the syntactic type of the operand to the left of the dot; that is expected to yield an operator which in turn is applied to the value of that operand plus the other arguments, if any.
In the second case, e.n has a proc type. The application is type correct iff, for each formal f and each corresponding actual a, a.predicate Ò f.predicate or there is a coercion from a to some type t such that t.predicate Ò f.predicate.
In the terminology of the old Mesa manual, an argument freely conforms to f if the implication holds, and it conforms if either it freely conforms or a suitable coercion can be found.
In this scheme, type checking can fail in two ways: the operator cannot be found in the cluster of the leftmost operand, or some operand (including the leftmost) has a type incompatible with the corresponding formal. These two situations correspond to two general classes of error messages, respectively
e has a type with no n operation
arg has incorrect type
In the first case, the compiler does not know the type required and can only report that the value supplied is not suitable. In the second case, the compiler has a clear idea of the required type; subsequent versions of the compiler will try to report it in a concise and readable way. Note some consequences:
This desugaring gives an asymmetric interpretation to the arguments of operators, such as = or +, that are normally considered symmetric. Thus essentially similar errors can be reported differently, depending upon the position of the operand. Life is hard.
Type errors in the first operand are most critical. If the compiler finds an operation in the wrong cluster, it is very likely to report type errors for each of the other operands. There is no attempt to consider all the operands and choose an operator that minimizes the total number of errors.
Current Cedar only partially supports the definition and use of clusters for user defined types. On the other hand, every built-in type comes with a predefined cluster, and every built-in type constructor produces a type with a cluster that can be defined in terms of the constructor and its arguments. For some of the resulting operations, there is a "sugaring" rule that allows a more conventional or more concise notation to be used for their application. These forms are defined in terms of the corresponding desugarings, which map back into dot notation.
Examples:
sugared desugared interpreted
-x   x.UMINUS x.UMINUS[x]
x+y   x.PLUS[y]x.PLUS[x, y]
MAX[x, y, z]  x.MAX[y, z] x.MAX[x, y, z]
WAIT c  (@c).WAIT CONDITION.WAIT[@c]