The changes for the language server are minimal. This will require
shipping version 2.0.0 of the debug server: use
https://github.com/willox/auxtools/releases/tag/v2.2.0
There are plenty of compiler features missing on the debug server's
end, but it is definitely more than usable so I want to get it
published. I plan on going a lot further this all of this, maybe we'll
even have hot loading one day.
Noticeable differences from actual BYOND are:
1. It only compiles expressions! This means no for loops, no if
statements, etc.
2. It lacks all static typing - the compiler has no access to type
definitions and will treat all `.` accesses as `:` accesses and
ignore the rules of const.
3. There are no implicit uses of `src`. This comes from the fact that
there is no static typing, so to access a field on `src` you have to
explicitly use `src.xyz` syntax.
4. Strings are lame. There is no interpolation support and the escape
sequences are super limited too.
5. Some built-in procs aren't supported, but most are. They'll
gracefully error if you try to use them.
6. No pre-processor.
For other limitations, just view the error list:
9ba328ef8c/src/compiler.rs (L45-L76)
tl;dr: relatively well-working debug console eval, watch eval, and
conditional breakpoints
I renamed the current `IndexKind` enum to `PropertyAccessKind` purely
based off of the fact that somewhere in the byond ref both procs and
vars are referred to as a datum's "properties" and I had no better name
ideas.
The checker treats conditional list accesses exactly the same as normal
ones. I was going to add some linting stuff for them but their expected
behaviour is completely up in the air at the moment.
This only becomes a problem when stuff we haven't got control over
decides to output to stdin or stderr.
vgstation-coders/vgstation13#28789 shows (in the most recent responses)
that they're using an internet explorer plugin which outputs some debug
info to stderr and terminates it with some invalid utf-8 or something.
I don't think the details on that side are too important, we just need
to fix the next part: This makes the language server's pipe_output
close the stream which then makes auxtools panic when it tries writing
to said stream (because eprintln!() will panic in such a case.)
Auxtools could handle this better, but there's no reason for the
debugger to just stop piping output because it sees some wacky bytes.
This requires an update to
https://github.com/willox/auxtools/releases/tag/debug-v1.0.0.
Basically, this'll let me add new debug console commands without having
to touch SpacemanDMM. I'm gonna be adding some as I push my way through
some DM bytecode related stuff so this'll save me a bunch of effort.
There's no new functionality here, it's still only `#help` and `#dis`.
The DLL is starting to get a bit big (it's still much smaller than a
tiny example implementing maptick which for some reason comes out at
2.5MB) so I'll try to get them smaller before making any new releases.
This fulfils some auxtool debugger requests you had.
1) All connection modes except for `BACKGROUND` wait for the DAP client
to be configured before continuing.
2) stddef.dm contents are sent to the debug client
3) disassemble eval command works (with the added benefit of being able
to disassemble procs that aren't currently running)
The updated auxtools also does some other stuff you wanted:
1) src/usr moved to arguments
2) your PR https://github.com/willox/auxtools/pull/11
3) arguments with no formal parameter in a proc that is being debugged
should show up
This adds support for a debug server written in auxtools (currently
located at https://github.com/willox/auxtools).
The dependency is similar to extools, where SpacemanDMM's
`auxtools_types.rs` has to be up-to-date with the `server_types.rs`
file located in whichever version of debug server is used. In the
future this could change to be some shared dependency, or maybe the
debug server could just be moved into SpacemanDMM.
There's a bunch of repeated code in `mod.rs` where there's match
statements where one branch is for the extools client and one branch is
for auxtools client. It's a bit iffy, but they all have minor
differences and wouldn't be super easy to merge.
I accidentally ran a `cargo fmt` on the files I was working with at
some point, so there's a few formatting changes about. I don't think
it's too much to read over.
I haven't edited any documentation yet, so here's how it works:
In your DM project:
```dm
// Currently needed for auxtools' error reporting. TG code already has this defined.
/proc/stack_trace(msg)
CRASH(msg)
/proc/enable_debugging(mode, port)
CRASH("auxtools not loaded")
/world/New()
var/debug_server = world.GetConfig("env", "AUXTOOLS_DEBUG_DLL")
if (debug_server)
call(debug_server, "auxtools_init")()
enable_debugging()
. = ..()
/world/Del()
var/debug_server = world.GetConfig("env", "AUXTOOLS_DEBUG_DLL")
if (debug_server)
call(debug_server, "auxtools_shutdown")()
. = ..()
```
In your project's SpacemanDMM.toml
```toml
[debugger]
engine = "auxtools"
```
The extension doesn't have a way to override the DLL being used (and I
don't think it should), so if you're testing stuff I suggest you set
the env vars to something like below and use the attach mode:
```
AUXTOOLS_DEBUG_DLL=path_to_your_build
AUXTOOLS_DEBUG_MODE=BLOCK
```
- Added hover handling for ScopedVar, UnscopedVar, ScopedProc,
UnscopedProc
- Improved handling of existing hovers, adding dm lang blocks to the
hovers where appropriate
- Added documentation to all existing hovers when it is available
- Fixed bug with annotating Variables, which would lead to excessive
whitespace being consumed
