Uncommented the sources and update some mistakes after following the
sample provided by Apple. Initially tests were going to be added but
they resulted to be to flacky and would make the CI red too often to be
adding value.
Porting the sample will ensure that it works are the bindings are not
broken.
* [Runtime] Enable the -Wshorten-64-to-32 flag and fix all warnings.
We want to enable the -Wconversion but that will raise too many warning
for a single commit. We are enabiling one by one the flags included in
-Wconversion so that we have smaller diffs.
-Wshorten-64-to-32 adds warnings when there is a implicit conversion that
loses integer precision. We are moving all the 32 to 64 conversions to
use 64. Expecially since most of the code changed is related with sizes,
legths and params counts that are never going to be negative.
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
This is already done by the generated code, as seen below.
```csharp
selWindowWithWindowNumber_Handle = Selector.GetHandle ("windowWithWindowNumber:");
selWindowsHandle = Selector.GetHandle ("windows");
selWindowsMenuHandle = Selector.GetHandle ("windowsMenu");
class_ptr = Class.GetHandle ("NSApplication");
class_ptr = Class.GetHandle ("NSApplication");
}
```
With this change, we've also removed the static constructor, therefore all the fields are going to be initialized when they are used, as opposed to being forcefully loaded on the first access. This may improve startup times
`get_mono_env_options` allocate memory so it must [1] be freed.
[1] to be polite since it will be freed when the app exit, which
will free everything anyway
Enable the -Wsign-compare which will raise issues when a comparison
between signed and unsigned values could produce an incorrect result
and fix all the raised warnings.
state.
Some of the tests were creating connections when not needed, this
'apparetly' was leaving the internal state of the Networking API in a
bad state in which it would throw a SIGSEGV and will make the connection
of other tests fail. In this case, the Tls tests that use the Network
API.
Cleaning the tests and removing those badly managed connections ensured
that the SIGSEGV would not be thrown and got all the other tests to
work.
This is a blackbox, test now passes without problems.
Fixes: https://github.com/xamarin/maccore/issues/2048
The DSymUtil tool not only generates the debug symbol files but also modifies the executable file. Marking that property as Output (and changing it to ITaskItem type) makes Visual Studio on Windows aware of that change. Under certain scenarios this was making the build on VS produce an app bundle that was not fully signed on incremental builds. For instance, the DSymUtil task was run for a framework on an incremental build, but as the executable file of that framework was not modified on Windows the inputs/outputs check for CodesignFrameworks did not fail so that target was skipped. This led to a failure on the CodesignVerify target.
Partial fix for https://developercommunity.visualstudio.com/content/problem/729766/codedesign-exited-with-code-1.html
This is already compiled as ObjC++ but this gives an additional (and
required) hint to some tools that it is Objective C++ code.
This avoid a lot of build errors (under static analysis tools),
most of them not really helpful (a trait shared with many C++ compiler
warnings and errors) except for this one:
```
error: invalid argument ‘-std=c++14’ not allowed with ‘Objective-C’
```
* [Tests] Fix the Network tests.
The pattern used to Cancel then Dispose the connection is wrong and
ended up crashing the tests sometimes. It is a race condition and is
very rare, but makes the tests flaky. The changes ensures that we
Dispose the connection, which internally closes it.
Tests have been added for the NWConnection Close calls.
Also cleaned some on the CWL that were not needed.
* [runtime] Simplify Vision dlsym'ed functions
More code sharing - DRYer :)
It also remove complaints (from static analysis tools) that a `dlclose`
should be present. That's not really an issue here since it's reference
counted and won't be unloaded if you use the code (and such a call is
not added in the PR). It silence the warning since it's not a local
variable anymore.
We have only encountered a case in which we had to add a nested
class/enum as the return type of a property. This fix ensures that we
can work with 1 level nested classes. A more general situation with
nested/nested/nested/.. classes is not taken into account because:
1. Would complicate too much the code.
2. Is fixing problems we do not have AFAIK.
So I'm keeping the fix simple, as I said, we have never faced anything
deeper than one level.
and by friends I mean `mmp` and `btouch`
What does this do ?
1. Assume that output of `mtouch` (and other similar tools) is **always** of high importance. Why ?
- If not then it's not saved in the binary log (even if visible on the console/text logs).
- The logging of `mtouch` (and friends) is dynamic, based on a supplied verbosity level.
- If a verbosity level _anywhere_ then it's a clear sign that the developer wants that extra output (and that includes binary logs).
2. Assume the _global_ verbosity of `msbuild` from the console is just as valid/useful than the one from VSfM.
- CI/bots produce logs and they should be useful to diagnose build issues.
- Setting verbosity in several places is error-prone, which delay investigations and results.
- Running the same project, with the same `msbuild` verbosity, should be identical between IDE and console.
What does that mean ?
Using `msbuild /v:diag /bl:out.binlog` you get a small(er) binary log that has everything[1] you need to diagnose a Xamarin.iOS (or Mac) build. It's also identical to the output what VSfM produce (for the same `msbuild` verbosity level).
[1] we might need to review what we log if we're missing interesting stuff
References:
https://github.com/xamarin/xamarin-macios/issues/7035