Files
benilla-octo/crates/benilla-ui/src/script/tests/numeric_shape_gate.rs
T
gromandClaude Opus 5 81d96af35d Everwood: the HD/OctoWoW line of benilla, imported onto upstream
This checkout had no git history at all, so this one commit carries the whole
of the Everwood work as a single import on top of chairmanpow/benilla-octo's
`main` (706cd71). The two trees have genuinely diverged — each has files the
other does not — so this is a fork point, not a catch-up.

Today's work, which is the reason a baseline exists at all:

- Booth previews no longer cast world shadows (`NO_BOOTH_SHADOW`). Portrait
  characters were entering the sun's shadow cascades, so every skinned-rig
  shadow specialization compiled live mid-frame; the hitch detector logged
  "main thread blocked 1316 ms" beside a `compiled LIVE` warning. This was
  the Fashion/Tmog stutter.
- Per-pane dress-up: each `DressUpModel` pane assembles and stages its own
  tried-on look instead of every pane mirroring the live player.
- Item template cache is append-only JSONL written on the IO pool, replacing
  an 11.6 MB whole-map JSON rewrite on the main thread every 10 s.
- `WOW_SYSTEM_TIMING` rebuilt per-thread: it took 2 mutexes per system enter
  and 4 per exit, costing 15 ms a frame (590 fps -> 60) and corrupting the
  measurements it was taken to produce.
- The visibility-churn sweep moved to its own `WOW_FLASH_CHURN` switch, so a
  frame-cost reading no longer pays 2.7 ms a frame for it.

Local state (`benilla-config/`, `logs/`, `target/`) is excluded by the
existing .gitignore; the account credential it holds is not in this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-15 15:01:14 -06:00

145 lines
6.3 KiB
Rust

