forked from xamarin/xamarin-macios
-
Notifications
You must be signed in to change notification settings - Fork 0
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
github-actions
wants to merge
5,940
commits into
main
Choose a base branch
from
lego/TestTJ
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
…ate and PTChannelRestorationDelegate declarations. Fixes xamarin#16792. (xamarin#17273) Fixes xamarin#16792.
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.
* Use the right TFM. * Compute the right assembly name.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automated PR. Bring new translated changes in the lcl files for OneLocBuild to create translated resx files.