$cpp_options() lists the same option under two spellings after merging executable metadata

[jgabry]

Another issue I noticed while working on #1235. I asked Claude to write up the report below:

---

$cpp_options() can list the same option twice, under two spellings, once the
model has merged what the executable reports about itself.

Reproduction

The ordinary threading workflow is enough:

mod$compile(cpp_options = list(stan_threads = TRUE), force_recompile = TRUE)
names(mod$cpp_options())
#> [1] "stan_threads"  "STAN_THREADS"

model_compile_info() upper-cases the keys it parses out of <exe> info, so the
merge adds STAN_THREADS beside the stan_threads that came from the request.

Why it is cosmetic

Every consumer resolves it correctly:

• cpp_option_value() matches case-insensitively and deliberately takes the last
  match, with a comment saying why.
• parsed_cpp_options() reduces to last-wins, so only one assignment reaches
  Make.
• built_cpp_options_ holds only what was passed on the command line and never
  the merged copy, so the mismatch detection in the no-op path never sees the
  duplicate.

Nothing wrong is compiled and nothing wrong is reported by
assert_valid_threads(). It is what a user sees when they print
$cpp_options().

The trap in the obvious fix

Deduplicating case-insensitively in merge_exe_info_cpp_options() looks like a
two-line change. It is, but the direction matters and is easy to get backwards.

The merge appends the metadata key after the request key, so cpp_option_value()'s
last-wins gives the executable precedence over the request. That is the right
precedence for a field whose job is to describe the artifact on disk rather than
what was asked for. A dedupe that keeps the first occurrence — the natural way to
write it — silently inverts that.

It would also be invisible in tests: the merge only writes options the binary
reports as enabled, so in practice the two entries almost always carry the same
value, and a test would have to construct disagreeing values on purpose to catch
the inversion.

Anything touching this should also check exe_info_reflects_cpp_options() and the
inherited / explicit name filtering in the no-op path, both of which key off
the names in these lists.

Scope

Pre-existing: on master the same duplicate arises through initialize() and the
no-op path. #1235 added the merge after a successful compile as well, so it now
also appears after $compile(force_recompile = TRUE) on an existing object, where
it previously did not — and #1235's NEWS entry draws attention to $cpp_options()
reporting more than it used to.

Possibly best folded into #1238 rather than fixed on its own: once the build
record is read from a sidecar instead of parsed back out of <exe> info, the
upper-casing that creates the second spelling goes away, and the dedupe question
changes shape.

[jgabry]

Correction to the last paragraph of the issue body: this is not folded into #1238.

The design review for #1238 established that the sidecar narrows the affected paths but does not dissolve the problem. $cpp_options() still exposes a single list to users, and Unknown executables (any binary without a readable sidecar, which is every binary built before the feature ships) still hydrate from <exe> info. A precedence-aware merge or presentation layer is still required.

Keeping explicit and metadata-derived options separate inside the record is the right internal structure, and it removes the duplicate from the recorded side. It does not remove it from what a user sees.

So this remains explicit work. The precedence trap described above still applies: the merge appends the metadata key after the request key, so last-wins gives the executable precedence over the request, and a dedupe that keeps the first occurrence silently inverts it.

[jgabry]

Closing — folded into #1238. Design note: #1254.

This is about $cpp_options() showing one option under two spellings after the executable-metadata merge. Under the new design that becomes a property of the record format rather than a display bug to patch separately:

• the record has a defined canonical form — named assignments are case-sensitive with last-wins, opaque arguments preserve order, include paths preserve order because it controls shadowing
• $cpp_options() presents the merge of request with reported_features, the latter tri-state so that absence never reads as disabled

Specifying the canonical spelling once, as part of the record schema, is better than fixing the display separately and then having to keep the two consistent. Tracking it in #1238.

Related: the case-sensitivity half of the underlying problem is #1250, which is now a prerequisite for the record rather than adjacent work.