Skip to content

ArgParser: backtick the Default<FieldName> member reference - #611

Merged
Smaug123 merged 2 commits into
mainfrom
argparser-backtick-default-member
Jul 31, 2026
Merged

ArgParser: backtick the Default<FieldName> member reference#611
Smaug123 merged 2 commits into
mainfrom
argparser-backtick-default-member

Conversation

@Smaug123

Copy link
Copy Markdown
Owner

Same class of bug as the record-construction fix in #604, at a different site.

[<ArgumentDefaultFunction>] makes the generator concatenate Default with the field's name and emit the result as an identifier — twice, once to set the default and once to render it into help text. A field whose name needs backticks forces the member to be declared with them too, and the reconstruction dropped them, so the generated file did not parse:

AwkwardDefaultFunctionName.Defaultspace in name()

The concatenation cuts both ways, and the fix accounts for both directions: a field named mod needs backticks itself, but the member Defaultmod does not, and is still emitted bare. Both are covered by tests.

isValidBareRecordLabel/backtickRecordLabel are renamed to isValidBareIdent/backtickIdent, since they now serve a member name as well as a record label. The probe deliberately stays in the record-label position for every caller, which is worth knowing about: that is the tightest position available, admitting exactly one identifier and nothing else. A probe in the position this new caller emits into would be far weaker — Owner.Defaultspace name () parses perfectly happily as an application of Owner.Defaultspace to name, and would report success for a name which is nothing of the sort. Being tighter than a caller needs only over-backticks, which is always safe.

Test first, observed failing: ConsumePlugin gained AwkwardDefaultFunctionName, and the build broke exactly as above before the fix. Runtime test covers both the defaulted and the user-supplied path.

Suite green (1105 / 164 / 3).

🤖 Generated with Claude Code

Same class of bug as the record-construction fix, at a different site.
[<ArgumentDefaultFunction>] makes the generator concatenate "Default"
with the field's name and emit the result as an identifier -- twice, once
to set the default and once to render it into help text. A field whose
name needs backticks forces the member to be declared with them, and the
reconstruction dropped them, so the generated file did not parse.

The concatenation cuts both ways and the fix accounts for both: a field
named ``mod`` needs backticks itself, but the member `Defaultmod` does
not, and is still emitted bare.

isValidBareRecordLabel/backtickRecordLabel are renamed to
isValidBareIdent/backtickIdent, since they now serve a member name as
well as a record label. The probe deliberately stays in the record-label
position for every caller: it is the tightest one available, admitting
exactly one identifier and nothing else. A probe in the position this new
caller emits into would be far weaker -- `Owner.Defaultspace name ()`
parses happily as an application, and would report success for a name
which is nothing of the sort.

Test first, observed failing: ConsumePlugin gained a record whose
default-function fields have awkward names, and the build broke with
`AwkwardDefaultFunctionName.Defaultspace in name()` before the fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Smaug123
Smaug123 merged commit b3843a4 into main Jul 31, 2026
19 checks passed
@Smaug123
Smaug123 deleted the argparser-backtick-default-member branch July 31, 2026 11:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant