Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge upstream master #186

Merged
merged 72 commits into from
Aug 18, 2023
Merged

Merge upstream master #186

merged 72 commits into from
Aug 18, 2023

Conversation

sethrj
Copy link
Member

@sethrj sethrj commented Aug 11, 2023

wsfulton and others added 30 commits July 4, 2023 12:07
Fixes for C++11 using declarations for inheriting constructors
when the constructors are overloaded.
The ocaml headers have a value typedef.

See swig#2649
old version removed
This is for consistency with other members.
Fixes csymbol table name for the constructor.

Notable side effects:

- When $name is replaced in a constructor it no longer includes any
  template parameters, so similar to member functions which also
  don't include template parameters (li_boost_shared_ptr testcase)
- Fixes mangled C constructor name when using nested templates
  (nested_in_template, template_nested testcases)
- Fixes some typedef look up when generating templates that have
  default template parameters, to improve generated code so that
  the default parameters are no longer explicitly generated when
  the template type is used (template_default_class_parms_typedef
  testcase)
- For Ruby, better error messages when calling constructors,
  old:
    runme.rb:5:in `initialize': Expected argument 0 of type int, but got String "hi" (TypeError)
	in SWIG method 'Temply<(int)>'
  new:
    runme.rb:5:in `initialize': Expected argument 0 of type int, but got String "hi" (TypeError)
	in SWIG method 'Temply'
- Feature matching of parameters that are template types is now
  consistent for parameters in constructors and methods
  (features testcase)
  Potential incompatibility though:
  old:
    %exception Template<int>::Template(const Template&) "..."
  new:
    %exception Template<int>::Template(const Template<int>&) "..."
This is for consistency with other members.

Notable side effects:
    - When $name is replaced in a constructor it no longer includes any
      template parameters, so similar to member functions which also
      don't include template parameters (li_boost_shared_ptr testcase)
…es with template base classes

Internal using name no longer contains template parameters.
Fixes symbol table lookup for non-instantiated template constructor.
Builds on previous few commits where the internal name no longer
contains the template parameters for constructors and destructors.
…ctors

Corner case problem fix for when the base template class was
instantiated with %template including the default arguments and
the base class had an explicitly declared constructor.

Swig_symbol_template_deftype() was sometimes incorrectly finding
a constructor instead of a template and thus failing to correctly
expand the template default args. Problem noticed since
9cf0491 where constructors are
stored simply by their name instead of name plus template args.

Probably fixes a few other subtle template problems when a template
class contains default args.
For use outside of the target languages for forthcoming commits
which move adding default constructors/destructors from Language
to Allocate.
…nguage to Allocate

This is one more step in the direction of supporting C++11 using
declarations for inheriting constructors that are implied/non-explicit
in a base class.

This step now adds the default constructor/destructors to the parse tree
in the earlier Allocate stage of processing the parse tree instead of
the language specific stage.

Doing this in the Allocate stage is much more sensible as this is the
stage that is primarily analysing the classes that require implied default
constructors and destructors.

Only minor complication is that the Language class controls most of the
director code generation and requires the previous commit to move director
enablement detection into Swig_directors_enabled() which is callable from
the Allocate class.
Adding using declarations to the parse tree is done in this later
TypePass stage of processing the parse tree as the implicitly defined
constructors in the base class have already been added. The implicitly
defined constructors are also added in TypePass and are added during
processing of a base class, which is always before a derived class.
These constructors are thus available for a derived class to use when
TypePass::usingDeclaration is looking for base class constructors to add
to the parse tree.

This is a another step towards supporting C++11 using declarations for
inheriting base class constructors that are implicitly defined, both
template and non-template classes.
Parser no longer checks for a declared constructor when handling a
using declaration in order to correct the name as it won't find
implicitly declared constructors. Now it checks that a using
declaration is for something that looks like a constructor instead
by checking the immediate base classes for allowed constructors.
Support extended to directors.

Go protected constructors fix required for new testcase:
- Emit wrappers if director class is abstract
- If called, errors out with: accessing abstract class or protected constructor
- Now consistent with other target languages
Recent commits for internal constructor and destructor names resulted
in destructors declared with template parameters being ignored
with warnings like:
  Illegal destructor name TemplPublicBase6< int >::~TemplPublicBase6(). Ignored.

Although declaring constructors and destructors with template parameters
are rejected by modern compilers and C++20, SWIG continues to support it.

Make sure the name stored in the parse tree is the C++20 compliant name
name, that is, without the template parameters.

Fixes using declarations for templated constructors declared with
template parameters, was warning with:
  Nothing known about 'TemplPublicBase6< int >::TemplPublicBase6'.
Don't generate a default constructor wrapper when a class has a
templated constructor, as there isn't actually an implied default
constructor. For example:

  struct TConstructor3 {
    template<typename T> TConstructor3(T val) {}
  };

Previously wrappers were generated for a non-existent default
constructor which failed to compile.
…ructors

Testcase - compiles given previous commit, but needs more work!
wsfulton and others added 28 commits July 29, 2023 08:16
Correct unintended commenting out of code.

Issue swig#2541
Previously SWIG always attempted to call a copy constructor
taking a const reference parameter instead of a non-const
reference parameter.
Implement overloading between different integer types and between double
and float.
Define a goto label in the typemap with a fixed name which will give a
multiple definition error if the typemap is substituted more than once
in a particular wrapper function.

This way we'll also catch this potential bug for target languages that
don't have a runme for the ignore_parameter testcase.
when a method is declared in the class along with a
using declaration and the using declaration is declared before
the method that implemented the pure virtual method, such as:

  struct ConcreteDerived : AbstractBase {
    ConcreteDerived() {} // was not wrapped
    using AbstractBase::f;
    virtual void f(int n) override {}
  };

SourceForge bug: https://sourceforge.net/p/swig/bugs/932/

check_implemented in allocate.cxx was correctly finding a
non-abstract method, however, Swig_symbol_clookup_local_check, was
using the using declaration node instead of using the node returned
by check_implemented. The checkfunc is now given more control by
returning the node to use rather than Swig_symbol_clookup_local_check
always using the head of the csym linked list.
Restoring the scope was missing when handling base classes - the scope
was not set correctly after visiting base classes.

This bug doesn't seem to manifest itself in any way as either the code
uses fully resolved types or specifically sets the scope when needed,
so I can't see anything that is fixed by this.
Fixes inheritance hierarchies more than two deep and the using
declarations are overloaded. Using declarations
from a base class' base were not available for use in the target
language. For example in the code below, Using1::usingmethod(int i)
was not wrapped for use in Using3:

  struct Using1 {
  protected:
    void usingmethod(int i) {}
  };
  struct Using2 : Using1 {
  protected:
    void usingmethod(int i, int j) {}
    using Using1::usingmethod;
  };
  struct Using3 : Using2 {
    void usingmethod(int i, int j, int k) {}
    using Using2::usingmethod;
  };

Similarly for C++11 using declarations for inheriting constructors.
Add support for using declarations to introduce templated member
methods and for inheriting templated constructors, such as:

  struct Base {
    // templated constructor
    template <typename T> Base(const T &t, const char *s) {}
    // templated member method
    template <typename T> void template_method(const T &t, const char *s) {}
  };

  %template(Base) Base::Base<int>;
  %template(template_method) Base::template_method<double>;

  struct Derived : Base {
    using Base::Base;
    using Base::template_method;
  };

Previously the templated methods and constructors were ignored and
not introduced into the Derived class.
Even if this can't really happen in practice
This has been deprecated since SWIG 1.3.32 in 2007.  Use -init_name
instead.
Support was removed in 736c052 but
I missed this code.
Suppresses -Wfinal-dtor-non-final-class and -Wnon-c-typedef-for-linkage
observed with clang 17.
This is due to a change in d387ea2 that processes `feature:nodefault` before the Language sees it.
A betetr solution is to override the behavior in the constructor and destructor handlers.
@sethrj sethrj merged commit 4b24b54 into master Aug 18, 2023
8 checks passed
@sethrj sethrj deleted the fix-master branch August 18, 2023 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants