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

[Localization] Pulling New Localization Translations $GITHUB_RUN_ID #4

Open
wants to merge 5,940 commits into
base: main
Choose a base branch
from

Conversation

github-actions[bot]
Copy link

Automated PR. Bring new translated changes in the lcl files for OneLocBuild to create translated resx files.

rolfbjarne and others added 30 commits January 18, 2023 18:54
…ocols. Fixes xamarin#17268. (xamarin#17269)

In the following scenario:

* Type T is not available on a platform (say tvOS).
* Protocol P is available on said platform.
* A member M of P has its own availability attribute for said platform (for
  instance if P is available on tvOS 11.0, and the member is available on tvOS
  12.0).
* The protocol P is inlined into the type T.

We'd include the SupportedOSPlatform attribute from the inlined member on
generated code on other platforms (so the iOS assembly would say that the
inlined member M in T is available on tvOS).

Fixes xamarin#17268.
)

Apple provides the headers to target PushToTalk (so using PushToTalk in code
builds just fine for the simulator in Xcode), but it doesn't work at runtime.

I believe it's better to allow the same thing in our bindings, for two reasons:

* Apple prints out a helpful error message at runtime, instead of our rather
  incomprehensible build error.
* Apple might implement simulator support in the future, in which case we
  won't need to do anything else.
This pull request updates the following dependencies

## From https://github.com/dotnet/installer
- **Subscription**: 50c9492e-4671-4d1d-7920-08dabd1031a2
- **Build**: 20230117.22
- **Date Produced**: January 18, 2023 2:09:01 AM UTC
- **Commit**: 33d44bcd2251c000f797df6cab241d0e8581e08d
- **Branch**: refs/heads/release/7.0.1xx

- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.103-servicing.23063.7 to
7.0.103-servicing.23067.22][1]

[1]: dotnet/installer@4a2d55e...33d44bc
This pull request updates the following dependencies

## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230117.6
- **Date Produced**: January 18, 2023 12:56:45 AM UTC
- **Commit**: 7db1c3333302d4d5ac97a5cfb28e88e5c2cde968
- **Branch**: refs/heads/release/7.0

- **Updates**:
  - **Microsoft.NETCore.App.Ref**: [from 7.0.3 to 7.0.3][1]

[1]: dotnet/runtime@c8a73af...7db1c33
The ifdefs here were confusing, so I cleaned them up a bit.

Note that No* attributes in enum members won't prevent the enum members from
being generated, they'll just get an unavailable attribute, so adding No*
attributes to an enum member is not a breaking change (which allows for some
of this cleanup).

Contributes towards xamarin#14802.
…a platform when the type itself isn't available on that platform. (xamarin#17293)
…amarin#17304)

Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.

