Because there will be a lot of stable functions we only report on them
in the json report as the text report is more meant for summaries.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The go source (ast) visitor will now keep track of all public functions it
finds putting them into lists by category: deprecated, preview, stable.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Do more than collect names, because we're going to need more information
to feed to the eventual check tool.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Teach the implements tool how to detect functions marked deprecated and
marked preview in the go-ceph codebase. Especially helpful will be the
JSON output which can, in the future, be added to a tool-chain that
helps track when deprecated functions are to be removed and when preview
functions should become stable.
Note that this change ONLY implements the detection of
preview/deprecated based on the doc comments.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add new arguments to 'implements' that allow for specifying one or more
report type and either a dash ('-' meaning stdout) or a file name to
control where the report is written.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This io.Writer will be the destination for writes from the report.
This better matches with what the JSON report was doing.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This is a dev tool mainly for just those of us who work on the project,
so this is mainly just a quick-start type description.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
To be clearer about what the tool detects, rename "covered" to "found"
such as not to indicate an undocumented but used function is considered
"covered". Future arguments about what "covered" really means to be
scheduled at a later date. :-)
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Currently, annotating the functions (are they documented, deprecated,
etc) in the function listing is not very costly and there are very
few situations where that extra information would be unwanted. Just
annotate the listing every time when running the tool.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Allowing the tool to generate a JSON report makes it easier to add
additional tools later to make use of this data, without hand parsing
the text output.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add simple reporting functionality to the implements package that is
intended to mimic the output of the current contrib/apicompare.py
script.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a file for processing C sources using the `castxml` tool. This tool
produces XML describing a C AST. This file adds go code for invoking the
tool and minimal processing of the XML it generates.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This code makes use of Go's native AST processing packages and allows us
to analyze our source code using the go-ceph conventions.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This log.go file establishes the ability for the package's user to hand
it any logger that meets the very minimal interface.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
John Mulligan