On Tue, May 02, 2017 at 03:08:01PM -0400, David Malcolm wrote: > Currently the C/C++ frontends discard comments when parsing. > It's possible to set up libcpp to capture comments as tokens, > by setting CPP_OPTION (pfile, discard_comments) to false), > and this can be enabled using the -C command line option (see > also -CC), but c-family/c-lex.c then discards any CPP_COMMENT > tokens it sees, so they're not seen by the frontend parser. > > The following patch adds an (optional) callback to libcpp > for handling comments, giving the comment content, and the > location it was seen at. This approach allows arbitrary > logic to be wired up to comments, and avoids having to > copy the comment content to a new buffer (which the CPP_COMMENT > approach does). > > This could be used by plugins to chain up on the callback > e.g. to parse specially-formatted comments, e.g. for > documentation generation, or e.g. for GObject introspection > annotations [1].
Making that kind of task easier seems like a good thing. One difficulty will be associating the comment with the declaration its for. In C++ its probably better to use attributes when possible but that won't work for the documentation issue. > Does enchant seem like a reasonable dependency for the compiler? > (it pulls in libpthread.so.0, libglib-2.0.so.0, libgmodule-2.0.so.0). > Or would this be better pursued as a plugin? (if so, I'd > prefer the plugin to live in the source tree as an example, > rather than out-of-tree). I'd kind of worry about what loading all that does to start up time, but maybe that's premature optimization. Anyway it seems like making things plugins where reasonable will help modularity, so kinda seems like a good idea anyway. > Unrelated to spellchecking, I also added two new options: > -Wfixme and -Wtodo, for warning when comments containing > "FIXME" or "TODO" are encountered. > I use such comments a lot during development. I thought some > people might want a warning about them (I tend to just use grep > though). [TODO: document these in invoke.texi, add test cases] it seems useful if you don't have existing committed fixmes all over already, or you can tel those apart easily. It may also be worth suppoting more wordings, for some reason Mozilla uses XXX a lot. > Thoughts? Does any of this sound useful? didn't read the code careful, but the ideas seem useful. Trev