Community
Participate
Working Groups
3.1.0 The following queries for a model containing Class.name : String Class.superClass : Set(Class) [The apparently strange extra Set(...) is becuase there are multiple parallel trees so Class X may have superclasses in more than one tree] ----- [query public cgGetAllSuperClasses(elem : Set(Class)) : Set(Set(Class)) = let superClasses : Set(Class) = cgGetAllSuperClasses1(elem) in let superClassNames : Set(String) = superClasses->collect(name)->asSet() in superClassNames->iterate(superClassName : String; acc : Set(Set(Class)) = Set{} | acc->union(superClasses->collect(name = superClassName)->asSet())) /] [query public cgGetAllSuperClasses1(elem : Set(Class)) : Set(Class) = elem->closure(superClass)->union(elem) /] ---- demonstrates 5 problems a) closure must be factored out to avoid a spurious "usage of non-standard closure" message that suppresses all other diagnostics and only vanishes when no other messages are present. b) gives a duplicate message in the error hovertext Iterate expression body type must conform to the result type (superClassNames->iterate(superClassName : String; acc : Set(Set(Class)) = Set {} | acc->union(superClasses->collect(temp2 : Class | temp2.name.=(superClassName))->asSet()))) Iterate expression body type must conform to the result type (superClassNames->iterate(superClassName : String; acc : Set(Set(Class)) = Set {} | acc->union(superClasses->collect(temp2 : Class | temp2.name.=(superClassName))->asSet()))) c) Gives me no help by failing to tell me Iterate expression body type result type d) gives me no partial expression hover text to support viewing individual terms e) after editing the query, the error does not update until a Ctrl-S and a very slow workspace rebuild completes.
It's not just unhelpful, the diagnostic is actually wrong; after refactoring the iterate body to a separate query, it compiles.
This same query now gives a single error message "Iterate expression body type must conform to the result type" So a) and b) are solved. c) cannot be addressed since it comes from an OCL's SemanticException which sole message is what we print, no info on result type or iterate body type. See Bug #490990 I don't understand d) e) is not reproducible. Leaving open for now in case you remember what you meant with d).
Closing for now as what could be fixed has been. Please reopen if you remember what the last part meant
