Return iOS version in Environment.OSVersion on Mac Catalyst

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!

[filipnavara]

Implement OperatingSystem.IsMacCatalyst and OperatingSystem.IsMacCatalystVersionAtLeast

Fixes#47768

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[akoeplinger]

why do we need an autoreleasepool here?

[filipnavara]

I am not necessarily sure whether it's needed or not but LLVM code has it there (https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm#L83-L90).

[akoeplinger]

yeah I saw that, I was mostly wondering because we have some custom code in pal_autoreleasepool.m that does thread initialization stuff used by ThreadPool code in managed and I don't know if we need that here too:

runtime/src/libraries/Native/Unix/System.Native/pal_autoreleasepool.m

Lines 18 to 35 in 5b683e2

	void* SystemNative_CreateAutoreleasePool(void)
	{
	if (![NSThreadisMultiThreaded])
	{
	// Start another no-op thread with the NSThread APIs to get NSThread into multithreaded mode.
	// The NSAutoReleasePool APIs can't be used on secondary threads until NSThread is in multithreaded mode.
	// See https://developer.apple.com/documentation/foundation/nsautoreleasepool for more information.
	PlaceholderObject* placeholderObject = [[PlaceholderObject alloc] init];
	// We need to use detachNewThreadSelector to put NSThread into multithreaded mode.
	// We can't use detachNewThreadWithBlock since it doesn't change NSThread into multithreaded mode for some reason.
	// See https://developer.apple.com/documentation/foundation/nswillbecomemultithreadednotification for more information.
	[NSThreaddetachNewThreadSelector:@selector(noop:) toTarget:placeholderObject withObject:nil];
	}
	assert([NSThreadisMultiThreaded]);
	return [[NSAutoreleasePoolalloc] init];
	}

@rolfbjarne do you know the implications?

[filipnavara]

Good point. I'm no expert on that but the documentation really suggests that it may be necessary... 🤷🏻‍♂️

[spouliot]

That's fine [1] if the new API are called from user+managed code.

If the dotnet runtime(s) calls (independently or before xamarin's runtime completed it's initialization) SystemNative_iOSSupportVersion then SystemNative_CreateAutoreleasePool should be called first (or to create the instance).

[1] if not it means we need to fix it

[filipnavara]

I'll modify it to call SystemNative_CreateAutoreleasePool instead of @autoreleasepool which should be safe. The code should not depend on Xamarin runtime being used/initialized (even if in most cases it will be).

[filipnavara]

The Apple documentation says that using NSAutoreleasePool manually would trip the ARC analyzer so I just extracted the code into helper method and kept using @autoreleasepool.

[akoeplinger]

Thank you!