summaryrefslogtreecommitdiff
path: root/giscanner/scannerparser.y
Commit message (Collapse)AuthorAgeFilesLines
* Revert "scanner: don't accept invalid symbols in binary expressions"Emmanuele Bassi2023-01-081-22/+36
| | | | This reverts commit b37f24b7e27a77c398f41cc331608aff806f0d42.
* scanner: don't accept invalid symbols in binary expressionsLubomir Rintel2023-01-081-36/+22
| | | | | | | | | | | | | | | | | | | | | The rules for binary expressions were entirely oblivious to the type of the operand symbols and assumed they're integer constants. This is very unfortunate, since it caused all sort of nonsense to end up getting accepted. One such example is the following define from NetworkManager's libnm: #define NM_SETTING_PARAM_SECRET (1 << (2 + G_PARAM_USER_SHIFT)) As G_PARAM_USER_SHIFT is unknown, it was parsed as an invalid symbol. The addition didn't care, treated it as: #define NM_SETTING_PARAM_SECRET (1 << (2 + 0)) Let's just ensure we get CSYMBOL_TYPE_CONST only when both operands actually have const_int_set. Otherwise just create CSYMBOL_TYPE_INVALID. That will cause the symbol to be dropped on the floor eventually, but that's probably much better than a having an invalid value.
* giscanner: Support C99 designated initializersJan Tojnar2022-08-171-2/+17
| | | | | | https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html Based on https://github.com/katef/kgt/blob/c9d8ad246855c6b65e42371be7898f4073c28d18/examples/c99-grammar.iso-ebnf#L247-L252
* giscanner: Support ISO varargs in function macrosPhilip Withnall2022-03-221-1/+22
| | | | | | This fixes support for macros like `g_message()` in GLib. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* giscanner: Support function macros with zero argumentsPhilip Withnall2022-03-221-0/+10
| | | | | | | This fixes support for macros like `G_BREAKPOINT()` or `G_DEBUG_HERE()` in GLib. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* scannerparser.y: Include io.h on WindowsChun-wei Fan2022-02-131-0/+4
| | | | | We need it for close(), especially when unistd.h is not available, such as in the case of Visual Studio-style builds.
* giscanner: Improve error handling while parsing macrosDavid King2021-06-181-3/+29
| | | | | | | | | Check for errors during g_file_open_tmp() and fdopen(). Make sure to free tmp_name and error as needed. Found with Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* Fix a bison deprecation warning for using %error-verboseChristoph Reiter2019-12-111-1/+1
| | | | warning: deprecated directive, use ‘%define parse.error verbose’
* Support array arguments with static keywordEmmanuele Bassi2019-09-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | C99 allows defining an array argument with a fixed size as: void foo (int arr[static 10]) Compilers conforming to the C99 specification will be able to warn if the function is called with NULL or with an array smaller than the specified length, something that does not happen when using pre-C99 declarations like: void foo (int arr[10]) As the declaration above is identical to: void foo (int arr[]) Which is, in turn, identical to: void foo (int *arr) Fixes: #309
* scanner: parse and expose function macrosMathieu Duponchelle2019-07-191-0/+9
| | | | | This is useful for documentation tools, and other utilities that rely on full introspection of the C API of a given library.
* scanner: Merge specifiers and qualifiers when merging basic types.Tomasz Miąsko2019-01-051-0/+5
|
* scanner: Merge basic types in `specifier_qualifier_list` production.Tomasz Miąsko2019-01-051-10/+11
| | | | | | | | | | | This is necessary to parse types like `unsigned char` or `long double`, and is already done when parsing `declarations_specifiers`. Examples that are fixed by this change include: * `GLib.TestLogMsg.nums` previously parsed as `long` but should be `long double`. * `GMime.Encoding.uubuf` previously parsed as `unsigned` but should be `unsigned char`.
* Merge branch 'sourcescanner-empty-delcs' into 'master'Christoph Reiter2018-12-091-0/+4
|\ | | | | | | | | | | | | sourcescanner: Allow empty declarations. Fixes #216 Closes #216 See merge request GNOME/gobject-introspection!89
| * sourcescanner: Allow empty declarations. Fixes #216Christoph Reiter2018-12-091-0/+4
| | | | | | | | | | As far as I see these are not valid C and only allowed in C++11. But they do occur in the wild (mingw headers) so let's try to handle them.
* | Replace linked lists with arrays in source scannerTomasz Miąsko2018-12-091-3/+3
|/ | | | Reduce total number of memory allocations and increase data locality.
* sourcescanner: collect error messages and expose themChristoph Reiter2018-12-081-4/+7
| | | | | | | | | | | 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.
* gi_source_scanner_parse_file: use a filename instead of a FILE structChristoph Reiter2018-12-061-9/+22
| | | | | | This allows us to get rid of the msvc hacks which are needed in case Python is built with a different msvc than g-i. By passing a filename the FILE struct never passes over library boundaries.
* Recognize additional basic types from ISO/IEC TS 18661-3:2015.Tomasz Miąsko2018-06-231-28/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Create a new symbol instead of changing its identifier in place.Tomasz Miąsko2018-02-131-2/+8
| | | | Also free memory associated with macro name when it is unused.
* Reuse const_table between calls to SourceScanner parse_files and parse_macros.Tomasz Miąsko2018-02-131-11/+3
| | | | | | | | Macro constants may now refer to constants defined in source files. Test case provided by Philip Chimento. Fixes issues #173 and #75.
* Fix parsing when type_specifier comes before type_qualifier.Tomasz Miąsko2018-02-091-2/+25
| | | | | | | | | | | | | | | | If type_specifier comes after type_qualifier, then GISourceType representing type_specifier will be merely updated with qualifier flags. On the other hand, when this order is reversed the type qualifier used to be attached as a separate node through base_type (with CTYPE_INVALID), and interpreted incorrectly in transformer code. This commit changes this behaviour so that information about type qualifiers is stored directly in GISourceType corresponding to type specifier. It also fixes analogous issue with storage_class_specifier and function_specifier. From higher level viewpoint, it for example represents `const char*` and `char const*` in equivalent manner after parsing, and addresses issue #79.
* giscanner: Recognize _Thread_local as a storage class specifierTing-Wei Lan2018-01-091-2/+6
| | | | | | | | | _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
* scannerparser.y: Really remove temp .h file on WindowsChun-wei Fan2017-05-011-1/+2
| | | | | | | | | | | | | In gi_source_scanner_parse_macros(), a temporary .h file is generated during the process of parsing the macros, and they aren't being deleted on Windows. In turns out that the g_unlink() call in that function failed because Windows does not allow one to unlink/delete files while they are open, and that the g_unlink() call is done way early (for some reason). Fix this by calling fclose() on the fmacros FILE* *after* we are done with fmacros, and then finally call g_unlink() on the temp .h file. https://bugzilla.gnome.org/show_bug.cgi?id=781525
* scanner: Support boolean constantsFlorian Müllner2013-11-291-2/+8
| | | | | | | | 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
* giscanner: Respect __GI_SCANNER__ when scanning for macrosStef Walter2013-10-211-2/+155
| | | | | | | | | 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: speed up SourceScanner().parse_files()Dieter Verfaillie2013-10-171-54/+54
| | | | | | | | | | | | | | | | | | | 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
* sourcescanner: Fix symbolic references in enum membersJasper St. Pierre2013-02-161-3/+3
| | | | | | | We need to copy the source symbols, otherwise we'll overwrite their values. This isn't good. https://bugzilla.gnome.org/show_bug.cgi?id=693939
* scanner: Emit correct type for unsigned integer constantsColin Walters2012-11-071-1/+1
| | | | | | Otherwise bindings will break. https://bugzilla.gnome.org/show_bug.cgi?id=685022
* scanner: Correctly handle large 64 bit integer constantsColin Walters2012-10-301-4/+8
| | | | | | | | | | | | | | | | 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
* giscanner/scannerparser.y: Avoid C99ismChun-wei Fan2012-10-271-2/+3
| | | | | | Move variable declarations to the start of block. https://bugzilla.gnome.org/show_bug.cgi?id=681820
* giscanner: special case G_GINT64_CONSTANT and G_GUINT64_CONSTANT + miscAlban Browaeys2012-08-031-2/+21
| | | | | | | | | 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
* giscanner: Fix pointer parsing.Krzesimir Nowak2012-07-061-3/+15
| | | | | | | | | | | | They were parsed in wrong order resulting in having wrong pointer being const. For example - g_settings_list_schemas return type is normally 'const gchar *const *', but parsing result was 'const gchar ** const'. This was unnoticed, because pointer constness information is rather not used by gobject-introspection now. https://bugzilla.gnome.org/show_bug.cgi?id=656445
* Fix symbols being reported in invalid filesStef Walter2011-08-101-53/+53
| | | | | | | | | | | * Due to the way that flex/bison works, the symbols were being added to the scanner after additional lines are parsed. * If these lines are #line directives, then scanner->current_filename can change between when the symbol is parsed and when it's added. * Change so that symbol gets filename when parsing rather than when being added to the scanner. https://bugzilla.gnome.org/show_bug.cgi?id=650200
* scanner: Parse GNUC expression statementsColin Walters2011-06-021-0/+4
| | | | | | This is needed so we don't fail to parse gatomic.h from GLib. https://bugzilla.gnome.org/show_bug.cgi?id=651548
* GScannerParser: recognize character constantsGiovanni Campagna2011-05-121-1/+3
| | | | | | | Some enumerations (like GVariantClass) use characters instead of plain integers, so we need to recognize them. https://bugzilla.gnome.org/show_bug.cgi?id=646635
* Support glib-mkenums comment /*< flags >*/Andreas Rottmann2010-12-071-14/+17
| | | | | | | | | | | | | | | - 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>.
* Support hexadecimal escapes in constantsColin Walters2010-12-021-2/+81
| | | | | | | g_strcompress() only does some of what we need; fork it and add support for \x escapes too. https://bugzilla.gnome.org/show_bug.cgi?id=595773
* Handle enumerations with the full range of signed and unsigned valuesOwen W. Taylor2010-11-011-3/+3
| | | | | | | | | | | | | The C compiler will pick an enumeration type that accomodates the specified values for the enumeration, so ignoring 64-bit enumerations, we can have enumeration values from MININT32 to MAXUINT32. To handle this properly: - Use gint64 for holding eumeration values when scanning - Add a 'unsigned_value' bit to ValueBlob so we can distinguish the int32 vs. uint32 cases in the typelib - Change the return value of g_value_info_get_value() to gint64. https://bugzilla.gnome.org/show_bug.cgi?id=629704
* [scanner] Make sure private enums are filteredJohan Dahlin2010-09-261-0/+2
| | | | This is a follow-up to 60a8c75 which wasn't properly fixed.
* Remove trailing whitespaceJohan Dahlin2010-09-261-7/+7
|
* [scanner] Mark enum members as private in transformerJohan Dahlin2010-09-261-8/+2
| | | | | | | Remove enum members which follows /* <private> */ comments inside the transformer instead of the sourcescanner itself. Fixes a crash when creating the gir for GstBase.
* [scanner] Support private/public directivesJohan Dahlin2010-09-201-3/+17
| | | | Fixes https://bugzilla.gnome.org/show_bug.cgi?id=594125
* [sourcescanner] Rewrite linemarks parserJohan Dahlin2010-09-191-0/+1
| | | | | Rewrite the pre-processor linemark parser so we end up with accurate filenames and linenumbers.
* [sourcescanner] Support for line numbers on SymbolAlan Knowles2010-05-251-52/+52
| | | | | Add line numbers to symbols, which can be useful in later stages of the scanner.
* __extension__ can be put in front of expressionsDamien Lespiau2009-12-311-0/+1
| | | | | | | | | | | | glib uses __extension__ in macros dealing with 64 bits integer such as GUINT64_SWAP_LE_BE(). To quote the GCC manual: `-pedantic' and other options cause warnings for many GNU C extensions. You can prevent such warnings within one expression by writing `__extension__' before the expression. https://bugzilla.gnome.org/show_bug.cgi?id=605779
* scanner: more verbose parser error messagesStefan Kost2009-12-051-2/+3
| | | | | Keep track of the current line (the first 2000 chars of it) and include that in syntax error messages. Also print that failed token in the error message.
* Bug 555964 - Parse floating-point #definesColin Walters2009-02-251-2/+5
| | | | | | Previously we just supported int and string, add double to this. Technically we should probably differentiate between float and double, but it's not likely to be very useful in practice to do so.
* Disable a UTF-8 warning per defaultJohan Dahlin2009-02-201-0/+2
|
* Misc warning fixesDan Winship2009-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | * giscanner/scannerparser.y: Fix the "Ignoring non-UTF-8 constant string" error to print the right value. * tests/scanner/annotation.c (backslash_parsing_tester) (backslash_parsing_tester_2): make these non-static to avoid a warning. (annotation_object_string_out) (annotation_string_zero_terminated): fix return values * tests/scanner/annotation.h (annotation_object_with_voidp): prototype this * tests/scanner/gtkfrob.c: * tests/scanner/gtkfrob.h (gtk_frob_language_manager_get_default): fix prototype. (s/()/(void)/). * tools/compiler.c (format_output): fix signed/unsigned warning. Output a prototype for register_typelib() to avoid warnings later. svn path=/trunk/; revision=1071
* Bug 563591 – Flags not recognized when there is no introspection dataJohan Dahlin2009-01-121-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 2009-01-12 Johan Dahlin <jdahlin@async.com.br> Bug 563591 – Flags not recognized when there is no introspection data * giscanner/ast.py: * giscanner/girwriter.py: * giscanner/giscannermodule.c (type_get_is_bitfield): * giscanner/glibast.py: * giscanner/glibtransformer.py: * giscanner/scannerparser.y: * giscanner/sourcescanner.c (gi_source_type_copy): * giscanner/sourcescanner.h: * giscanner/sourcescanner.py: * giscanner/transformer.py: * tests/scanner/foo-1.0-expected.gir: * tests/scanner/foo-1.0-expected.tgir: * tests/scanner/foo.h: Large parts of this patch was done by Jürg Billeter. svn path=/trunk/; revision=1025
View Lorry Controller Status