Opened 6 years ago
Closed 6 years ago
#5380 closed defect (fixed)
Path to type definition in DAE.ElementSource not available
Reported by: | Karim Adbdelhak | Owned by: | Per Östlund |
---|---|---|---|
Priority: | critical | Milestone: | Future |
Component: | New Instantiation | Version: | |
Keywords: | Path, ElementSource | Cc: | Adrian Pop |
Description
When calling ElementSource.getElementSourceTypes
it always returns an empty list. The information for the property list<Absyn.Path> typeLst
from DAE.ElementSource
does not seem to be propagated through the NF and therefore not available in the Backend.
RTE updated their version of OMC and used this function to dump some information. In 1.9.4 it still worked.
Change History (3)
follow-up: 2 comment:1 by , 6 years ago
comment:2 by , 6 years ago
comment:3 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Possibly fixed in cbb67f0b, except that I'm not entirely sure what the expected behaviour is supposed to be. The comment in the code for
typeLst
says that it's "the classes where the type(s) of the element is defined", but what's actually added to the list seems to be the fully qualified names of the types of an element's parents in the instance tree. Anyway, the new frontend will at least add something totypeLst
now, so let me know if it's what you were looking for or if we need to tweak it.However, the old frontend only adds this information if either the
-d=infoXmlOperations
or the-d=visxml
flag is given, so I did the same in the new frontend. Having it turned on by default is probably not a good idea, since it can be quite expensive, but if you wish to use some other flag we can of course change it (it's defined inNFConvertDAE.convertVariables
if you wish to change it yourself).