Bugzilla – Full Text Bug Listing
| Summary: | [xbase] Validate uninitialized variables | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Niko Stotz <eclipse> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sebastian.zarnekow, sven.efftinge |
| Version: | 2.0.0 | Flags: | sven.efftinge:
indigo+
|
| Target Milestone: | SR1 | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
Workaround:
var value = switch(modelType) {
case "StringValue":
valueString
case "IntValue":
Integer::parseInt(valueString)
case "DoubleValue":
Double::parseDouble(valueString)
case "BooleanValue":
Boolean::parseBoolean(valueString)
default:
// this would be something like ((ComplexType) modelType).property
if (complexTypeProperty == "state") {
STATE_CONSTANT
} else {
throw new IllegalArgumentException("Unknown type")
}
}
=========
The syntax of your first example
var x
x = "Test"
is actually
var <TypeName> <VarName> = <InitialValue>
where x is both the typename and the var name. That's where the error message comes from.
var x;
x = "Test"
will type 'x' to Object.
However, the error message could be improved.
The thing we should do here is to make the type information mandatory (via validation rule) for uninitialized variables. Closed as works for me. See XbaseJavaValidator.checkVariableDeclaration(XVariableDeclaration). Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |
Build Identifier: I20110310-1119 using an uninitialized generic variable leads to logical, but not very user-friendly error messages. Either the error message should be improved or, preferably, the type should be set to Object. I think the case of having an uninitialized generic variable is quite common, in the sense "I know I'll need this variable somewhere below, but I don't know it's type or value yet". One example would be to have a complex, deeply nested if / else construct to test various conditions and finally settle on the value. It's also "closer" to the code style required in xtend 1 where "variables" were allowed only at the beginning of a block. Reproducible: Always Steps to Reproduce: var x // error "Couldn't resolve reference to JvmType 'x'" x = "Test" // error "Incompatible types. Expected void but was java.lang.String" An example of a complex structure without pre-known type: var value switch(modelType) { case "StringValue": value = valueString case "IntValue": value = Integer::parseInt(valueString) case "DoubleValue": value = Double::parseDouble(valueString) case "BooleanValue": value = Boolean::parseBoolean(valueString) default: // this would be something like ((ComplexType) modelType).property if (complexTypeProperty == "state") { value = STATE_CONSTANT } else { throw new IllegalArgumentException("Unknown type") } }