Currently, there is `Map::adjust_key_length()`, but it sets key length
based on the amount of items in the dictionary. Which is fine if keys
in order like 1-2-3-4-...-N, but it falls apart if the keys are not in
order - which is valid for a dmm map.
If a map has keys like [1, 2, 3000], then, currently,
`Map::adjust_key_length()` will set key length to 1, but the map will
panic on save cause the 3000 key is bigger than max key for this key
length (52).
This PR fixes `adjust_key_length` to work properly in that case, where
it sets key length based on the biggest key in the map dictionary.
Also `dmm_tools::dmm::Map::to_writer()`, so it can be used to save to a
string and not just a file, for use in external tooling that depends on
this, and may want to, for example, pass the string back to byond from
rust-g.
`dmm_tools::dmm::Map::to_file()` is kept for convenience (and
backwards compatibility I guess to not break code), but it just uses
the `::to_writer()` function.
A ton of time was spent constructing/destructing the Tera contexts, so
skipping that step by using a compile-time templater helps a lot. Takes
dmdoc time on /tg/station13 down from 10+ minutes to <5 seconds.
Adds support for :: to the parser, in all its forms (global proc/var,
off type). Also implements behavior for it. We'll properly read the
type of what we attach to, and double check that everything matches.
Works for the proc refs too.
I've added unit tests for all this to double check my work. I DIDN'T
mirror the static var detection byond does. problem for another day.
I'm not hooking it into the existing return type system because I'm
pretty sure it doesn't already support primitives, and I am not prepared
to deal with that bullshit.
It will parse without erroring tho, so that's based.
Neither was handled in try_read_operator_name, and `operator/` needed
special handling in tree_path so that the `/` isn't taken as a tree path
separator and the method is ultimately named just `operator`.
Fixes#362.
As a part of this we need to make a struct when building proc defs, to
keep track of their flags AND their kind at the same time.
We then pass that down into a new flags var on the proc decl struct,
and we're golden.
Only thing of note is I removed the is_private and is_protected vars
from proc declarations because they were totally unused. Spooky added
em a long time ago and I think it was for not much reason.
It turns out this kinda sucks. it doesn't work with ::, so we don't even
really need to care about its value. I threw in support for constant
eval but that's inconsistent on our end cause type_hint doesn't always
play. I figure it's good to at least have something, and issues can get
sorted out as we go.
It is also seemingly massively annoying to eval in like, an istype(),
since it has special case behavior there. I just kinda left it sit
since I'm pretty sure it'd be a massive change to support and it like
does not matter.
We basically just capture them early, and then treat them as unique
symbols. We don't replace inline or anything because the required
context isn't quite there.
The float stuff was easy. Operator was too, just took a bit to realize
how it worked
Nothin much else to say, outside that I needed to roll my own operation
for this one, since float remainder is kinda hard to find (and I
couldn't after cursory reading)
Also explicitly declare our dependency on syn 1's "full" feature, as
otherwise the phf_macros upgrade means the feature will go missing and
cause failures in some situations.
- `guard` 0.5.1 was released on 2021-04-11
- `let else` was stabilized in Rust 1.65.0 on 2022-11-03
- `box_syntax` became a hard error in Rust 1.70.0 on 2023-06-01
- `guard` has tests that use box_syntax so it no longer compiles
