https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #1)
> (In reply to David Malcolm from comment #0)
> > In my original edit_context patch kit I posted a
> > "-fdiagnostics-apply-fixits" option that would auto-apply fix-it hints:
> > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01682.html
> > ...but there was no error-checking.
> >
> > This is something of a brainstorm:
> >
> > A really smart implementation of this would directly modify the token
> > stream, and fix the AST as we go.
> >
> > Sadly I don't think that doing that would be feasible, for C, at least, so
> > any implementation is probably going to have to write a file to disk.
> > (maybe it's doable for C++, given that that has all the tokens in-memory
> > up-front? but what about the preprocessor?)
> >
> > Error-handling needs to be perfect: we must *never* lose or corrupt the
> > user's source code.
> >
> > Would probably need to be something like:
> > * write the proposed new code to disk
> > * verify that it works
> > * make a backup copy of the old code
> > * copy the new code into place (various failures here need to be dealt with)
> > * tell the user where the backup is
> > * maybe keep the last, say, 10 copies around, with rolling backup (param to
> > control it)
>
> As far as backups go, the standard way for GNU programs to do backups is
> Emacs backups; see autoupdate and autoheader in autoconf, gnulib-tool in
> gnulib, gettextize in gettext, and probably a few others I'm forgetting. See
> also gnulib modules backupfile and backup-rename:
> https://www.gnu.org/software/gnulib/MODULES.html#module=backupfile
> https://www.gnu.org/software/gnulib/MODULES.html#module=backup-rename
Update: apparently autoconf/automake check the environment variable
$SIMPLE_BACKUP_SUFFIX:
https://lists.gnu.org/archive/html/autoconf/2021-01/msg5.html
>
> >
> > Further complications:
> > * fix-it hints could affect multiple files, not just the primary source file
> > * we might not have write access to some of the files (e.g. headers).
> > (Reminiscent of fixincludes?)
> >
> > There could be interaction with the driver: apply the fixes, reinvoke the
> > compiler, etc. Maybe keep going until we can't fix. If so, could need some
> > diagnostic-suppression to avoid spamming the user with the same diagnostic
> > over and over again. Question: if we successfully get the user's code to
> > compile, but there were errors along the way, do we still generate a .o
> > file?
> >
> > Maybe "-fixit" is a better name?
>
> Sounds like "-fast", which got renamed to "-Ofast"
(to make what I was saying here a bit more explicit, what I meant was that
making intentional puns out of option names seems to be on its way out. Instead
of just "-fixit" I'd say at least extend it to "-ffixit" so the negative
becomes "-fno-fixit" rather than just "-fno-ixit", but really I think the
original longer name of "-fdiagnostics-apply-fixits" is still the best.)
