Skip to content

Remove dead code in expandStringOperand #564

@AntoineGautier

Description

@AntoineGautier

The following is dead code and can be remove.

  if (typeof myoperand === "string" && !/^".*"$/.test(operand)) {
    const element =
      typeStore.get(myoperand, basePath) || typeStore.get(myoperand, baseType);
    // Only expand if it's a definition (enum, type, etc.), not an instance parameter
    const isDefinition =
      element && !["component_clause", "import_clause"].includes(element.elementType);
    myoperand = isDefinition ? element.modelicaPath : myoperand;
  }

Tracing through the possible cases for myoperand reaching the if block:

  1. Fully qualified type paths (e.g. "Buildings.Fluid.Types.HeatExchangerConfiguration") — typeStore.get finds the Enumeration element, isDefinition = true, but element.modelicaPath === myoperand already, so no change.

  2. Import aliases (e.g. "con") — typeStore.get finds the Import element, but elementType === "import_clause"isDefinition = false, no change.

  3. Local parameter references (e.g. "typCtlFanRet") — found as component_clauseisDefinition = false, no change.

  4. Enum values (e.g. "...HeatExchangerConfiguration.CounterFlow") — _get splits to name="CounterFlow", parent=Enumeration, isInputGroup("type") = false → while loop never runs → typeStore.get returns undefinedisDefinition = false, no change.

  5. MLS predefined types / unparseable pathstypeStore.get returns undefined or bails early, no change.

There is no realistic code path in the Buildings library where element is found, isDefinition is true, AND element.modelicaPath !== myoperand.

And indeed, removing this block has no effect on templates.json.

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions