Added the "<custom-type>" tag, and better requirements for function signatures.sb-0.10.10

Trying to find a non-qualified (without scope information) class, found
in a function signature or return type, was a bad idea for it makes the
parsing awfully slow when dealing with huge libraries. If the user
writes a type in short form in a function signature (e.g. "SomeClass",
instead of "Namespace::SomeClass"), APIExtractor will exit with a
message indicating the error and the possible candidates for the type.

The "<custom-type>" tag is for types of the target language ("PyObject"
in Python, for instance) and will be handled by the generator.

Reviewed by Hugo Parente <hugo.lima@openbossa.org>
Reviewed by Paulo Alcantara <pcacjr@gmail.com>

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/typesystem_specifying_types.rst b/doc/typesystem_specifying_types.rst
index d5a4ef2d9..0d24a6d52 100644
--- a/doc/typesystem_specifying_types.rst
+++ b/doc/typesystem_specifying_types.rst
@@ -328,6 +328,26 @@ container-type
 
     The *optional*  **since** value is used to specify the API version of this container.
 
+
+.. _custom-type:
+
+custom-type
+^^^^^^^^^^^
+
+    The custom-type node simply makes the parser aware of the existence of a target
+    language type, thus avoiding errors when trying to find a type used in function
+    signatures and other places. The proper handling of the custom type is meant to
+    be done by a generator using the APIExractor.
+
+    .. code-block:: xml
+
+        <typesystem>
+            <custom-type name="..." />
+        </typesystem>
+
+    The **name** attribute is the name of the custom type, e.g., "PyObject".
+
+
 .. _function:
 
 function