https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |egallager at gcc dot gnu.org
--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
(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
>
> 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"
