Bug 41654 - registrar calls the incorrect base constructor for chained constructors
Summary: registrar calls the incorrect base constructor for chained constructors
Status: ASSIGNED
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools (show other bugs)
Version: master
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-06-09 12:39 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2017-08-07 15:37 UTC (History)
4 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Rolf Bjarne Kvinge [MSFT] 2016-06-09 12:39:47 UTC
Exhibit A:

	class Managed : Native
	{
		[Export ("init")] // calls [self initWithA:]
		public Managed () { }

		[Export ("initWithA:")]
		public Managed (int a) { }
	}

in this case, if the native class' init ctor chains to its own initWithA: selector, then this happens:

1a) new Managed ()
1b) managed default ctor is executed, which eventually calls NSObject's ctor which calls the native init method.
1c) native init method does: [self initWithA:]
1d) our initWithA trampoline is hit, we detect that we already have a managed object for this pointer, and do not invoke the initWithB managed ctor. Instead we call super's initWithA selector directly (since we have to call some init method - see bug #35458).

This is correct behavior.

Exhibit B:

	class Managed : Native
	{
		[Export ("init")] // we don't know what the native ctor does, we have to assume it can call [self initWithCoder:]
		public Managed () { }

		[Export ("initWithCoder:")] // there is no native initWithCoder: method
		public Managed (NSCoder a) { }
	}

now what should the trampoline (from 1d. above) do? Calling [super initWithCoder:] is not correct, because that method doesn't exist.

Ideas:

1) Somehow figure out which ctor the managed initWithCoder: implementation chains to, and mirror that in the trampoline. This is likely requires inspecting IL, which is not easy at runtime (i.e. in the dynamic registrar). It'll also only work if the parameters match
2) Do a respondsToSelector:@selector (initWithCoder:) first, and if false, throw an exception. The only real difference here is that we'll get a nice managed exception instead of an ObjC selector not found exception.
3) Actually call the managed ctor. The caveat here is that somehow the NSObject ctor needs to know if this is the first time it's been executed or not (to avoid calling init again).
Comment 5 Rolf Bjarne Kvinge [MSFT] 2016-10-31 15:14:48 UTC
Another solution:

4) Add another attribute to describe which native constructor to chain to:

	class Managed : Native
	{
		[Export ("init")] // we don't know what the native ctor does, we have to assume it can call [self initWithCoder:]
		public Managed () { }

		[Export ("initWithCoder:")] // there is no native initWithCoder: method
		[ChainToConstructor ("init")]
		public Managed (NSCoder a) { }
	}

Note You need to log in before you can comment on or make changes to this bug.