summaryrefslogtreecommitdiff
path: root/giscanner
Commit message (Collapse)AuthorAgeFilesLines
* Fix errors parsing OSX 10.9 headersDavide Bertola2014-02-131-0/+4
| | | | | | Un-defining __BLOCKS__ disables blocks in system headers (like stdlib.h). This avoids errors while compiling.
* scanner: Improve compatibility with OS XClemens Lang2014-02-102-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While gobject-introspection works on OS X, a few circumstances are handled a little different there. For one, libraries are linked using absolute paths. The current gobject-introspection code however strips any path components and just uses the filename in the .gir file – while this doesn't cause failure, the generated typlibs will only work in presence of a correctly set DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH environment variable. Setting DYLD_LIBRARY_PATH on OS X often is a bad idea due to the side-effects: Doing so causes the directory parts of libraries referenced using an absolute path to be ignored if there is a equally named file in the directory listed in $DYLD_LIBRARY_PATH, possibly overriding referenced system libraries with incompatible versions. Setting DYLD_FALLBACK_LIBRARY_PATH is the better solution for this problem; however because this variable has an implicit default value it's not simple to do so correctly. The best solution to the problem is referencing libraries from .girs using absolute paths, just as all other binaries on OS X. The attached patches against 2.38.0 implement that. Another quirk one needs to be aware of on OS X is that Apple ships a program called libtool, which is not GNU libtool and incompatible with it. GNU libtool, if present, is usually called glibtool on OS X. The patches also fix this. https://bugzilla.gnome.org/show_bug.cgi?id=709583
* scanner: Report __inline__ as the inline tokenEmmanuele Bassi2014-02-101-0/+1
| | | | | | Improves support on MacOS when scanning system headers. https://bugzilla.gnome.org/show_bug.cgi?id=631507
* docwriter: Don't render private nodesJasper St. Pierre2014-01-311-0/+3
| | | | | This prevents fields like __gtk_reserved1 from being emitted in the documentation.
* scanner: Replace GInitiallyUnowned field sharing with generic solutionSimon Feltman2014-01-042-17/+7
| | | | | | | | | | | | Remove GInitiallyUnowned special case in gdumpparser where fields are copied from GObject. Add generic solution where anytime we have multiple typedef structs, the fields become shared: typedef struct _Foo Foo; typedef struct _Foo Bar; struct _Foo {...}; https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Cleanup exception handling in the transformerSimon Feltman2014-01-041-42/+15
| | | | | | | | | Move exception handling of various symbol/identifier stripping into the outer level parse function. This removes a lot of embedded try excepts peppered throughout the code by letting exceptions flow to the top level where they can be handled just as gracefully. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Remove typedef namespace cacheSimon Feltman2014-01-041-20/+0
| | | | | | | | | Remove the caching of typedefs in Transformer._typedef_ns. This is no longer used due to the added _tag_ns cache which store tags rather than typedefs. Remove adding of callback typdefs to the typedef_ns since these were not being used anyhow. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Use tag namespace for parsing unionsSimon Feltman2014-01-041-74/+30
| | | | | | | Generalize _create_tag_ns_struct for both structs and unions. Remove _create_compound newer struct parsing code has completely replaced it. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Add simplified parsing for nested structsSimon Feltman2014-01-041-4/+7
| | | | | | | | Add _create_member_struct for the parsing of nested structs. This is precursory work to remove the member/anonymous flag from other struct/union creation code and allow simplification of those code paths. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Fix parsing for various typedef struct orderingsSimon Feltman2014-01-042-10/+106
| | | | | | | | | Add structs parsed from C's "tag namespace" into their own cache for lookup by typdef parsing. This fixes issues where a typedef declared after a struct would not have a correct name. This also cleans up the need for special casing struct tags prefixed with an underscore. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* scanner: Fix get_symbols/comments to maintain the scanner listsSimon Feltman2014-01-022-2/+18
| | | | | | | | | | | | Use g_slist_copy prior to returning the lists run through g_slist_reverse. This preserves the source scanners internally held lists where previously they would only point to a single element after a call, leaking memory and breaking subsequent calls. Note the functions as (transfer container) and use g_slist_free after calls in the Python bindings. Add new unittest file: test_sourcescanner.py for isolated unittesting of the SourceScanner. https://bugzilla.gnome.org/show_bug.cgi?id=581525
* Honour CPPFLAGS as we do CFLAGSRyan Lortie2013-12-212-0/+7
| | | | | | | In all of the places that we pass through the CFLAGS, we should be doing the same with the CPPFLAGS. https://bugzilla.gnome.org/show_bug.cgi?id=720063
* scannerlexer: Fix bad unrefJasper St. Pierre2013-12-171-1/+2
| | | | It's possible for scanner->current_file to be NULL, so add a check...
* dumper: use 'cc' as the default C compilerRyan Lortie2013-12-081-1/+1
| | | | | | | | If $(CC) is unset, use 'cc' instead of 'gcc' as the default compiler. This matches the behaviour used in the source scanner. https://bugzilla.gnome.org/show_bug.cgi?id=720066
* scanner: make sure we pass CFLAGS to cppRyan Lortie2013-12-081-0/+1
| | | | | | | | When doing the source scanning in giscanner, make sure we pass the user's CFLAGS environment variable to the compiler, as we do for the dumper. https://bugzilla.gnome.org/show_bug.cgi?id=720063
* scanner: Support boolean constantsFlorian Müllner2013-11-297-4/+43
| | | | | | | | 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
* scanner: Use PATH_MAX, not hardcoded 1024 for realpath()1.39.0Colin Walters2013-11-161-1/+15
| | | | | | Otherwise we can overflow the stack on longer pathnames. Tested-By: Mantas Mikulėnas <grawity@gmail.com>
* giscanner: Handle the case when there's a space between -I cpp flag and the pathCarlos Garcia Campos2013-11-161-0/+3
| | | | | | | | | | In this case we were considering -I and the path as two different command line options. This was not a problem in the past (or for other cpp flags) because they are passed directly to gcc that accepts it. Now that we are ensuring that the include paths are always real paths, we need to handle this case to identify include paths in the command line. https://bugzilla.gnome.org/show_bug.cgi?id=712211
* giscanner: Make sure we use real paths in more placesCarlos Garcia Campos2013-11-154-7/+20
| | | | | | | | Ensure we are using the real path also for cflags comming from pkg_config files and command line options. This fixes the generation of the gir files when include paths contain symlinks. https://bugzilla.gnome.org/show_bug.cgi?id=712211
* giscanner: Make sure that the current path set from linemarks is also a real ↵Carlos Garcia Campos2013-11-151-1/+55
| | | | | | | | | 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
* scanner: Don't barf on anonymous unionsColin Walters2013-10-301-0/+1
| | | | | | | | I'd like to be able to use this inside GTK+. See: https://bugzilla.gnome.org/show_bug.cgi?id=711153 https://bugzilla.gnome.org/show_bug.cgi?id=711157
* giscanner: Test fixups for field annotations and documentationStef Walter2013-10-281-7/+12
| | | | Related to: https://bugzilla.gnome.org/show_bug.cgi?id=710561
* giscanner: Include field documentationStef Walter2013-10-281-1/+1
| | | | | | Structure field documentation was not being included in the gir file. https://bugzilla.gnome.org/show_bug.cgi?id=710562
* giscanner: Correctly consume field annotations on structsStef Walter2013-10-283-18/+52
| | | | | | | | A hidden exception was being thrown (which we now log), due to fields being treated as function parameters. Fixed to make field array annotations be transformed and written out to the gir correctly. https://bugzilla.gnome.org/show_bug.cgi?id=710561
* sourcescanner: Removed unused struct_or_union_or_enum_table fieldStef Walter2013-10-212-13/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=710560
* giscanner: Respect __GI_SCANNER__ when scanning for macrosStef Walter2013-10-214-3/+191
| | | | | | | | | 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
* giscanner: remove g_realpathDieter Verfaillie2013-10-175-82/+10
| | | | | | | | | | | 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
* giscanner: speed up SourceScanner().parse_files()Dieter Verfaillie2013-10-175-102/+96
| | | | | | | | | | | | | | | | | | | 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
* giscanner: restore linemark filename unescapingDieter Verfaillie2013-10-171-15/+14
| | | | | | | | 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
* Revert "sourcescanner: Avoid scanning files when doing a macro scan"Dieter Verfaillie2013-10-171-16/+11
| | | | | | | This reverts commit 77fcc8fa47d63f58b2c3f6216a0493e42f6d44b3. Will be not needed in about 2 patches... https://bugzilla.gnome.org/show_bug.cgi?id=710320
* Revert "sourcescanner: Do some fast path checks on the filename"Dieter Verfaillie2013-10-171-5/+0
| | | | | | | | | This reverts commit 8c0ca4717d834a6c578579656683c55ea22a06f4. The "fast" path doesn't seem to work at all. Testing shows creating Gtk-3.0.gir still takes about 30 seconds with this (even on a Linux box)... https://bugzilla.gnome.org/show_bug.cgi?id=710320
* scannerlexer: don't reject __volatile__ tokensGiovanni Campagna2013-10-161-2/+2
| | | | | They should be treated the same as regular volatile specifiers, not like __attribute__() or __asm__().
* sourcescanner: Do some fast path checks on the filenameJasper St. Pierre2013-10-151-0/+5
| | | | | | Going through the VFS layer is substantially slower, so check against the base filenames first. This speeds things up on case-sensitive filesystems.
* sourcescanner: Avoid scanning files when doing a macro scanJasper St. Pierre2013-10-151-11/+16
| | | | We already know the condition will be TRUE.
* giscanner: remove Python xml attribute formatterDieter Verfaillie2013-10-091-44/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no sense in keeping it around as it is never used. And even though measuring the time it takes to build Gtk-3.0.gir using a) the C version and b) the Python version reveals there is no measurable difference to speak of (when *not* running under Python's cProfile module): With C collect_attributes: ========================== real 0m30.614s real 0m32.255s real 0m31.034s With Python collect_attributes: =============================== real 0m31.530s real 0m31.549s real 0m31.673s The C version ends up using g_markup_escape_text() which will escape \004 as &#x4;. Even though this is invalid xml 1.0 (but valid xml 1.1), the Python version leaves the \004 as is, which is even less desirable...
* giscanner: remove unneeded isinstance checkDieter Verfaillie2013-10-091-3/+2
| | | | | | _write_class() is only ever called with ast.Class and ast.Interface nodes so the check served no purpose other than contribute to global warming...
* giscanner: write '<varargs/>' instead of '<varargs></varargs>'Dieter Verfaillie2013-10-081-2/+1
|
* giscanner: fix c0e748e1cdf8cf0803266f94c3c5ad154df504a8Dieter Verfaillie2013-10-082-51/+50
| | | | | | | | | | | 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
* giscanner: complain about text before the ' * 'Dieter Verfaillie2013-10-081-0/+9
| | | | | | Makes our GTK-Doc comment block rewriting tool halt on such issues, requireing user intervention instead of writing back even more bogus data.
* giscanner: write virtual method instance parameter docs to .gir fileDieter Verfaillie2013-10-081-0/+6
|
* giscanner: make Annotated.attributes an OrderedDictDieter Verfaillie2013-10-083-4/+4
| | | | | | annotationparser.py already stores attributes in a mapping so it makes little sense using a list of tuples (suggesting multiple duplicate keys would be allowed) on the ast side.
* giscanner: return namedtuples where appropriateDieter Verfaillie2013-10-081-65/+77
| | | | | makes _parse_annotations() and _parse_fields() callers slightly more readable
* giscanner: Fix GtkDocBlock.position...Dieter Verfaillie2013-10-081-59/+119
| | | | | ... so it points to the start of the GTK-Doc comment block instead of the position of the identifier field.
* giscanner: don't generate synthetic names for '...' parameterDieter Verfaillie2013-10-081-8/+8
| | | | tests/warn/unkown-parameter.h:41 still passes with this...
* giscanner: refactor GTK-Doc comment block serializationDieter Verfaillie2013-10-082-105/+198
|
* giscanner: make some warnings errorsDieter Verfaillie2013-10-081-23/+23
| | | | | | | GTK-Doc comment block fixer tool will refuse to rewrite source files that generated errors (indicating a source->parse tree->source would result in information being lost), but will happily continue on warnings (which do not result in information being lost).
* giscanner: use proper terminologyDieter Verfaillie2013-10-081-49/+50
|
* giscanner: honor line and paragraph breaks in description fieldsDieter Verfaillie2013-10-082-19/+40
| | | | | | | | | GTK-Doc parameter description fields are allowed to span multiple lines, tag description fields are allowed to span multiple lines and paragraphs. A tool fixing/rewriting GTK-Doc comment blocks in source files would need to have description fields parsed and stored (almost) exactly as they appear in the source file.
* giscanner: improve state trackingDieter Verfaillie2013-10-081-19/+12
|
* giscanner: better lineno handlingDieter Verfaillie2013-10-081-12/+13
| | | | | | No need to enumerate the comment lines list as we already receive the lineno of the very first line as a parameter. Simply increment that one when looping over the comment lines list.
View Lorry Controller Status