If a wrapper type has a custom field (with a non-default value), we need to
mark the instance as dirty, to make it participate in the toggle-ref
machinery, and not get collected as long as the corresponding native instance
is around (otherwise the GC will collect the value in the field).
Fixes https://github.com/xamarin/xamarin-macios/issues/17635.
This is mostly converting 'bool' arguments to 'byte' arguments, and 'string'
arguments to 'IntPtr' with custom utf8->string conversions.
This is necessary in order to convert all block callbacks to use
UnmanagedCallersOnly function pointers (which can't have non-blittable types
in their signature).
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15783.
Includes latest fixes like support for retry and reconnect, new telemetry, bug fixing, etc.
Also added Merq.Core.dll to dotnet/Workloads/SignList.xml because now it comes as part of Xamarin.Messaging
This allows to add a prefix to the uploads/downloads of the CI to help
avoid collisions with other projects when the template is used in a diff
template.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We actually do need to keep this task inside our normal builds for the
Loc team to identify if there are new translations through the
localizationDrop artifact. The other pipeline that runs this task on the
cron job is used for a separate part of the localization process that
creates the PRs with the usable translations.
We re-add the job and provide a new parameter to ignore the translations (set to be true by default) that way other pipelines using the template can ignore the job.
https://github.com/xamarin/maccore/wiki/Localization#the-translation-process
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
These CGImageAnimation.AnimateImage functions are one-directional only, in
that they're only used to call into Objective-C from managed code, and not
into managed code from Objective-C. This means we can remove any block code
related to the latter scenario, since it's not needed.
This will be required when we make blocks use blittable callbacks, since we'll
have to use pointers in a few cases (because ref/out arguments aren't
blittable).
Removed a flavor of `class_addMethod` that is unused.
Ignored a few cases that are going to be in .NET and/or may break AOT
optimizations
Now all iOS pivots pass, 17 macOS remain.
We don't typically own input parameters, so make sure to pass 'false' for the
'owns' parameter to Runtime.GetNSObject.
This fixes a crash due to overreleasing these objects.
Also make the block creation code optimizable.
* Make BlockLiteral disposable.
This also means to modify the cleanup logic so that it's safe to call
Dispose more than once.
* Create a helper class to create a block for a simple Action delegate.
This allows us to simplify a good chunk of code.
* Update all block creation to use the new block API, where blocks are
disposable. This makes the code pattern a lot simpler.
I've changed all the P/Invokes to use an unsafe 'BlockLiteral*' pointer,
because 'using' variables can't be passed as ref arguments, so the choice
was either to make the parameter type 'IntPtr' and cast away the pointer:
using var block = new BlockLiteral ();
PInvoke ((IntPtr) &block);
or make the parameter an unsafe 'BlockLiteral*' pointer:
unsafe {
using var block = new BlockLiteral ();
PInvoke (&block);
}
The upcoming support for function pointers don't have this choice:
function pointers are always unsafe, so I chose to go the unsafe route
here as well, since it makes the code simpler once support for function
pointers has been implemented.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15783.
This PR might be easier to review commit-by-commit.
Applies the following changes from Xamarin.Messaging:
xamarin/Xamarin.Messaging#543xamarin/Xamarin.Messaging#541
It includes fixes for SSH keys handling, UX improvements when SSH is disabled on the Mac and also when the user is not logged in on the Mac
Naming could be problematic when generating code, move the logic out of
the generator class to a helper class whose only job is to name classes
and keep track of names.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This pull request updates the following dependencies
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230215.6
- **Date Produced**: February 16, 2023 6:00:46 AM UTC
- **Commit**: b68fd882623b528fd4ef78b122209710f17bacdb
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.4 to 7.0.4][1]
Code is complicated, lets remove as much noise as possible to focus on
the important parts.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Use a class that we can have to store the types and a single place to
locate the types to load.
Later we can use the class to write tests and move to a Dictionary
implementation that passes the tests and is more efficient.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Group all attr methods in the attr manager class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Several changes:
- Refactored AsyncMethodInfo and move the collection extensions out of
the Generator class.
- Added tests for the collection extension methods.
- Fix a mistake/bug in which Last was used instead of LastOrDefault
(funny comment was close to the right reason).
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Move all the string methods that can be an extension to a static class
(re-use the present one) and add tests.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 7.0.100-1.22579.2 to 7.0.100-1.23062.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 7.0.2 to 7.0.3 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 50c9492e-4671-4d1d-7920-08dabd1031a2
- **Build**: 20230214.27
- **Date Produced**: February 15, 2023 2:49:17 AM UTC
- **Commit**: 6d3cb5a4f9f758114727bce6a7fd965097a763fa
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.104-servicing.23109.16 to 7.0.104-servicing.23114.27][1]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22579.2 to 7.0.100-1.23062.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.2 to 7.0.3][3]
[1]: 0709aa6...6d3cb5a
[2]: 8db10f4...19fa656
[3]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GC7c81065&targetVersion=GCfebee99&_a=files
We need to use 'DOTNET_MANIFEST_VERSION_BAND' instead of
'DOTNET_VERSION_BAND', because the former always ends with '00' (which
manifest version bands are supposed), while the latter can have other numbers
(for instance 7.0.100 vs 7.0.101 - the former is a valid manifest version
band, the latter isn't).
Cleaned some code that could be simpler too.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>