guile: fix smob exports

Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added
the created class to the exports list of (oop goops); v2.1+ does not
implicitly create bindings in any modules. This means that the GDB
manual subsection documenting exported types is not quite right when GDB
is linked against Guile <v2.1 (types are exported from (oop goops))
instead of (gdb)) and incorrect when linked against Guile v2.1+ (types
are not bound to any variables at all!).

There is a range of cases in which it's necessary or convenient to be
able to refer to a GDB smob type, for instance:

 - Pattern matching based on the type of a value.
 - Defining GOOPS methods handling values from GDB (GOOPS methods
   typically use dynamic dispatch based on the types of the arguments).
 - Type-checking assertions when applying some defensive programming on
   an interface.
 - Generally any other situation one might encounter in a dynamically
   typed language that might need some introspection.

If you're more familiar with Python, it would be quite similar to being
unable to refer to the classes exported from the GDB module (which is to
say: not crippling for the most part, but makes certain tasks more
difficult than necessary).

This commit makes a small change to GDB's smob registration machinery
to make sure registered smobs get exported from the current
module. This will likely cause warnings to the user about conflicting
exports if they load both (gdb) and (oop goops) from a GDB linked
against Guile v2.0, but it shouldn't impact functionality (and seemed
preferable to trying to un-export bindings from (oop goops) if v2.0
was detected).

[1]: This changed with Guile commit
     28d0871b553a3959a6c59e2e4caec1c1509f8595

gdb/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

	* guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered
	smob type from the current module.

gdb/testsuite/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

	* gdb.guile/scm-gsmob.exp (test exports): Add tests to make
	sure the smob types currently listed in the GDB manual get
	exported from the (gdb) module.

Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7

1 files changed, 28 insertions, 1 deletions

diff --git a/gdb/guile/scm-gsmob.c b/gdb/guile/scm-gsmob.c
index c623b07..72a96a7 100644
--- a/gdb/guile/scm-gsmob.c
+++ b/gdb/guile/scm-gsmob.c
@@ -96,7 +96,8 @@ gdbscm_is_gsmob (SCM scm)
   return slot != NULL;
 }
 
-/* Call this to register a smob, instead of scm_make_smob_type.  */
+/* Call this to register a smob, instead of scm_make_smob_type.
+   Exports the created smob type from the current module.  */
 
 scm_t_bits
 gdbscm_make_smob_type (const char *name, size_t size)
@@ -104,6 +105,32 @@ gdbscm_make_smob_type (const char *name, size_t size)
   scm_t_bits result = scm_make_smob_type (name, size);
 
   register_gsmob (result);
+
+#if SCM_MAJOR_VERSION == 2 && SCM_MINOR_VERSION == 0
+  /* Prior to Guile 2.1.0, smob classes were only exposed via exports
+     from the (oop goops) module.  */
+  SCM bound_name = scm_string_append (scm_list_3 (scm_from_latin1_string ("<"),
+						  scm_from_latin1_string (name),
+						  scm_from_latin1_string (">")));
+  bound_name = scm_string_to_symbol (bound_name);
+  SCM smob_type = scm_public_ref (scm_list_2 (scm_from_latin1_symbol ("oop"),
+					      scm_from_latin1_symbol ("goops")),
+				  bound_name);
+#elif SCM_MAJOR_VERSION == 2 && SCM_MINOR_VERSION == 1 && SCM_MICRO_VERSION == 0
+  /* Guile 2.1.0 doesn't provide any API for looking up smob classes.
+     We could try allocating a fake instance and using scm_class_of,
+     but it's probably not worth the trouble for the sake of a single
+     development release.  */
+#  error "Unsupported Guile version"
+#else
+  /* Guile 2.1.1 and above provides scm_smob_type_class.  */
+  SCM smob_type = scm_smob_type_class (result);
+#endif
+
+  SCM smob_type_name = scm_class_name (smob_type);
+  scm_define (smob_type_name, smob_type);
+  scm_module_export (scm_current_module (), scm_list_1 (smob_type_name));
+
   return result;
 }