cleanups with long-term benefits (was Re: [PATCH] schemas: Add vim modeline)

[Paolo Bonzini <pbonzini@redhat.com>]

On 31/07/20 17:07, Daniel P. Berrangé wrote:
> The QAPI JSON-but-not file format is a case where I think we should just
> adopt a standard file format no matter what. A conversion will have some
> short term work, but this is really simple data to deal with and the code
> involved is nicely self contained. Again I'm not saying QAPI maintainers
> must do it, just put the idea out there as a piece of work that would
> be welcomed if someone is interested in working ont.

The main issues with JSON-but-not in QEMU are:

- the 64-bit integers, which does not apply to the QAPI schema though

- the comments, which are a common extension to JSON (see JSON5, NodeJS
config files, json_verify's -c option, etc.) so I find it quite surprising
that no off-the-shelf Python component can parse JSON + comments

- the single-quote strings, which are not particularly useful in QAPI schema

If we changed the single-quote strings to double-quote, jsonc.vim
(https://github.com/neoclide/jsonc.vim) seems to support JSON + comments.
In Emacs you'd probably add an epilogue like

(defconst json-mode-comments-re (rx (group "#" (zero-or-more nonl) line-end)))
(push (list json-mode-comments-re 1 font-lock-comment-face) json-font-lock-keywords-1)

Did I miss anything?

Besides that, why are we using Python and not JavaScript in the mode line?

> Another example would be elimination of anything in QEMU code that is
> duplicating functionality in GLib, even if there zero functional
> difference between the two impls.

Would you consider intrusive lists vs. GList/GSList to be duplicating 
functionality?  I don't think we have that many duplicates at this 
point.

We have qemu_strto*, but unfortunately the GLib function g_ascii_strtoll
does nothing to fix the awful design of the C standard strto* functions
(especially the overloading of the return value for error and result).
If there are cases that are clear cut against adopting the GLib version,
I think patches would be easily accepted.

> Another example would be adopting a standard code style and using a
> tool like clang-format to enforce this for entire of existing code
> base and future contributions and throwing away our checkpatch.pl
> which nearly everyone is scared of touching as it is Perl code.

Checkpatch does much more than that, though the scary part is indeed the 
one that enfoces coding style.  I wouldn't have a problem with using
clang-format and calling it a day.

Paolo