GNOME Bugzilla – Bug 756921
g-ir-scanner does not recognize _Thread_local
Last modified: 2018-01-20 12:04:06 UTC
I usually get this warning when running g-ir-scanner on FreeBSD: /usr/include/runetype.h:94: syntax error, unexpected '{', expecting ',' or ';' in '{' at '{' In /usr/include/runetype.h: 93 extern _Thread_local const _RuneLocale *_ThreadRuneLocale; 94 static __inline const _RuneLocale *__getCurrentRuneLocale(void) 95 { It seems that g-ir-scanner doesn't know _Thread_local, which is a C11 keyword.
I think g-ir-scanner should skip the whole extern variable declaration on line 93, as it's not going to be properly introspectable (the thread locality concept is different across different thread implementations).
Created attachment 326623 [details] [review] giscanner: Recognize _Thread_local as a storage class specifier _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.
(In reply to Emmanuele Bassi (:ebassi) from comment #1) > I think g-ir-scanner should skip the whole extern variable declaration on > line 93, as it's not going to be properly introspectable (the thread > locality concept is different across different thread implementations). Do you think we can skip all global variable declarations (not just thread-local) because they cannot be introspectable?
(In reply to Ting-Wei Lan from comment #3) > (In reply to Emmanuele Bassi (:ebassi) from comment #1) > > I think g-ir-scanner should skip the whole extern variable declaration on > > line 93, as it's not going to be properly introspectable (the thread > > locality concept is different across different thread implementations). > > Do you think we can skip all global variable declarations (not just > thread-local) because they cannot be introspectable? Global variables are introspectable; thread locality at the C level may very well not be, when combined with multiple thread implementations, without an actual language-level wrapper.
(In reply to Emmanuele Bassi (:ebassi) from comment #4) > (In reply to Ting-Wei Lan from comment #3) > > (In reply to Emmanuele Bassi (:ebassi) from comment #1) > > > I think g-ir-scanner should skip the whole extern variable declaration on > > > line 93, as it's not going to be properly introspectable (the thread > > > locality concept is different across different thread implementations). > > > > Do you think we can skip all global variable declarations (not just > > thread-local) because they cannot be introspectable? > > Global variables are introspectable; thread locality at the C level may very > well not be, when combined with multiple thread implementations, without an > actual language-level wrapper. How can I make global variables appear in gir files? g-ir-scanner doesn't seems to have an option to enable this feature and this section of code in giscanner/transformer.py seems to suggest that all global variable declarations are ignored: def _traverse_one(self, symbol, stype=None, parent_symbol=None): ... elif stype == CSYMBOL_TYPE_CONST: return self._create_const(symbol) # Ignore variable declarations in the header elif stype == CSYMBOL_TYPE_OBJECT: pass
If global variables are completely ignored in gobject-introspection, can my patch (attachment 326623 [details] [review]) be reviewed now? Or it is still required to add an explicit (and unused) check for thread_local?
Ping ... Although not recognizing a valid keyword doesn't cause build failure, it can help reducing the number of warnings when running g-ir-scanner.
Review of attachment 326623 [details] [review]: Okay
Attachment 326623 [details] pushed as ab71b25 - giscanner: Recognize _Thread_local as a storage class specifier