Lummox recently made this a RUNTIME error, but also irrespective of
that this tends to mask HELL vars[] security holes. We really should be
linting for it.
I had to implement operator overloading support for the builtin parser,
which was far more annoying then I expected. Bit scuffed, but it works.
(I am unsure of how to parse for "" though so I left that unimplemented)
This will likely throw errors on most codebases, I'm unsure of how to
handle that.
fix parsing of
```dm
var/alist/foo = list()
for (var/index as num, C in foo)
world << index
```
currently `got ',', expected one of: '|', 'in', ')'`
also fixes two clippy warnings
ref: bottom of https://www.byond.com/docs/ref/#/proc/for/list
The Displace filter has the ability to add an Overlay flag. It works
properly and as expected. Link to the Byond documentation:
https://www.byond.com/docs/ref/#/{notes}/filters/displace
> The optional FILTER_OVERLAY flag is supported for the flags argument,
> which will overlay the displaced image onto the original.
Trying to loop over values using `for(var/v in alist("a" = 2))` would
throw an "iterating over a /alist which cannot be iterated" error
despite working in DM.
I wasn't able to find a concise way to reference the range and/or
contents of proc bodies without also needing to reference the Annotation
tree. I haven't implemented any use case for the added information
outside of some experiments I'm doing with the deeper analysis
companion; I think it could be useful for determining return values and
types without the need for SpacemanDMM directives, at a later point.
It's an Option to account for built-ins not having any actual presence
in the syntax tree.
This adds a new arm to the parser for the `for (var/k, v in X)`
dict-like syntax that was added in 516.
I have hijacked the arm that checks for this type of expressions :
`for (init, test, inc)` or `for (init; test; inc)`
I have seperated it between `init; test; inc` (left untouched) and
`init, test, inc`.
If `inc` is not None, I then check if `test` in a `BinaryOp::In`
(something like `for(init, [x in y])`. If not I just assume it's a `for
(init, test)` which is valid DM syntax.
I then check if `init` is a `var/k` type of statement, using copypaste.
DM will not compile `for (k, v)` nor will it compile `for (var/k,
var/v)`. I check if v is an ident.
If we're all good, I create a new type of structure
`ForKeyValueStatement` and the lib.rs / findreferences.rs knows what to
do with it.
Both `for (i = 0, i < 10, i++)`, `for (i = 0, i < 10)` still pass.
This adds support for 516's `call_ext(LoadedFunc)` syntax (allowing
either one or two args to `call_ext`).
The `call_ext_missing_arg` test is removed as a result, as `call_ext`
with a single arg is now valid syntax.
It's slightly annoying to have to bump the Rust version here to keep it
working, and it rarely gets noticed when it's out of date anyways
because it isn't really used.
Currently when a spaceman setting like `SHOULD_CALL_PARENT` comes after
some other statement other than possibly another setting, it is silently
ignored. This PR now errors in that situation. The checking is only
performed on spaceman settings and not built in settings (e.g.
`background`) because those can situationally be allowed in control
statements so long as they otherwise would be at the top of the proc,
but dreammaker will already warn for them if they would have no effect.
See below where red lined are the new lints, and yellow lined are the
existing dreammaker warnings.
This makes it so blank strings are filtered out of
`dreammaker.debugServerDll` (and also `dreammaker.extoolsDLL`, but I
highly doubt that is still in use at all), so the config option being a
blank string will just be treated as if said config option were unset.
