| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Removes the existing Autotools build system and adds a new Meson one.
Also replaces the shell script test driver with a Python one, since
Meson already brings in a Python dependency.
Common operations:
- ./configure -> meson _build
- make -> ninja -C _build
- make install -> ninja -C _build install
- make check -> meson test -C _build
- make Tartan.pot-update -> ninja -C _build tartan-pot
- make update-po -> ninja -C _build tartan-update-po
To run the tests with coverage enabled and make a coverage report:
- meson _build -Db_coverage=true
- meson test -C _build
- ninja -C _build coverage-html
|
|
We assume that in any catch blocks, program state has already been
modified since an exception has been thrown, so we only look for
assertion statements in the try block.
|
|
This type of expression can occur in several instances, but primarily in
C++ where a temporary object is created. In is_assertion_stmt() and
_simplify_boolean_expr(), only consider the expression and ignore the
cleanups.
Adds some machinery to the build system and the test runner script so
that we can have test files in C++, for testing C++-only features.
|
|
Some minor API changes are needed for this.
We also make 7.0 the minimum required version. It's the version
currently shipped in Debian Stable, so that's a good baseline. (At the
time of writing, 9.0.0 is the latest released version.)
Fixes: #5
|
|
Remove all the guards that checked for earlier versions.
See: #5
|
|
On macOS, clang will unhelpfully print "(framework directory)" after
some of its include paths. Filter this out, so that we don't
accidentally stick it in the tartan command line.
|
|
The previous code seems to be accidentally looking in the srcdir.
|
|
|
|
If $srcdir is a relative path, for example starts with "../", then the
temp files in this script will escape their temp dir. To prevent this,
use $(mktemp -d)/$abs_top_builddir as the temp dir, so that the relative
path has somewhere to go.
|
|
I was told by a Clang static analyzer developer that running the
analyzer without the core checkers enabled is not supported, and I've
seen that it can lead to crashes.
For this we need to make a few changes to the test programs. In
gvariant-iter we need to avoid tripping a warning from a core checker,
and in gerror-api we can remove two tests for cases that a core checker
already detects.
See https://bugs.llvm.org/show_bug.cgi?id=42816
|
|
As described in commit 0743df4033967c18a5009e4f01ccf709f7c06c86, LLVM
changed an error message between 3.4 and 3.5. We ignored the problem
before, but actually it’s easy (if hacky) to fix by checking against
both versions of the error message in the wrapper script.
|
|
They turn out to be useful.
|
|
As a follow up to commit 915a744037d93abfcaab8b35e98e281cf88bb132, add a
non-GLib test, which checks that scanning a file which doesn’t include
glib.h succeeds.
|
|
This is a path-sensitive checker which detects various invalid usages of
the GError API from GLib, such as overwriting GErrors which have not
been cleared to NULL, or double-freeing GErrors. It can statically
detect all run time errors from preconditions in GError methods.
Includes a full unit test suite with > 95% coverage.
|
|
|
|
This should aid future debugging.
|
|
The wording of the non-null warning messages changed between LLVM 3.4
and LLVM 3.5, so the tests were all arbitrarily failing.
This change makes them work on LLVM 3.5 at the expense of failing on
LLVM 3.4. There’s no satisfactory way to improve this, short of
duplicating the test files and having one copy for 3.4 and one for 3.5.
|
|
It seems common to use a gpointer argument for the swapped instance
parameter (i.e. the last argument) to a signal callback, even though
this is not the most specific type known for the variable.
Allow this behaviour — hopefully the programmer is correctly dynamically
casting the gpointer to something more concrete in the callback body.
Either that, or (more likely), ignoring it entirely.
|
|
Previously they were expected to be passed as pointers, which was not
correct. Now they are expected to be passed by value.
|
|
Fallout from 234ba46cd95026e763d6a8d7c19cd561c0520ee6.
|
|
If the user passes an architecture-dependent type into a GVariant
variadic function, the behaviour will differ between architectures,
which we really do not want — essentially the code would be using the
wrong width integer on one architecture but not another, which would be
hard to track down. This is mostly a problem with ‘long’, which is 32
bits wide on 32-bit systems, and 64 bits wide on 64-bit systems.
This was a problem encountered in the wild in telepathy-gabble. Thanks
to Simon McVittie for suggesting that Tartan check for it.
|
|
Otherwise we can end up with error messages which recommend using a C
standard ‘long’, whose width varies between architectures. Using that is
a bad idea.
|
|
Previously, Tartan would enforce the type relationship:
actual <: static
but this was wrong, as then the callback could legitimately be invoked
with an instance of type T, where:
actual <: T and T <: static
and it could proceed to call methods defined on actual which are not
defined on T, and crash.
Instead, the following relationship has to hold:
static <: actual
which guarantees that for any T passed to the callback, since we have to
have T <: static, we definitely also have T <: actual, which is the
necessary condition for type safety of function parameters on
invocation.
Additionally, check whether
static = actual
and emit a remark if that relationship does not hold, as the callback is
most likely performing unnecessary and inefficient dynamic type checks
in this case.
|
|
So that extraneous test output does not affect the result matching.
|
|
It is perfectly valid to specify a signal name with hyphens or with
underscores, so support both in the checker.
|
|
…rather than GError**. If that were the case, multiple handlers for the
signal would collide on setting the GError. There is no way it could
work sensibly.
|
|
It is most likely due to a GIR containing the signal information not
being available. As such, make the messages remarks rather than
warnings.
|
|
Previously the checker would not find the information about a signal
which was defined on an interface implemented by the dynamic instance
object (or one of its superclasses).
|
|
This is a minefield.
g_signal_connect_swapped() is intended to be used in situations where
the number of formal parameters in the callback function differs from
the number of actual parameters emitted by the signal. This allows the
common idiom of (e.g.) calling gtk_widget_hide() on a signal callback
from another object, with the widget being passed in the user_data.
It turns out that these situations are entirely implementation defined.
The C specification disavows all knowledge of how parameter passing
should work when the callback function prototype isn’t known, leaving
this to the calling convention to define.
All calling conventions that we care about handle this sensibly,
explicitly covering the case of the number of actual parameters
exceeding the number of formal parameters, just like they handle
varargs. However, there are a few calling conventions which won’t handle
this properly, and will cause explosions should you try. For example, I
believe that passing a WinAPI function (calling convention: stdcall) as
a signal callback will cause problems. I haven’t verified this
experimentally though.
The gsignal-checker now allows for the number of formal and actual
parameters to differ, but only if the calling convention for the
callback function is safe. That should cover things.
|
|
It was mysteriously missing before, because it is actually a hard
problem than it looks to check correctly. This adds support for
g_signal_connect_swapped() and g_signal_connect_data() with the
G_CONNECT_SWAPPED flag.
Currently, the user_data parameter is validated as being any kind of
pointer. This could potentially be tightened up in future to check that
it is a subtype of the closure variable passed into g_signal_connect()
(even in the non-G_CONNECT_SWAPPED case). However, this is best left to
a separate checker which examines closure types.
|
|
Otherwise the handlers could modify the strings.
|
|
When an unexpected extra parameter is passed to a GVariant variadic
function, it is useful to tell the programmer what format string they
can use for it. This is a first draft, and only covers basic types.
|
|
This is the first real bug found in the wild by Tartan, in tp-glib.
|
|
The Clang QualType formatting adds quotation marks, but our error
messages already contained them. Loath as I am to revert to using ASCII
quotation marks, the formatting provided by QualType is quite good
(since it adds aka information), so drop the old Tartan Unicode
quotation marks.
|
|
Previously, the wrapper-compiler-errors script was assuming a test was
successful if it could see at least one of the expected error message
lines in the compiler output. Since several of those lines are
boilerplate, this hid legitimate test failures.
Fix it so that *all* expected lines are checked for (although there are
no checks which test that *only* those lines were output), and fix up a
few tests.
|
|
This validates that:
• The named signal exists on the given GObject subclass.
• The type of the callback function matches that declared for the
signal.
Unit tests are included.
|
|
Make the name a little less GNOME-centric, since the plugin actually
only (currently) deals with GLib, so has much wider application than
just on GNOME code.
Also, ‘Tartan’ sounds cooler.
|
|
Rather than assuming they’re installed.
|
|
Also ensure all the right test files are distributed.
|
|
Test that extracting non-NULL checks from g_return[_val]_if_fail() calls
works.
|
|
If an integer constant is passed as a vararg, it will be passed as a
signed integer to the function. For integers less than G_MAXINT this is
not a problem (as the bit representations of int and uint are the same
to that point). Modify the GVariant checker to accept low-valued signed
integers for unsigned integer GVariant elements.
|
|
The integer constant 0 can be interpreted as NULL, so only perform NULL
pointer checks when the expected type is a pointer.
|
|
This makes the tests a little less hard-coded.
|
|
This loosely depends on the GLib patch in bug #719966.
|
|
This enables GVariant format string checking for:
• g_variant_get_child()
• g_variant_lookup()
• g_variant_iter_next()
• g_variant_iter_loop()
• g_variant_builder_add()
and adds basic unit tests for all of them.
GVariant support is now complete!
|
|
This required a little further work on top of the work for checking
g_variant_new() calls, as g_variant_get() takes outbound arguments,
rather than inbound ones, so has an extra level of indirection. Further
to that, integer promotion doesn’t occur, and nullable arguments are
treated a little differently.
This includes a set of unit tests for g_variant_get().
|
|
This checker will examine the code for GVariant method calls, such as
those to g_variant_new(), and will proceed to check the types of the
variadic arguments in the call against the GVariant format string in
the call (assuming this format string is constant).
For GVariant methods such as g_variant_new_va(), which take a va_list
rather than varargs, the validity of the GVariant format string is
checked, but the va_list itself cannot be.
There are a few limitations to the checker at the moment. These are
noted in FIXME comments, but are minor and don’t affect correctness.
(Implementing them would, however, make the checker more strict.)
A test suite is included with over 100 tests for parsing valid and
invalid g_variant_new() and g_variant_new_va() calls. The test suite
uses a custom test harness which splits up the test file, adds
boilerplate, and then attempts to compile it with gnome-clang enabled.
It then compares the compiler output to an expected error message.
|
