Nguyễn Gia Phong <[email protected]> writes:
Starting this is not much more than introducing errors (and the
relevant
messages) in the substitute* function, pushing these changes to
a
branch, asking QA to start building and investigating, no?
I support this course of action.
I'd be curious to hear from those who are deeply familiar with the
QA infrastructure, but I suspect that errors scattered across
thousands of build logs are an inconvenient signal to consume. If
those errors were compiled into a dashboard, then sure, but that
seems like a project unto itself.
On 2026-04-27 at 15:27-04:00, Jason Conroy wrote:
- 8643 total pattern matches
Based on the above, I agree that opt-out is a non-starter
without
some plan for incremental migration.
Thanks for the statistics, and I think the number of bad calls
is a couple orders smaller than the total.
That is my hope as well. But who knows! With silent failures, a
lot of cruft can accumulate over 13 years.
On 2026-04-27 at 15:27-04:00, Jason Conroy wrote:
1) One module at a time, rebind substitute* to substitute**,
rebuild, and fix errors. For the files with hundreds of
matches,
maybe place the rebinding closer to the bottom of the file to
limit its scope, then move it toward the top over successive
PRs.
IIUC this entails modify (and rebuild) each package using it
to opt in. It does not seem economical given most calls
requires no modification.
Ok, but on the other hand any change to substitute* (even just
adding error output) would also affect its module's hash and
trigger a rebuild. And then we would rebuild again when the
warn-on-error implementation was updated to fail-on-error.
Jason
