| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A SourceSpan contains up to two SourceLocations: the location of the
span in the parsed source file (called in_merged), and the location of
the span in an original source file as per a path comment in the parsed
source file (called in_source). In places where only one location can
be reported, the in_source location is preferred but is not guaranteed
to exist, so the in_merged location is used as a fallback.
Because this pattern is used in multiple places, it was added as a
method to SourceSpan and all occurrences of the pattern were replaced
with a method call.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous source merging strategy was to concatenate source units
in the reverse order that they were added to the resolver, which
generally only worked when each source unit had at most one
macro-resolving parent.
An issue arose when some macros in a source unit were resolved by a
source unit which had been added earlier in the order, as the required
macro definitions would then be merged after they were referenced,
preventing the program from assembling.
The new source merging strategy finds an optimal merge order by first
recording for a given source unit the ID of each unit which resolves a
macro referenced by the given unit, and then only merging those source
units whose macro-defining dependencies have already been merged. In the
case that a cycle is detected, where two or more source units depend on
one another, a message is printed and the assembly is aborted.
|
|
|
This is an almost complete rewrite of the entire assembler from the
ground up, with a different parsing strategy and a whole new symbol
resolution mechanism for automatically including library files.
The assembly syntax has also been slightly modified, with padding
tokens now being prefixed with '#' instead of '$', and a block-style
anonymous-label syntax which uses the '{' and '}' characters.
|
