| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The scanner is chocking on the `__float80` and `__float128` types that
are provided by GCC as extensions to ISO/IEC TS 18661-3:2015:
https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
Fixes: #384
|
|
|
|
|
|
|
|
| |
This is to compensate the for the lack of unistd.h on Visual Studio
builds, and to avoid the compiler warning about the implicit declaration
of access() as a result. This is to also prepare for the next commit
when we force-include msvc_recommended_pragmas.h from GLib on Visual
Studio builds.
|
| |
|
|
|
|
|
|
|
|
|
| |
With !45 special casing of bool in the lexer was removed which previously allowed the usage of
bool without including stdbool.h. This breaks scanning of graphene headers
which guarded the stdbool include with __GI_SCANNER__ (I haven't figured out why).
Add back the special handling for bool in the lexer and also map it to gboolean like
_Bool as if stdbool.h was included.
|
|
|
|
| |
Reduce total number of memory allocations and increase data locality.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It just printed errors to stderr and always returns success even if parsing
fails. This prevents us to write any tests for it.
As a first step collect all lexing/parsing error messages and print them to stderr after
the scanner is done. This allows us to add some regression tests for !78.
In the future we probably want to raise an exception with those errors if parsing
fails.
|
|
|
|
|
|
| |
This makes it possible to parse inputs where typeof is used as part of
cast expression, e.g., in g_object_ref macro expansion. Selection of
VOID is arbitrary since there is no actual implementation of typeof.
|
|
|
|
|
|
|
| |
GLib 2.57.2 introduced __typeof__ in g_clear_pointer, which the scanner
failed to parse.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/328
|
|
|
|
| |
It's DWORD and gcc complained about defaulting to int.
|
|
|
|
| |
It was never defined because G_OS_WIN32 was used before the glib include.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recognize additional floating point types from ISO/IEC TS 18661-3:2015,
that are already in use by glibc. This continues work from commit
8cf3e8e5cf6d0d49db359f50c6eb0bc9ca22fbef and fixes issue #201.
* _Float16
* _Float32
* _Float64
* _Float128
* _Float32x
* _Float64x
* _Float128x
Use a single BASIC_TYPE token for basic types, while using its string
representation as a type name. This also fixes incorrect type used
previously for __uint128_t, __int128_t, __uint128, __int128, and
_Float128 (they have been mapped to int and float respectively).
Also avoid mapping bool and _Bool to gboolean as those are distinct
types and generally ABI incompatible. Fixes issue #202.
After this changes, when _Bool, _Float* or _int128 types are used
as a part of public API, g-ir-scanner will produce warning about
unresolved type. This is appropriate given that they are currently
inexpressible in GIRepository format.
|
|
|
|
|
|
|
|
|
| |
_Thread_local is a C11 keyword, and thread_local is a macro to make it
more confortable to read. As this keyword can only be used in variable
declarations, not in function return values or parameters, it cannot
be included in bindable APIs and we can safely ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=756921
|
|
|
|
|
|
|
|
|
| |
The ISO/IEC TS 18661-3:2015 standard added new floating point types to
the C standard.
Newer versions of the GNU C library started exposing `_Float128` in the
headers, which means we need to add this type to the known tokens, to
avoid warnings.
|
|
|
|
|
|
|
|
|
|
| |
It looks like flex 2.6.1 changed [1] the return code for EOF in
yyinput. Therefore, use the right value depending on the version of
flex which generates the lexer.
[1] https://github.com/westes/flex/commit/f863c9490e6912ffcaeb12965fb3a567a10745ff
https://bugzilla.gnome.org/show_bug.cgi?id=773272
|
|
|
|
|
|
|
| |
These qualifiers are present in header files on macOS (introduced in
XCode 7).
https://bugzilla.gnome.org/show_bug.cgi?id=784458
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752047
|
|
|
|
| |
Forgot to amend.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752904
|
|
|
|
|
|
| |
Otherwise API using it will badly break in weird ways.
https://bugzilla.gnome.org/show_bug.cgi?id=745608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates giscanner/scannerlexer.l by ignoring the Visual C++-specific
directives, so that the scanner will not bail out while trying to produce
the introspection dumper program source code, and silence many of the
warnings that are produced in the process.
As the Visual C++ processor produces slightly different line markers, we
need to handle this here as well, otherwise the sources/headers would not
be processed to acquire the _get_type and _get_gtype symbols to put in the
introspection dumper sources, producing bad results.
https://bugzilla.gnome.org/show_bug.cgi?id=728313
|
|
|
|
|
|
|
|
|
|
| |
This shows up in the headers in FreeBSD's stdlib. Now I didn't add
anything to regress.h because I think that'd introduce an effective
hard dependency on a C11-capable compiler, unless we used #ifdef
trickery. But the problem with #ifdef is that the -expected.gir isn't
conditional.
https://bugzilla.gnome.org/show_bug.cgi?id=724851
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=724887
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=724887
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=724737
|
|
|
|
|
|
| |
Improves support on MacOS when scanning system headers.
https://bugzilla.gnome.org/show_bug.cgi?id=631507
|
|
|
|
| |
It's possible for scanner->current_file to be NULL, so add a check...
|
|
|
|
|
|
|
|
| |
Aliasing TRUE or FALSE is not very common, but done occasionally
for extra clarity. Namely G_SOURCE_REMOVE / G_SOURCE_CONTINUE are
self-explanatory, unlike the "raw" booleans.
https://bugzilla.gnome.org/show_bug.cgi?id=719566
|
|
|
|
|
|
| |
Otherwise we can overflow the stack on longer pathnames.
Tested-By: Mantas Mikulėnas <grawity@gmail.com>
|
|
|
|
|
|
|
|
|
| |
path
This fixes the case when the include path doesn't contain any symlink,
but the path built by the preprocessor does.
https://bugzilla.gnome.org/show_bug.cgi?id=712211
|
|
|
|
|
|
|
|
|
| |
When scanning for macros respect ifdefs of __GI_SCANNER__
in the various header files. Only #ifdef and #ifndef are supported.
If __GI_SCANNER__ appears in plain #if statements, a warning is
printed.
https://bugzilla.gnome.org/show_bug.cgi?id=698367
|
|
|
|
|
|
|
|
|
|
|
| |
giscannermodule expects file names to be canonicalized and
symlinks to be resolved (most likely to support users of
symlinked /usr/local). Instead of computing absolute and real
paths all over the place, we can do this once on entry
in SourceScanner().parse_files() and SourceScanner().parse_macros()
and clean the rest a bit...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Was looking around a bit and noticed about 2/3 of
g-ir-scanner time is spent in SourceScanner().parse_files().
Some profiling quickly shows most of that 2/3 is used
by gi_source_scanner_add_symbol() where it creates a whole
bunch of GFile instances just to compare paths and throw
them away again. With this a scanner instance now maintains
a hash table of GFile instances instead of a list of file
names, so comparing those paths can be reduced to a fast
g_hash_table_contains() call.
This makes "g-ir-scanner <whole_bunch_of_options> --output Gtk-3.0.gir"
complete in about 10 seconds on my box instead of about
30 seconds (both best of 3 runs).
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
|
| |
This was broken in 0d6db7114a176c2d24a19a2d6a570aab406608ac
where the unescaped filename was still computed but
no longer used...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
| |
They should be treated the same as regular volatile specifiers,
not like __attribute__() or __asm__().
|
|
|
|
|
|
|
|
|
|
|
| |
When encountering /**/ in the source, parse_gtk_doc_comment()
would be executed (due to the /** part starting a GTK-Doc
comment block) and would happily consume the / and everything
up until the next comment block was closed or EOF, thus
consuming a whole block of C code...
Encoutered in the wild here:
https://git.gnome.org/browse/clutter-gst/tree/clutter-gst/clutter-gst-player.c?id=03f0d8f48bd7f60e582e6185cb73a07038e8d55d#n1926
|
|
|
|
|
| |
This reverts commit ebffefb27ed81b095106056698dd8db9a21fb6f9.
Pushed by mistake
|
|
|
|
|
| |
They should be treated the same as regular volatile specifiers,
not like __attribute__() or __asm__().
|
|
|
|
|
|
|
|
|
| |
This is a hack, but all we really want to do is ignore them for
now.
See https://mail.gnome.org/archives/gtk-devel-list/2013-May/msg00013.html
https://bugzilla.gnome.org/show_bug.cgi?id=699722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the spirit of c9708af2 also parse and ignore
__asm [whitespace] volatile
__asm__ [whitespace] volatile
__volatile
__volatile__
Ignoring __volatile is cosmetic, but the __asm cases avoid an unwanted
VOLATILE token. Extension of
https://bugzilla.gnome.org/show_bug.cgi?id=678794
|
|
|
|
|
|
|
|
|
|
| |
For example, GTK+ has over 15.000 comment blocks (/* ... */)
of which only about 5.000 are GTK-Doc comment blocks (/** ... */).
No need to store and parse those +-10.000 comment blocks
just to find out we don't care about them anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=697625
|
|
|
|
|
|
|
|
|
| |
This let the macro expands to its value as gint64/guint64.
Also
- fix lexer identifier/typdef detection for macro and misc
- do not discard cast
|
|
|
|
|
| |
This avoids a bit of python work and reduces the
amount of allocations.
|
|
|
|
|
|
|
|
|
|
|
| |
In Sandro Sigala's original c-c++-grammars code, this function
was known as "static void skip_comment(void)". It was built this
way instead of a lex pattern because it didn't need to save the
matched comment in the "yytext" buffer. This is still true as
we directly assign the matched comment to the scanner object.
So simply prepend and append the markers back where they belong.
https://bugzilla.gnome.org/show_bug.cgi?id=672254
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=672254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Modify the lexer to consider all "trigraph" comments specially, and
parse them for "flags" as well as "private" and "public" (which were
previously hardcoded). This change allows for future support of
multiple annotations inside a single trigraph comment.
- Change the parser to consider the additional field "flags" set by
the lexer when constructing enums.
- Add a test case for the "flags" trigraph comment to the scanner
annotation tests.
See <https://bugzilla.gnome.org/show_bug.cgi?id=631530>.
|
|
|
|
|
|
|
| |
This is useful e.g. on cygwin, where system headers use #pragma directives,
causing annoying false-alarm errors during every g-ir-scanner run.
https://bugzilla.gnome.org/show_bug.cgi?id=630994
|
|
|
|
| |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=594125
|
|
|
|
|
| |
Rewrite the pre-processor linemark parser so we end
up with accurate filenames and linenumbers.
|
| |
|