Give cfproperty and cfparam their real attribute sets

[ghedwards]

Resolves the question #43 left open, by answering it with evidence rather than judgement. Refs #39.

The blocker was never the wiring

#43 deferred "should validateAttributes be wired up for param and property?" on the grounds that it throws. Going to answer that, I checked whether the allowed sets were even correct. They are not.

Class	Allowed set	Dictionary says
CFLockStatement	5	5	exact match — and it is the one live caller
CFParamStatement	6	7	missing MAXLENGTH
CFPropertyStatement	6	65	holds cfparam's six

CFPropertyStatement.validAttributes was NAME, TYPE, DEFAULT, MAX, MIN, PATTERN — a copy of cfparam's list. Only the first three are cfproperty attributes at all. So getter, setter, persistent, fieldtype, ormtype, required, hint — the attributes on essentially every accessor-generating or persistent CFC — all counted as invalid.

That reframes the original question entirely. Wiring property validation up would not have been a debatable trade; it would have rejected almost every ORM entity ever written.

getValidAttributes() is public static on both classes, so this was reachable from outside regardless of wiring. That makes it a live bug, not dormant code.

Both sets now come from the dictionaries

The shipped dictionaries agree on all three tags across cf11 and lucee5 — no dialect divergence — so a hardcoded set can be correct for both:

cflock:     cf11=5  lucee5=5   (no difference)
cfparam:    cf11=7  lucee5=7   (no difference)
cfproperty: cf11=65 lucee5=65  (no difference)

CFLockStatement matching the dictionary exactly is the useful control here: the validation mechanism was never broken, only the data it was given.

Still not wired up, and now for a better reason

validateAttributes throws, parseScript does not catch, so one unrecognised attribute aborts the whole file instead of reporting an error on the statement. There is no error-reporting path through CFScriptStatementVisitor to change that without real plumbing.

The decisive argument is staleness: these sets are pinned to dictionaries that ship with the parser, and will fall behind whatever the next CF release adds. A hardcoded allowlist that throws is a time bomb aimed at valid code, in a parser whose job is to survive unfamiliar input. Correct data makes that failure rarer, not impossible.

So the sets are now right for anyone who asks — including CFLint, which has the dictionary and a proper diagnostic channel — and the parser still does not abort files over an attribute it has not heard of.

cfadmin is deliberately untouched: its set carries RETURNVARIABLE, which the lucee4.5 dictionary omits but Lucee accepts. A permissive superset, not a bug.

Tests

Four added. Three fail with cfml.parsing/src/main stashed:

testPropertyAndParamSetsAreNotTheSame  expected:<7> but was:<6>
testParamAllowsMaxLength               ParseException: Invalid attribute maxlength
testPropertyAllowsItsOwnAttributes     ParseException: Invalid attribute getter

The fourth, testPropertyStillRejectsUnknownAttributes, passes either way by design — it guards the rejection path so a future widening of the set cannot quietly turn validation into a no-op.

Verification

• 322 tests, ./gradlew build
• CFLint 675 against a clean build

---

Generated by Claude Code