1. 17 Sep, 2021 3 commits
  2. 24 Aug, 2021 3 commits
  3. 16 Aug, 2021 1 commit
    • Emmanuele Bassi's avatar
      scanner: Handle constructors with mismatched GTypes · 3b17bb37
      Emmanuele Bassi authored
      For historical reasons, we have boxed types that do not follow the
      typical conversion from CamelCase to snake_case when it comes to their
      get_type function.
      The introspection scanner will correctly detect that a type is matched
      to that get_type function, but then it will default to tokenize the
      get_type function to set the c_symbol_prefix of the given type.
      The method pairing code in the main transformation path takes that
      mismatch into consideration, but the constructor pairing code does not.
      This leads to interesting cases, like GString.
      GString is correctly detected as GLib.String, and correctly matched to
      its `g_gstring_get_type()` type function, but its c_symbol_prefix is set
      to `gstring` after the tokenization. While methods like
      `g_string_append()` are correctly paired to the `GLib.String` node,
      constructors like `g_string_new()` do not, and end up being turned into
      function nodes, like `GLib.string_new`, even if they are annotated as
      I'm not entirely confident that changing the c_symbol_prefix
      tokenization this late in the game is going to be free of regressions;
      instead, we provide a way for pairing constructors if they are annotated
      as such.
      In other words: non-annotated constructors of types that have a
      different symbol prefix than the one of the get_type function will stay
      as they are today鈥攁 global function. To enforce the matching, we rely on
      an explicit `(constructor)` annotation; at least, this should ensure
      that we have explicit buy in from the maintainers of the API.
      Fixes: #399
  4. 05 Aug, 2021 24 commits
    • Emmanuele Bassi's avatar
      docs: Fix the "final" attribute in the GIR schema · 64ae0bfd
      Emmanuele Bassi authored
      The "final" attribute is not namespaced. Like "abstract", the "final"
      flag is shared across type systems, it's not strongly related to GObject
    • Emmanuele Bassi's avatar
      Ignore accessor annotations for non-introspectable properties · e79ea48a
      Emmanuele Bassi authored
      If a property is not introspectable we need to decouple it from its
      accessors; the property data will not be compiled into the typelib,
      and when the compiler will try to resolve the offsets into the binary
      blob we'll get a fatal exception.
    • Emmanuele Bassi's avatar
      Improve readability of error message · 8d007420
      Emmanuele Bassi authored
      Use the parent type and the function symbol when erroring out if we
      can't find a property accessor.
    • Emmanuele Bassi's avatar
      Improve getter function matching heuristic · dfb5ce07
      Emmanuele Bassi authored
      Some readonly boolean properties in the form of 'has-foo' or 'is-bar'
      expose a getter function in the form of `get_has_foo()` or
      `get_is_bar()`, according to extant coding practices. We should ensure
      we still check for those.
    • Emmanuele Bassi's avatar
      scanner: Warn if property annotations are mismatched · 2b6c06da
      Emmanuele Bassi authored
      If the (set-property) and (get-property) annotations on methods do not
      round trip with the (setter) and (getter) annotations on the
      corresponding property, we want to emit a warning.
    • Emmanuele Bassi's avatar
      docs: Clarify scope of property-related annotations · d324947d
      Emmanuele Bassi authored
      The `set-property` and `get-property` identifier annotations only apply
      to methods.
      The `setter` and `getter` identifier annotations only apply to
    • Emmanuele Bassi's avatar
      Use a macro for the missing accessor sentinel value · 4bcb26d6
      Emmanuele Bassi authored
      Easier to read than `0x3ff`.
    • Emmanuele Bassi's avatar
      scanner: Add an heuristic for property getters · 194088c2
      Emmanuele Bassi authored
      If a property is boolean and read-only, the getter method can be the
      same as the property name, for instance:
        - gtk_widget_has_focus()
        - gtk_media_stream_has_audio()
    • Emmanuele Bassi's avatar
      scanner: Try to pair properties with accessor methods · 9b5eae64
      Emmanuele Bassi authored
      The heuristic is pretty trivial: for any given non-construct-only,
      writable property, we check if there's a `set_<property>` method; for
      any given readable property, we check if there's a `get_<property>`
    • Emmanuele Bassi's avatar
      docs: Clarify the meaning of accessor functions · de2f64c4
      Emmanuele Bassi authored
      Public accessor functions are the functions typically called through
      g_object_set_property() and g_object_get_property().
    • Emmanuele Bassi's avatar
    • Emmanuele Bassi's avatar
    • Emmanuele Bassi's avatar
      Add annotations for property setters and getters · f83e75dd
      Emmanuele Bassi authored
      We need new annotations to allow library developers to associate a
      setter and a getter functions to a property definition.
    • Emmanuele Bassi's avatar
      Add introspection data for property accessors · b058ccae
      Emmanuele Bassi authored
      A GObject property can be accessed generically through the GObject API,
      e.g. g_object_set_property() and g_object_get_property(). Properties
      typically also have public accessor functions, which are (according to
      our own best practices) called through the generic API.
      The introspection data is currently missing the relation between a
      property and its public accessor functions. With this information, a
      language binding could, for instance, avoid exposing the C API entirely,
      thus minimizing the chances of collisions between property names and
      accessor functions; alternatively, a binding could call the C API
      directly instead of going through the generic GObject API, thus avoiding
      the boxing and unboxing from a native type to a GIArgument and finally
      into a GValue, and vice versa.
      In the GIR, we add two new attributes to the `property` element:
        - setter="SYMBOL"
        - getter="SYMBOL"
      where "symbol" is the C function identifier of the setter and getter
      functions, respectively. The `setter` attribute is only applied to
      writable, non-construct-only properties; the `getter` attribute is only
      applied to readable properties.
      We maintain the ABI compatibility of the typelib data by using 20 bits
      of the 25 reserved bits inside the PropertyBlob structure. The data is
      exposed through two new GIPropertyInfo methods:
        - g_property_info_get_setter()
        - g_property_info_get_getter()
      which return the GIFunctionInfo for the setter and getter functions,
    • Emmanuele Bassi's avatar
      docs: Add the new accessors annotations · 63eeaf11
      Emmanuele Bassi authored
      Mention them in the annotations list, and add the new attributes to the
      GIR schema.
    • Emmanuele Bassi's avatar
      tests: Check new property accessors annotations · e39804f3
      Emmanuele Bassi authored
      Add an accessors pair to Regress.TestObj and annotate them.
    • Emmanuele Bassi's avatar
      Add new annotations for property accessors · 3ec400b0
      Emmanuele Bassi authored
      We introduce two new annotations:
        - (set-property PROPERTY_NAME)
        - (get-property PROPERTY_NAME)
      These annotations are valid inside function blocks for methods on
      objects and interfaces, and define whether a function is a property
      accessor, e.g.:
           * gtk_widget_set_name: (set-property name)
           * @self: ...
           * @name: ...
           * ...
           * gtk_widget_get_name: (get-property name)
           * @self: ...
           * ...
           * Returns: ...
      The annotations are transformed into the GIR data as attributes:
       - glib:set-property="PROPERTY_NAME"
       - glib:get-property="PROPERTY_NAME"
      The underlying typelib data has had flags for setter and getter
      functions for a while, but they have never been plugged into the GIR
      data or the introspection scanner. Now they are; you can retrieve the
      GIPropertyInfo from a GIFunctionInfo that has the GI_FUNCTION_IS_SETTER
      or GI_FUNCTION_IS_GETTER flags set.
      Fixes: #13
    • Emmanuele Bassi's avatar
      Property accessors work for interfaces and objects · 700e8776
      Emmanuele Bassi authored
      We need to check the container type before trying to obtain a
      GIPropertyInfo for GIFunctionInfos that have a SETTER or a GETTER flag
    • Emmanuele Bassi's avatar
    • Emmanuele Bassi's avatar
      Add "final" class attribute · 661ca094
      Emmanuele Bassi authored
      A "final" class is a leaf node in a derivable type hierarchy, and cannot
      be derived any further.
      This matches the changes in libgobject that introduced G_TYPE_FLAG_FINAL
      to the type flags.
    • Emmanuele Bassi's avatar
      Add version macros for 1.70 · ffb165a5
      Emmanuele Bassi authored
      We are going to introduce new API.
    • Emmanuele Bassi's avatar
      Update the GLib documentation · 937c37ba
      Emmanuele Bassi authored
      Up to the 2.69.1 tag.
    • Philip Chimento's avatar
      build: Export warnlib sources as variables · 4926312b
      Philip Chimento authored
      This is so that GJS can use these variables in its own build files when
      including gobject-introspection as a Meson subproject. Previously we
      took the approach of using the files in their installed locations, but
      that doesn't work as a subproject.
    • Emmanuele Bassi's avatar
      Update the developer.gnome.org URLs · 7719bab8
      Emmanuele Bassi authored
      The GNOME developers documentation website has been updated, and we're
      in the process of moving API references elsewhere. The old documentation
      is still available under developer-old.gnome.org, so let's update the
      URLs we have in our documentation.
  5. 29 Jul, 2021 1 commit
  6. 28 Jul, 2021 1 commit
  7. 09 Jul, 2021 1 commit
  8. 24 Jun, 2021 6 commits