ConstReadonlyargument: {The same, for the arguments of a call.
Readonlyname: "argument"ReadonlystringVector: (The argument's value as a vector of strings.
ReadonlysymbolName: (The argument's value as the name of the symbol it holds.
ReadonlytoName: (The argument's name.
Readonlyvalue: (The argument's value.
ReadonlyvectorLength: (The length of the vector the argument holds.
ReadonlybyName: (Every definition the identifier may refer to, whatever its type.
ReadonlybyNameAndType: (The definitions the identifier may refer to that fit the wanted ReferenceType.
The same, for a graph that is already at hand.
the graph to resolve in
the analyzer context stating how far resolution may go
Where to resolve, put together from a finished analysis: its graph, its id map and the configuration the analyzer was built with. Hand what this returns to Resolve.toValue and its kin, or to NodeValue, rather than assembling a ResolveInfo by hand.
the analysis to resolve against; its dataflow is computed if it has not been yet
ReadonlyisBuiltIn: (Whether the name is not shadowed by a user definition, so it still refers to the built-in.
Readonlyname: "Resolve"ReadonlytoBuiltIn: (Whether the name always, never, or maybe refers to a built-in constant of the given value.
ReadonlytoConstants: (The constant values the name resolves to.
ReadonlytoSingleString: (The single string the node resolves to, or undefined if it is not exactly one.
ReadonlytoValue: (The value(s) the node may hold, tracking aliases as the configuration allows.
The helper object for resolution: from a name to the definitions it may refer to, and from a node to the value(s) it may hold.
Resolve.info and Resolve.infoOf state where to resolve, which everything below takes; from an analyzer that is one call, with no need to assemble the graph, the id map and the context by hand.
Take the narrowest entry point that answers your question, they differ a lot in cost: