scanner: Warn if we're missing (element-type) for GPtrArray

For background,
See https://bugzilla.gnome.org/show_bug.cgi?id=629682
See https://bugzilla.gnome.org/show_bug.cgi?id=689871

Basically we should emit a warning here.

https://bugzilla.gnome.org/show_bug.cgi?id=689998

Update annotations from glib git

build: Include tests/scanner/annotationparser/* to EXTRA_DIST

tests: Fix up WarnLib build, remove accidental additions to regress.c

Previous WarnLib commit was broken.

build: Use -Bsymbolic-functions by default if available

While we have much larger performance problems right now, using
-Bsymbolic-functions to avoid internal PLT indirection is an easy win.

This is the same code that both GLib and GTK+ have.

https://bugzilla.gnome.org/show_bug.cgi?id=689456

tests: don't fake Automake silent mode

https://bugzilla.gnome.org/show_bug.cgi?id=689570

tests: fix incremental build

Running make multiple times caused "mkdir" to complain
that it could not create those directories because they
where already there...

https://bugzilla.gnome.org/show_bug.cgi?id=689570

WarnLib: New library for testing API that emits warnings

Both GIMarshallingTests and Regress right now use --warn-error; but
in some cases (e.g. GErrors without a corresponding enum), we still
want bindings to support the functionality.

So add this new library where we can add C API that emits
introspection warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=689488

scanner: Parse comments with */ not on a new line, but emit a warning

We don't know how many apps do this, but at least ibus had one.

https://bugzilla.gnome.org/show_bug.cgi?id=689354

gimarshallingtests: Add a utf8-in-bytearray test

Will be used by gjs

giscanner: don't continue parsing after multiline descriptions

This doesn't change anything, really, except that you don't have
to read a whole page of code just to realize that nothing else
happens with that line and we go on processing the next.

Putting the continue statements there makes it a bit more readable.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: fix DocBlock().comment

If there is no comment block description, DocBlock().comment
should be None. This results in the removal of unneeded blank
lines in the output of DocBlock().to_gtk_doc and hence the .c
files generated by misc/update-glib-annotations.py

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: update annotationparser to most recent gtkdoc-mkdb bug fixes.

This patch adds a test for and implements a more generic solution to
GTK-Doc commit 47abcd53b8489ebceec9e394676512a181c1f1f6

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: remove re.MULTILINE usage from annotationparser

These are remnants from the original prototype and are no
longer used.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: Correctly detect invalid GTK-Doc comment block end markers

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: treat the GTK-Doc Description: tag like any other tag

and add paragraph break tests.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: construct list of possible tag names for TAG_RE from _ALL_TAGS...

... instead of having a secondary hard-coded list. This results
in the removal of giscanner/annotationpatterns.py to prevent a
circular import.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: move unit tests from giscanner/annotationpatters.py...

... to tests/scanner/annotationparser/test_patterns.py because the
following patch will remove giscanner/annotationpatters.py

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: add AnnotationParser tests

The tests in giscanner/annotationpatters.py only test the regular
expression programs used when parsing GTK-Doc comment blocks but
do not test the structure of the resulting "parse tree".

This patch adds 193 GTK-Doc comment blocks and the expected
results AnnotationParser should return (with it's current level
of understanding of GTK-Doc comment block syntax). These are
compared by tests/scanner/annotationparser/test_parser.py which
complains with a diff on failure.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: use re.match() instead of re.search()

From Python's documentation:
Python offers two different primitive operations based on
regular expressions: match checks for a match only at the
beginning of the string, while search checks for a match
anywhere in the string (this is what Perl does by default).

The different behavior between match() and search() doesn't
matter in our case and conceptually we are checking if a
piece of text matches a certain pattern, so match() is a
better fit.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: drop dead code

DocOptions already has a position attribute, no need to overwrite it
when the position of DocBlock or DocTag is set, hence the
set_position methods are no longer needed.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: make it clear DocOptions() also has a position attribute

Lost a couple of hours hunting down a failed test case (from the
annotationparser work about to land) due to this not being clear...

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: implement DocOption() in terms of odict instead of dict

The order of the "options" key/value pairs returned by
DocOption().all() should be identical to the order in
which they where stored. Hence replace the dict usage
with odict.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: remove unused variables

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: remove duplicate "os" import...

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: use collections.OrderedDict when available

Starting with Python 2.7 we can use the batteries included
collections.OrderedDict class. However, configure.ac claims
we still support Python 2.5 and 2.6, so don't remove our
custom odict implementation just yet...

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: use dict.values() in favor of dict.itervalues()

This makes it possible to run the upcoming annotationparser.py
tests with both Python 2 and Python 3.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: use dict.items()...

... in favor of "for key in dict: value=dict[key]"
and "dict.iteritems()". This makes it possible to
run the upcoming annotationparser.py tests with both
Python 2 and Python 3.

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: use "if in [a, b]" instead of "if == a or if == b"

It simply looks better...

https://bugzilla.gnome.org/show_bug.cgi?id=688897

giscanner: improve wording of inline documentation

https://bugzilla.gnome.org/show_bug.cgi?id=688897

tests: add g-ir-doc-tool generated output to .gitignore

https://bugzilla.gnome.org/show_bug.cgi?id=688897

Update GLib annotations to master

https://bugzilla.gnome.org/show_bug.cgi?id=688897

GIMarshallingTests: Add more virtual methods with out arguments

Add virtuals method which takes both an (in) and and (out) argument, and
variants with both caller and callee allocation.

This came up in https://bugzilla.gnome.org/show_bug.cgi?id=688783

Regress: Update expected gir for previous changes

Changes introduced by 5153efd29e9a813a97d58905340c0ec4af04c5bd

Add more tests for boxed types

gjs needs a boxed type that cannot be trivially allocated but has also
a complex constructor.

https://bugzilla.gnome.org/show_bug.cgi?id=612033

Bump version to 1.35.2

Our configure.ac still said 1.34.0, which is even older than the stable
gnome-3-6 branch. Bump it to 1.35.2 so that pygobject can depend on >= 1.34.2.

docs: add GTK-Doc generated output to .gitignore

https://bugzilla.gnome.org/show_bug.cgi?id=688418

docs: don't mark non GTK-Doc as being a GTK-Doc comment block

This patch silences another gtkdoc-mkdb warning.

https://bugzilla.gnome.org/show_bug.cgi?id=688418

docs: remove reference to object_grouped.sgml.

This most likely sneaked in as a copy paste error from GTK+
reference docs as g-i never had a object_grouped.sgml...

https://bugzilla.gnome.org/show_bug.cgi?id=688418

docs: make gtkdoc-mkdb ignore cmph doxygen comment blocks.

When building g-i reference documentation, girepository/cmph/*
was being scanned for GTK-Doc comment blocks by gtkdoc-mkdb.
Unfortunately, cmph uses doxygen comment blocks which also
start with /**. This patch prevents gtkdoc-mkdb from complaining.

https://bugzilla.gnome.org/show_bug.cgi?id=688418

GIMarshallingTests: Add GVariant property

giscanner: unbreak g-ir-annotationtool...

... and by extension misc/update-glib-annotations.py.

Commit 5c70ef2eb32949f8889e9ae654d50bfbf838951f broke
these by assuming create_source_scanner() is always
called with 'options' and 'args' built by the
OptionParser() defined in scannermain.py's
_get_option_parser().

This is not the case with g-ir-annotationtool, where
annotationmain.py's annotation_main() creates it's
own OptionParser() accepting a different set of
'options' and 'args' as compared to scannermain.py

Update annotations from glib git

gimarshallingtests: Fix return data type

gi_marshalling_tests_genum_returnv() should (and does) return a
GIMarshallingTestsGEnum, not  a GIMarshallingTestsEnum. The latter is already
covered by gi_marshalling_tests_enum_returnv().

gimarshallingtests: Add some GBytes tests

Will be used by gjs for new byte array work.

https://bugzilla.gnome.org/show_bug.cgi?id=687696

scanner: Emit correct type for unsigned integer constants

Otherwise bindings will break.

https://bugzilla.gnome.org/show_bug.cgi?id=685022

Update annotations from glib git

tests: work around make check warning

The tests in tests/repository/ depend on libregress.so
from tests/scanner which cannot be loaded during make check.
Fixing this properly would require migrating to non-recursive
automake for the tests, but for now we can just work around
and set LD_LIBRARY_PATH (for linux) and PATH (for win32).

http://bugzilla.gnome.org/show_bug.cgi?id=675049

tests/offsets: Remove leftover g_type_init() call

cmph: Remove leftover statement-without-effect

Compiler warning introduced from MSVC patches.

scanner: Correctly handle large 64 bit integer constants

In C, positive integer constants are by default unsigned.  This means
an expression like 0x8000000000000000 will be "unsigned long long".

In the actual scanner code, we were parsing them as "gint64", and
storing them as gint64.  This was incorrect; we need to parse them
as guint64, and store the bits we get from that.  This gives us
an equivalent result to what the C compiler does.

However, when we actually return the value as a Python "long"
(arbitrary length integer), we need to treat the value as unsigned if
the result indicated it was.

https://bugzilla.gnome.org/show_bug.cgi?id=685022

Expand on the documentation tests

Add tests for complex function signatures (including arrays and
callbacks), for enumerations and for static methods.
Add JS reference files.

https://bugzilla.gnome.org/show_bug.cgi?id=683046

MallardWriter: support cross-references across namespaces

Look in included namespaces when resolving a cross-reference.

https://bugzilla.gnome.org/show_bug.cgi?id=683046

Add documentation for enumeration members

Enum members were Annotated in the AST, and most code already assumed
they could have docs. What was missing was reading the docs from the
comment blocks and writing them in the XML.

https://bugzilla.gnome.org/show_bug.cgi?id=683046

Ast: Add parent to Fields

Properties have it, there is no reason for Field not to, and in this
way mallard docs can treat a field almost like a property.

https://bugzilla.gnome.org/show_bug.cgi?id=683046

Namespace: fix appending of nodes

Traverse appended nodes for methods, so that namespace.symbols contains
all known symbols and not just global functions.
Also, ensure that all relevant nodes are appended when parsing GIRs.

https://bugzilla.gnome.org/show_bug.cgi?id=683046

regress: Add a test case for skipping a function with an unannotated callback

https://bugzilla.gnome.org/show_bug.cgi?id=685399

gimarshallingtests: Attempt to avoid using reserved words

"int8" apparently blows up on AIX.  It was kind of lame how we would
just ad-hoc append a _.  Since we only have one value for a lot of
these, let's just go with the couldn't-be-any-simpler "v".

https://bugzilla.gnome.org/show_bug.cgi?id=664166

gmarshallingtests: Fix prototype () -> (void)

Dear Python programmers, () doesn't mean what you think it means in C.

girepository: Use girepository.symbols for Unix builds too

Rather than having a regex for both builds, but *also* use a symbol
file for the MSVC build which would bitrot quickly, force us to update
the .symbols file by using it for Unix too.

Add some missing symbols.

g-ir-scanner.1: English fix

Add a Windows .bat to generate typelibs

This will enable one to generate the .gir and .typelib files for GLib,
GModule, GObject, GIO and G-I without using a bash-style shell on Windows.

This is also the .bat that is used during the Visual C++ build process to
generate the .gir and .typelib files

https://bugzilla.gnome.org/show_bug.cgi?id=681820

giscanner/dumper.py: Support Visual C++

-Pass the --msvc-syntax flag to pkg-config when Visual C++ is used.
-Use .obj instead of .o filename extension when running on Visual C++, as
 that is the default object file name extension on visual C++.
-Specify compiler output flags for Visual C++.
-Avoid using -Wl and -rpath on Visual C++, and link to .lib files instead
 when generating a .gir file within the package.
-Avoid unecessary linking under Visual C++ to the .dll files since we
 already linked to the corresponding .lib files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Update autotools for Visual C++ projects creation

-Add Makefile-msvcproj.am to fill in the cmph, girepository and
 g-ir-compiler projects
-Add various Makefile.am's under build/ to distribute the
 Visual C++-related files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add Visual Studio 2008/2010 Solution files

These are the master solution files that will load the Visual C++ projects
for building/generating gobject-introspection and its related tools and
files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add Visual Studio projects

These are the Visual C++ 2008/2010 project files that can be used to build
gobject-introspection.  The main girepository dll (along with cmph), tools
(in C), certain test/sample programs dlls are built with this project file
set.

Due to a bug in the Visual C++ 2008 linker, the g-ir-compiler and
g-ir-generator tools have the libgirepository-internals sources built
along side with the sources of these respective tool programs.

In order to ease future maintenance, the cmph, girepository,
g-ir-compiler and property sheets (for the "install" part) are done as
templates where header/source listings are filled in during "make dist",
so that the headers/sources listings are kept up to date between releases.

The GLib and girepository .gir and .typelib files are also generated and
"compiled" as part of the build process, using gengir.bat that
was committed earlier.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add README.txt files for Visual C++ builds

Add instructions to tell people how to build gobject-introspection with
Visual C++, especially as there are special steps and additional
requirements for a successful build.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add a test_gir_cmd.txt file

This is to show how one may be able to generate the .gir files from the
various DLL files in tests\ in a standard Windows cmd.exe prompt, which
will also attempt to demonstrate how .gir files are generated without a
shell.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

sourcescannermain.py: Add --filelist option

Add a function to put the files to pass to g-ir-scanner in a filelist
file, with one source/header file on a single line.  This is done to
work around the limitation of Windows cmd.exe (and MSYS) where the command
line cannot exceed 8192 characters.

When this option is used, g-ir-scanner will only look for the header/source
files that are specified in the filelist file, which is not too hard to
generate.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

giscanner/sourcescanner.py: Update for Visual C++ usage

Since the Visual C++ (cl.exe) preprocessor does not accept source input
from stdin (the '-' preprocessor flag, we need to use the GCC preprocessor
as a helper here.

Note that the generated dumper program is still compiled and run by
Visual C++.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add .def files for building the various DLLs (.la's) in test\

This will enable the exports of functions to create the .lib files needed
to create the .gir files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add girepository.symbols

This is the listing of symbols to export from the main libgirepository
.dll/.so.  This is used for example to generate the .lib file from the
Windows DLL.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

Add a pre-configured config.h.(win32.in)

This adds a pre-defined config.h for Windows builds, but versioning info
are updated by autotools.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

giscannermodule.c: Updates for Windows

-Incorporate and extend Dieter's patch regarding possible different CRTs
 used in Windows Python (msvcrt71.dll for Python 2.5, msvcrt90.dll for
 Python 2.6- 3.2, and msvcrt100.dll for Python 3.3+) vs. the CRT used to
 build g-i (msvcrt.dll for MinGW/WinDDK, msvcrt90.dll for stock MSVC 2008
 and msvcrt100.dll for stock MSVC 2010)
-Avoid C99ism for NEW_CLASS as we are having an array without a
 pre-determined length.  There might be better ways to get around this
 though.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

giscanner/dumper.py: Use os.name instead of os.uname()[0]

os.uname is not available universally, so use something that exists
universally.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

girepository: Remove C99ism and other updates

-Make code using libgirepository_internals relocatable on Windows,
 like what is done in the GTK+ stack, and the girepository DLL.
-Remove C99isms
-"interface" is a reserved keyword on certain compilers, so change that to
 "giinterface"

https://bugzilla.gnome.org/show_bug.cgi?id=681820

giscanner/scannerparser.y: Avoid C99ism

Move variable declarations to the start of block.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

girffi.c: Don't include unistd.h unconditionally

It does not exist on all platforms

https://bugzilla.gnome.org/show_bug.cgi?id=681820

cmph: Remove C99ism and other fixes

...So that it will compile on non-C99 compilers.  The changes are mainly
moving the variable declarations to the start of the resecptive blocks.

Also, replace the use of buflen in chd.c as it might not be defined for all
platforms, instead using packed_cr_size as it seems to represent the value
that is to be printed/displayed by the debugging output.

https://bugzilla.gnome.org/show_bug.cgi?id=681820

docs: Show correct path used by g-ir-scanner

Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=668193

scanner: Ignore #defines starting with _

This matches our behavior for symbols (and we should probably fix this
more globally...I think we still scan _-prefixed enums).

Noticed from gudev which had #define _GUDEV_INSIDE_H 1

https://bugzilla.gnome.org/show_bug.cgi?id=674072

Python3-friendly python.m4

https://bugzilla.gnome.org/show_bug.cgi?id=678728

common: Ensure we use $(CC) from environment when compiling scanned binaries

GNU make will default to "gcc" if "cc" isn't found; we need to
replicate that behavior here.

Patch-suggested-by: ojab <ojab@ojab.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=678678

Update annotations from glib git

Update annotations from glib git

giscanner: Don't prefer identifier prefixes over namespaces in deps

Use namespaces in dependencies before falling back to the deprecated
--identifier-prefix prefixes.

scanner: Deprecate using identifier prefixes in GINames

Instead of crashing.  For more details, see the attached bug.

Based on a patch by Stef Walter <stefw@gnome.org>.

https://bugzilla.gnome.org/show_bug.cgi?id=684370

Update annotations from glib git

Drop calls to g_type_init()

And bump our GLib requirement.

[gobject-introspection] Add test method for GDestroy with no user data

Added regress_test_callback_destroy_notify_no_user_data.
Updated Regress-1.0-expected.gir

https://bugzilla.gnome.org/show_bug.cgi?id=685922

gimarshallingtests: Add array/GList uint32/64 in/out API

Add in/out API for testing arrays containing uint64, as well as GList
containing uint32 (GList and GHash can't contain 64 bit values as they store
them in pointers).

https://bugzilla.gnome.org/show_bug.cgi?id=685860

Make gtk-doc not a hard dependency of gobject-introspection

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=684795

Release 1.34.0

Update annotations to glib 2.34.0

configure: Post-release version bump

Release 1.33.14

Update annotations from glib git

regress: Add API to test signals with (u)int64 params

https://bugzilla.gnome.org/show_bug.cgi?id=683596

Co-Authored-By: Martin Pitt <martinpitt@gnome.org>

Update annotations from glib git

gimarshallingtests: Add in/out int64 GValue method arguments

See https://bugzilla.gnome.org/show_bug.cgi?id=683596