Co-authored-by: CSIGS <[email protected]>
…alyst. (xamarin#17297)

Since it doesn't work anyway, there's no reason to show it.
…ompilation directives. (xamarin#17309)

According to the compilation compilation directives, these two APIs are only
available on macOS, so update the availability attributes accordingly.
…rin#17301)

So that all platforms know which other platforms the API is available on.
…S when the member has a NoMac attribute. (xamarin#17299)

This ensures that all platform assemblies know that the member doesn't exist
on macOS.
…l compilation directives. (xamarin#17311)

According to the compilation compilation directives, these APIs are not
available on tvOS nor macOS, so update the availability attributes
accordingly.
…ntity. (xamarin#17305)

The API for MPMediaItem/MPMediaEntity varies wildly between platforms (for
historical reasons), so move availability attributes around a bit so that they
match reality a bit better: MPMediaEntity is not available on macOS, only
MPMediaItem is.
…amarin#17300)

ARKit is in a weird spot on Mac Catalyst: it exists, but it doesn't do
anything. Since it doesn't actually work, we don't have bindings for ARKit.

This means that while the method '[NISession setARSession:]' technically
exists on Mac Catalyst, we can't bind it properly, since the type of the
parameter (ARSession) isn't available in our bindings for Mac Catalyst.

Due to how we hack around the lack of ARSession in our source code, we ended
up binding the method with an NSObject argument instead. This is still wrong,
so here I'm removing that method from the API.

But of course, removing that API is a breaking change, so until then the
method is obsoleted and hidden, and only removed in XAMCORE_5_0.

Also hide a few other obsoleted API in NISession, and remove those as well in
XAMCORE_5_0.
…() and FromUrl() throwing exceptions. (xamarin#17073)

Provided manual binding of AVAudioPlayer::initWithContentsOfURL:error: and AVAudioPlayer::initWithData:error: to prevent an issue where AVAudioPlayer::FromData() and FromUrl() do not throw exceptions when returning null.

Fixes xamarin#16229

Co-authored-by: GitHub Actions Autoformatter <[email protected]>
…older macOS bots. (xamarin#17317)

I've started seeing more random network delays on these tests recently - which
the tests themselves handle, but the test run ends up taking much longer, and
we need to give the test run more time to finish.
…arin#17302)

There's no trace of this in the headers, so I assume it's something that
happened in a beta and then got removed, and we didn't notice to update our
bindings.
…amarin#17342)

Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.

Co-authored-by: Alex Hsu <[email protected]>
Co-authored-by: CSIGS <[email protected]>
…TLRenderCommandEncoder API is available on the correct platforms. (xamarin#17307)
Co-authored-by: GitHub Actions Autoformatter <[email protected]>
Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
…stamp changes. (xamarin#17352)

Try to fix #xamarin/maccore@2637 by making sure a file's timestamp changes
after make runs the corresponding target.

Otherwise it seems make may run into some sort of infinite loop.

Fixes xamarin/maccore#2637.
. (xamarin#17345)

Also make CAEdrMetadata available on iOS and add a missing CAEdrMetadata
property.

Fixes xamarin#17340.
…amarin#17360)

The bug manifests like this:

> Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded.

which happens because the SBNotificationHub doesn't exist in the final
executable. We asked the linker to link with the static library containing
this type, but the linker didn't link with the library because it didn't need
any of the symbols in it.

We should have collected all the exported Objective-C types from this library
and asked the native linker to keep them, but that didn't happen because:

1. We collect bound Objective-C classes from binding libraries here (the
   ListExportedSymbolsStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs#L148-L157

2. That only happens for attributes with a LinkWith attribute.
	* We compute if an assembly has a LinkWith attribute here:
	  https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L266
	* Which is called from here:
	  https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L198
	* Which is called from here (the ExtractBindingLibrariesStep):
	  https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs#L18

Now, we must obviously compute if an assembly has a LinkWith attribute before
doing anything that depends on that value, but we weren't doing things in that
order.

Changing the custom linker steps to run the ListExportedSymbols step *after*
the ExtractBindingLibrariesStep fixes this logic problem.

Fixes xamarin#17347.
…availability is different than the property itself. (xamarin#17298)

This PR handles two scenarios (fixed in separate commits):

Scenario 1:

* The property has different availability attributes than the containing type.
* The property's accessor(s) do not have availability attributes.

We'd generate the wrong availability attributes for the property accessors,
because we'd take the type's availability attributes and add them to the
accessors.

As for the fix: I can't really explain it. This code is rather impenetrable,
and the parameter names don't make much sense, but whatever I did seems to
work?

And it turns out this fix shows up in an existing test as well (the
generator's Bug35176 test), which I had to modify to remove the expectation of
(now redundant) availability attributes that we no longer produce.

Scenario 2:

* Type is available on iOS, tvOS.
* Property in the type is available on iOS (and not tvOS).
* Property accessor has explicit availability attributes for iOS.

Then the property accessor would get the availability attribute for tvOS from
the type, and not the (un)availability attribute from the property.

The fix is to make sure the parent context is the property (and not the type)
when processing availability attributes for the accessor.
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.