{5} Assigned, Active Tickets by Owner (Full Description) (34 matches)

e.g., in Numbers.FiniteNumbers

• based on experience from C++
• code generation already produces executable axioms

Has circular dependency on:

• StyleBase
• MagnoliaResources
• ProjectURIResolver
• DeveloperMode

+ constructor calls various things that also use MagnoliaPlugin, in a way that is probably at least dodgy, and may also not be thread safe.

Specification clause "generate T by .." is missing.

The nested /*< .. >*/ comments do not always remove all errors and warnings from the commented away region. See sophus-src, cpp.BoundedArray. The related BoundedArrayRegion does not provide errors in commented away block of modules.

Depends on #48

Module names are not updated when file is renamed. Import statements are not updated when modules are renamed.

concept ok = {

type T; predicate di(t:T); preserve { predicate di ( a:A ); };

}; satisfaction bug = ok models {

preserve { predicate di ( a:A ); };

};

The preserve statement is fine inside the concept, but is flagged as an error:

MagnoliaFlattener::flattenTopExpr: Unknown top expr: Preserve

in the satisfaction statement.

Should the stuff in the "on" part be exported? What about code mixed in with @?

based on the design of the rule / transformation system

This is required to make all the hover services etc work on the current editor contents rather than the last saved state.

The error messages should be improved to pinpoint "missing semicolon" rather than just being "parse error".

type Subshape# = struct{var s:Shape; var b:Shape};

It would be useful to get a warning message when an item in a renaming list is not used.

For example:

concept a = { type A; }; concept b = a[ C => B ]; Warn that C does not exist in a.

This should not extend to named renamings. For example:

renaming r = [ A => R, C => B ]; concept c = a[ r ]; Do not warn about C not existing in a.

When a declaration is added to a C++ library interface (on the Magnolia side), the generated skeleton is updated. It would then be nice if the actual library implementation is updated with the new declarations added, ready to be filled in.

Simple version could be done by:

• diffing old and new skeleton code
• apply as patch to implementation code
• insert declarations by hand if patch fails

More complicated changes (removed operations, changes in argument lists), would need more advanced handling, and is out of scope for this ticket.