The current implementation appears to be based on the incorrect assumptions that:
INCDIR directives are one per file - there is no limit to the number of INCDIR statements
Their scope is limited to that file - they are aggregated from all included files (like other symbols)
Paths are relative to the file they are declared in - they are always relative to the main file being assembled.
i.e. if an included file in a different dir uses an include/incbin/incdir statement, the path is relative to the main file, not the included file. You can basically imagine that all includes are inlined into the main source file before being parsed.
We don't currently limit the scope of symbols by tracking which files are being included where. We just treat all symbols as global and accessible from every source file. I've applied the same approach here, adding an includeDirs symbol map to M68kDefinitionHandler.
Similarly we don't really know which source files are assembled directly vs which are includes. The simplest option is therefore to make paths relative to the workspace root dir, with the assumption that all entrypoints will live there.
Other fixes and enhancements include:
Handle paths in single quotes
Complete correctly when the partial word contains punctuation. Previously part of the word would be duplicated e.g. "my-e" -> "my-my-example".
Handle dot paths correctly for current or parent directory e.g. "./"
Provide path completions for incbin and incdir directives
Possible future enhancements:
Include paths can also be passed to vasm as command line args. We could potentially extract these from the project's build task definition.
Provide settings to override the path root directory and/or add additional include paths
The current implementation appears to be based on the incorrect assumptions that:
INCDIR
directives are one per file - there is no limit to the number ofINCDIR
statementsinclude
/incbin
/incdir
statement, the path is relative to the main file, not the included file. You can basically imagine that all includes are inlined into the main source file before being parsed.We don't currently limit the scope of symbols by tracking which files are being included where. We just treat all symbols as global and accessible from every source file. I've applied the same approach here, adding an
includeDirs
symbol map toM68kDefinitionHandler
.Similarly we don't really know which source files are assembled directly vs which are includes. The simplest option is therefore to make paths relative to the workspace root dir, with the assumption that all entrypoints will live there.
Other fixes and enhancements include:
incbin
andincdir
directivesPossible future enhancements: