Improve conflict detection and renaming behavior

[sethrj]

• Top-level symbols, when multiply defined in the target languages, will raise an error like Java does.
• Enum values will be ignored (and generate a warning) when they conflict.
• Member functions whose names conflict with other class functions will be ignored.
• Member functions that hide (shadow) base class functions will be ignored.
• Member functions consistently make "generic" or "specific" interfaces depending on what the base class does for the function being overloaded.
• We attempt to make function/subroutine overloading more consistent too.

[aprokop]

Enum values will be ignored (and generate a warning) when they conflict.

Can you please elaborate?

Member functions whose names conflict with other class functions will be ignored.

I don't quite understand that. If they have the same name, isn't it an overload?

Member functions that hide (shadow) base class functions will be ignored.

Would not that make the Fortran behave very differently from a similar C++ code?

[sethrj]

@aprokop The key is that Fortran's namespace/scope is different from C++: it's all lowercase, and there's no namspace. Currently, in most SWIG languages, if you have

namespace a {
class Foo {};
}
namespace b {
class Foo {};
}

the other SWIG languages will error out, but Fortran arbitrarily renames the second one. With enums, we also arbitrarily rename conflicts:

enum Foo {
 FOO
};

generates symbols foo and foo1 because they're both foo in Fortran's lowercase namespace. The Go language sometimes changes the case of symbols and ignores if they're duplicates rather than erroring. So again we'll be replicating that behavior.

Finally, regarding overloading and hiding: Fortran and C++ behave very differently with regards to "overloading". With Fortran, as I understand it, the basic idea is to apply the same operation to different types: daughter classes can extend the interface if the base class declares it generic. The result is that there are a ton of restrictions on what can be overloaded:

• If the base class doesn't use a "generic" spec, the daughter class can't either.
• The parameter names have to match exactly when overriding a function.
• If the base class method is a subroutine, the daughter method has to be as well. Same thing if one's a function.
• The daughter class can't have an identical signature to the base class if it's "generic".

...and a thousand others. Right now we generate a lot of invalid Fortran code with overloaded and overridden functions; the proposed change will make these overloads ignored by default since the semantic meaning of C++ overloading and Fortran generics are almost completely at odds.

%module derp

%inline %{

class Base {
public:
 int func();
 int func(int a);
 virtual int func(int a, int b);
 // void func(int, int, int); // ERROR: can't overload subroutine with functions
 void another();
};

class Derived : public Base {
 public:
  // using Base::func; // ERROR: generates functions ambiguous with base class
  double func(double b); // ERROR unless we have another overloading function
                         // so that the daughter function is labeled generic
  double func(double, double);
  // virtual int func(int x, int y); // ERROR: different parameter names
  // virtual int func(int a, int b); // ERROR: ambiguous with base class
  void another();
  // int another(int);
  // double another(double); // ERROR: generic in daughter class but not in parent
};

%}

Anyway, the result of the change is a lot of warnings but users will have to %rename the overloads.

[aprokop]

Thank you for the thorough comment! I did not realize the existence of all those nuances.

[sethrj]

Yeah, Fortran is fun 🙄

[sethrj]

This merge ticks a few boxes in #59 , fixing the following tests:

• cpp11_template_explicit
• cpp11_li_std_array
• cpp11_strongly_typed_enumerations
• clientdata_prop
• abstract_signature
• director_classes
• director_default
• director_detect
• director_overload2
• extend_default
• fvirtual
• inherit_target_language
• kind
• li_std_map
• multiple_inheritance
• multiple_inheritance_abstract
• multiple_inheritance_interfaces
• multiple_inheritance_nspace
• multiple_inheritance_shared_ptr
• nested_workaround
• template_methods
• using_composition
• using_extend
• using_inherit
• variable_replacement
• virtual_poly

Some new tests fail:

• friends
• grouping
• member_funcptr_galore
• member_pointer
• member_pointer_const
• smart_pointer_member

Most failing tests are due to conflicting symbols in the target language module and should be trivial to fix.