| Age | Commit message (Collapse) | Author |
|---|
|
using [System.Runtime]System.String the type was not understood as the primitive type string. (#15552)
Using ilasm from coreclr and running on mono it works, because of that I decided to fix on ilasm and not on runtime.
Fixes #13923
|
|
Use example.com and example.org instead.
Fixes https://github.com/mono/mono/issues/14585
Note that not all of the things I replaced make an actual network request but I thought it'd be nice to be consistent.
|
|
This test https://github.com/dotnet/coreclr/blob/1649da12db73c8c07513c9168cb30ec70c310063/tests/src/Regressions/coreclr/20452/twopassvariance.il
On mono we were ordering the list of implemented interfaces and shouldn't do this as it's described on ECMA-335 Section II.12.2.1 and II.12.2.2.
The ordering was removed on ilasm and some changes were needed on metadata either because it's not ordered anymore.
There were two bugs, one on ilasm and other on class initialization on mono.
### ILAsm ###
If we get the .exe generated by .net Framework it doesn't execute on mono without modifications because we ordered the implemented interfaces list by id. And doing that the order defined on source code is ignored.
If we get the .exe generated by Mono it doesn't execute on .net Framework because on IlAsm we order the list and loose the order defined on source code.
The interfaces on metadata before these changes on IlAsm were like this:
```
1: Fooer1 implements class IFoo<class Derived>
2: Fooer1 implements class IFoo<class Base>
3: Fooer2 implements class IFoo<class Base>
4: Fooer2 implements class IFoo<class Derived>
5: Fooer3 implements class IFoo<object>
6: Fooer3 implements class IBar<class Derived>
7: Fooer3 implements class IBaz<class Base>
8: IBar implements class IFoo<!0>
9: IBaz implements class IFoo<!0>
10: Fooer4 implements IQux
11: Fooer4 implements class IBar<class Derived>
12: IQux implements class IFoo<class Base>
13: IQux implements class IFoo<class Derived>
14: Fooer5 implements IQux
15: Fooer5 implements class IBar<class Derived>
16: Fooer6 implements class IBar<class Base>
17: Fooer6 implements class IFoo<class Base>
18: Fooer7 implements class IFoo<class Base>
19: Fooer7 implements class IBar<class Base>
```
And After the changes they follow the definition order which is the same order of IlAsm for .net framework and .net core.
```
1: IBar implements class IFoo<!0>
2: IBaz implements class IFoo<!0>
3: IQux implements class IFoo<class Base>
4: IQux implements class IFoo<class Derived>
5: Fooer1 implements class IFoo<class Base>
6: Fooer1 implements class IFoo<class Derived>
7: Fooer2 implements class IFoo<class Derived>
8: Fooer2 implements class IFoo<class Base>
9: Fooer3 implements class IBaz<class Base>
10: Fooer3 implements class IBar<class Derived>
11: Fooer3 implements class IFoo<object>
12: Fooer4 implements IQux
13: Fooer4 implements class IBar<class Derived>
14: Fooer5 implements class IBar<class Derived>
15: Fooer5 implements IQux
16: Fooer6 implements class IFoo<class Base>
17: Fooer6 implements class IBar<class Base>
18: Fooer7 implements class IBar<class Base>
19: Fooer7 implements class IFoo<class Base>
```
### Mono vtable layout ###
Internally when Mono computes the interface table for each class, it would previously sort the interfaces by `MonoClass:interface_id` which is a unique id assigned (roughly) in load order. This was incorrect because the order of the interfaces determines the final vtable for the class. This PR changes the interface table computation so that the interfaces of a single class are ordered in declaration order, following ECMA.
One consequence is that we can no longer use binary search with the interface id as the key to find out if a class implements an interface. We have to do a linear scan. On the other hand, we expect that the number of interfaces implemented by a single class is small in practice.
This is how the Vtable for Fooer1 and Fooer2 looks like after the changes:
```
*** Vtable for class 'Fooer1' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fd78681db20]
[O][001][INDEX 001] object:GetHashCode () [0x7fd78681daf8]
[O][002][INDEX 002] object:Finalize () [0x7fd78681dad0]
[O][003][INDEX 003] object:Equals (object) [0x7fd78681daa8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fd786503800]
[I][005][INDEX 000] IFoo:Gimme () [0x7fd7865038c0]
Packed interface table for class Fooer1 has size 2
[000][UUID 078][SLOT 004][SIZE 001] interface IFoo[Base]
[001][UUID 079][SLOT 005][SIZE 001] interface IFoo[Derived]
```
and
```
*** Vtable for class 'Fooer2' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fd78681db20]
[O][001][INDEX 001] object:GetHashCode () [0x7fd78681daf8]
[O][002][INDEX 002] object:Finalize () [0x7fd78681dad0]
[O][003][INDEX 003] object:Equals (object) [0x7fd78681daa8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fd7865038c0]
[I][005][INDEX 000] IFoo:Gimme () [0x7fd786503800]
Packed interface table for class Fooer2 has size 2
[000][UUID 079][SLOT 004][SIZE 001] interface IFoo[Derived]
[001][UUID 078][SLOT 005][SIZE 001] interface IFoo[Base]
```
This is how the VTable for Fooer1 and Fooer2 looks like before the changes, as you can see Packed interface table are the same in Fooer1 and Fooer2, so the behavior of both classes was the same:
```
Vtable for class 'Fooer1' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fcf3801d920]
[O][001][INDEX 001] object:GetHashCode () [0x7fcf3801d8f8]
[O][002][INDEX 002] object:Finalize () [0x7fcf3801d8d0]
[O][003][INDEX 003] object:Equals (object) [0x7fcf3801d8a8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fcf37c29880]
[I][005][INDEX 000] IFoo:Gimme () [0x7fcf37c29940]
Packed interface table for class Fooer1 has size 2
[000][UUID 076][SLOT 004][SIZE 001] interface IFoo[Base]
[001][UUID 077][SLOT 005][SIZE 001] interface IFoo[Derived]
```
```
Vtable for class 'Fooer2' at "FINALLY" (size 6)
[O][000][INDEX 000] object:ToString () [0x7fcf3801d920]
[O][001][INDEX 001] object:GetHashCode () [0x7fcf3801d8f8]
[O][002][INDEX 002] object:Finalize () [0x7fcf3801d8d0]
[O][003][INDEX 003] object:Equals (object) [0x7fcf3801d8a8]
[I][004][INDEX 000] IFoo:Gimme () [0x7fcf37c29940]
[I][005][INDEX 000] IFoo:Gimme () [0x7fcf37c29880]
Packed interface table for class Fooer2 has size 2
[000][UUID 076][SLOT 005][SIZE 001] interface IFoo[Base]
[001][UUID 077][SLOT 004][SIZE 001] interface IFoo[Derived]
```
|
|
shouldn't add virtual.
Fixes #13508
|
|
They can be used with native line endings.
We now have a shared folder with the dotnet repos and they have CRLF normalization enabled.
This difference leads to conflicts while applying changes from the dotnet repos to mono.
|
|
|
|
* [build] Unify bootstrap profiles
We can now rely on build only as we have reliable monolite and package
compilers
* Fixes genproj dependencies
* [csproj] Update project files
|
|
override it (#10429)
* Move the PreBuild dependency property later in the file so targets can't override it
* [csproj] Update project files
|
|
* Remove use of sln dependencies and use csproj project references instead
* Rewrite jay.vcxproj so it builds correctly even without help from the sln file
* Force pre-build event to run after references are resolved. Change how culevel.exe path is computed to be more resilient.
* [csproj] Update project files
|
|
for sources in projects so that we don't get erroneous duplicate files in cases where there are both profile and host platform criteria (#9952)
A recent commit revealed that in cases where we select based on a mix of host platform and profile, genproj csproj files can end up with duplicate sources because the existing <ItemGroup Condition= approach could make multiple groups match for a given compile when we really just want one.
This PR changes to generating a cascade of msbuild <Choose> elements, which give if-else selection to ensure that we only ever build a single set of files.
|
|
of solution dependencies (#9670)
Using solution dependencies in ```bcl.sln``` seems flaky and seems like it might not establish the full ordering we need to ensure that ```Consts.cs``` exists before we build things that require it. Let's try using project references (where ```corlib.dll``` 'depends' on ```genconsts.exe```) instead. This should also insert the dependency for any project that includes Consts.cs instead of just corlib.
This PR also makes update-solution-files actually fail if ```genconsts.exe``` fails to build because it was driving me mad.
Part of #6886
|
|
host platform (#8985)
* Update genproj makefile to include gensources
Update genproj argument parser to be more generous about displaying help
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Fix rebase issue
* Checkpoint
* Checkpoint
* Fix built sources only being added to one profile
* Fix typo
* Checkpoint
* Fix indentation
* Use csc instead of mcs
* Checkpoint
* Fix BUILT_SOURCES only being handled for the first profile processed
* Checkpoint
* Checkpoint
* Strip double slashes from paths to fix spurious csproj change
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint: Fix genproj compilation
* Checkpoint
* Checkpoint
* Checkpoint
* Fix crash when no targets were loaded (due to an error)
* Checkpoint
* Checkpoint
* Checkpoint
* Fix TryParseTargetInto bug
* Checkpoint
* Shuffle exclude logic around so that it works correctly during genproj diffing
* Remove gensources tracing
* Checkpoint
* Fix handling of oddball sources paths from executable.make
* Fix jay not being set to build
* Fix wrong slashes being used for embedded resource paths
* [csproj] Update project files
|
|
|
|
https://github.com/mono/mono/issues/8447 (#8467)
|
|
without setting a platform (#8223)
* Default platform to net_4_x if none is specified, to fix tools that build without setting a platform
* [csproj] Update project files
|
|
* [msvc] Update csproj files
* [msvc] Delete old net_4_x.csproj and xbuild_12.csproj files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The "cil" attribute seems to indicate that the data should be placed
in the .text section, along with the code.
Like the tls attribute, the cil attribute is only implemented insofar
as to recognize it as a valid keyword that can occur in a .data
declaration.
|
|
|
|
Note: DISABLE_CAS_USE was removed in ed989a8e9e5c170b6d19edc60bb80e8a4e6d5cc0
|
|
This changes the IL parser to have the same behavior as ilasm.exe from
MS
https://bugzilla.xamarin.com/show_bug.cgi?id=16628
|
|
|
|
value type.
The conflict happens when a type is declared like this:
.class value private auto ansi serializable sealed foo extends [mscorlib]System.Enum
The value keyword would make it a value type and ignore the parent declaration.
.net ilasm favors the later, which makes more sense.
|
|
|
|
* Add TODO list
* Use -useSourcePath when building resources, so we do not need to add the explicit extra path
* More updates, now battling resource generation across the board
* Use newlines in the Unix commands to avoid generating things like cs-parser.cs^M
|
|
|
|
to appease MS msbuild
|
|
|
|
contain the full call conv. Fixes b35784.
When generating varargs signatures for method defs, ilasm would discard the rest of the call conv. Things
like instance or explicit this would be discarded.
|
|
|
|
They weren't updated in the last 6 years and aren't helpful anymore (e.g. by causing unrelated matches during git grep searches).
|
|
Example IL: ".assembly extern mscorlib {auto}"
|
|
Example IL:
".assembly extern legacy library mscorlib {}"
".assembly legacy library test {}"
|
|
|
|
541a65ddd3f4b49c4d5bb6324bae63f0ed569115)
|