//! Shape C: a numeric position the reference reads with a bare `lua_tonumber` (`0x6f3620`) and no
//! `lua_isnumber` gate, so nil, a table or a non-numeric string is 0.0 and the call completes. A
//! *numeric* string is its number — `lua_tonumber` ends in `strtod` — which is the other half of
//! the shape and has its own test here. Shape B, not tested here, is a pre-staged default, such as
//! every colour setter's alpha (1.0 at `0x778220`).
use super::common::script;
#[test]
fn every_shape_c_colour_position_takes_nil_as_zero_and_never_raises() {
let s = script();
s.run(
r#"
F = CreateFrame("Frame", "F")
T = F:CreateTexture(nil, "ARTWORK")
FS = F:CreateFontString(nil, "ARTWORK")
SB = CreateFrame("StatusBar", "SB")
CS = CreateFrame("ColorSelect", "CS")
"#,
)
.unwrap();
// `Texture:SetVertexColor 0x79abd0` (`2=C 3=C 4=C`), as stock `QuestLogFrame.lua:337` calls it.
s.run("T:SetVertexColor(nil, nil, nil)")
.expect("SetVertexColor(nil,nil,nil) is three bare lua_tonumbers, not a raise");
s.run(
r#"
local r, g, b = T:GetVertexColor()
assert(r == 0 and g == 0 and b == 0, "a nil channel stores 0.0, it does not keep the old one")
"#,
)
.unwrap();
// A table, a boolean and a string that will not convert are 0.0 too: `lua_tonumber` tests
// nothing. A string that *will* convert is a number, not a tag — see
// [`a_numeric_string_converts_at_every_shape_c_colour_position`].
s.run("T:SetVertexColor({}, \"abc\", true)")
.expect("no tag is rejected at a shape-C position");
// `Texture:SetTexCoord 0x79beb0`: every coordinate C; only the arity raises.
s.run("T:SetTexCoord(nil, nil, nil, nil)")
.expect("four nil coordinates are four zeroes");
s.run("T:SetTexCoord(0, 1, 0, 1, 0, 1, 0, 1)")
.expect("the 8-corner form still takes numbers");
s.run("T:SetTexCoord(1, 2, 3)")
.expect_err("but 3 args is neither 4 nor 8, and the arity DOES raise (0x79bf5d)");
// `FontString:SetShadowColor 0x79dd40` and `StatusBar:SetStatusBarColor 0x78fc20`.
s.run("FS:SetShadowColor(nil, nil, nil)")
.expect("FontString:SetShadowColor is shape C on r/g/b");
s.run("SB:SetStatusBarColor(nil, nil, nil)")
.expect("StatusBar:SetStatusBarColor is shape C on r/g/b");
s.run(
r#"
local r, g, b = SB:GetStatusBarColor()
assert(r == 0 and g == 0 and b == 0, "and it stored the zeroes")
"#,
)
.unwrap();
// `ColorSelect:SetColorRGB 0x78eae0`: C on all three; it fires OnColorSelect either way.
s.run("CS:SetColorRGB(nil, nil, nil)")
.expect("ColorSelect:SetColorRGB is shape C on r/g/b");
// `Texture:SetGradient 0x79ae30` and `SetGradientAlpha 0x79b180`.
s.run("T:SetGradient(\"HORIZONTAL\", nil, nil, nil, nil, nil, nil)")
.expect("SetGradient's six stops are all C");
s.run("T:SetGradientAlpha(\"VERTICAL\", nil, nil, nil, nil, nil, nil, nil, nil)")
.expect("SetGradientAlpha's eight are C/B");
// `FontString:SetTextColor 0x79d9c0`.
s.run("FS:SetTextColor(nil, nil, nil)")
.expect("FontString:SetTextColor is shape C on r/g/b");
}
/// Shape C's other half: `lua_tonumber` is `luaV_tonumber` → `luaO_str2d` → `strtod`, so a string
/// that parses *is* its number at these positions and only one that does not falls to 0.0. No
/// stock FrameXML caller needs this — every one of them writes literals — but pfUI's
/// `GetStringColor` splits a config string with `strsplit` and hands the substrings to the colour
/// setters unconverted ("returns r,g,b,a as strings", `api/api.lua:1085-1096`), so its whole
/// configured palette arrives here as strings. Reading them as tags made every such colour opaque
/// black, which is what blacked out pfUI's map-reveal overlays (tint `.4,.4,.4,1`,
/// `modules/mapreveal.lua:99,163`).
#[test]
fn a_numeric_string_converts_at_every_shape_c_colour_position() {
let s = script();
s.run(
r#"
F = CreateFrame("Frame", "F2")
T = F:CreateTexture(nil, "ARTWORK")
FS = F:CreateFontString(nil, "ARTWORK")
SB = CreateFrame("StatusBar", "SB2")
B = CreateFrame("Button", "B2")
"#,
)
.unwrap();
// The exact tuple pfUI's `GetStringColor(".4,.4,.4,1")` returns: four strings, the first three
// with no leading digit, which `strtod` takes and a Rust `f32` parse of a `Value::String` by
// hand would be one careless `match` arm away from dropping.
let pf = r#"".4", ".4", ".4", "1""#;
for (setter, getter) in [
("T:SetVertexColor", "T:GetVertexColor"),
("FS:SetTextColor", "FS:GetTextColor"),
("SB:SetStatusBarColor", "SB:GetStatusBarColor"),
("B:SetTextColor", "B:GetTextColor"),
] {
s.run(&format!("{setter}({pf})")).unwrap();
assert_eq!(
s.eval::<(f32, f32, f32, f32)>(&format!("return {getter}()"))
.unwrap(),
(0.4, 0.4, 0.4, 1.0),
"{setter} must read a numeric string as its number, not as 0"
);
}
// `SetShadowColor`/`GetShadowColor` is the same shape on a different slot, and the exponent
// and sign forms `strtod` takes are not special-cased anywhere.
s.run(r#"FS:SetShadowColor("4e-1", "-0", "1.", ".5")"#)
.unwrap();
assert_eq!(
s.eval::<(f32, f32, f32, f32)>("return FS:GetShadowColor()")
.unwrap(),
(0.4, 0.0, 1.0, 0.5)
);
// `SetTexCoord` is shape C per coordinate (`0x79beb0`), so a string crops as it reads.
// `GetTexCoord` answers the eight corner components (UL, LL, UR, LR), so a (0, .765625,
// 0, .765625) rect reads back as that rect's four corners.
s.run(r#"T:SetTexCoord("0", ".765625", "0", ".765625")"#)
.unwrap();
assert_eq!(
s.eval::<Vec<f32>>("return { T:GetTexCoord() }").unwrap(),
vec![0.0, 0.0, 0.0, 0.765625, 0.765625, 0.0, 0.765625, 0.765625],
"a string coordinate is a crop, and a 0 there would collapse the quad's UV to a point"
);
// And a non-converting string still reads 0.0: the gate tests nothing, it just fails to parse.
s.run(r#"T:SetVertexColor("", "abc", "0x!")"#).unwrap();
assert_eq!(
s.eval::<(f32, f32, f32)>("local r,g,b = T:GetVertexColor() return r,g,b")
.unwrap(),
(0.0, 0.0, 0.0)
);
}