https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> --- (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/msg00005.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.)
