Real accessibility #15484
Real accessibility #15484
Conversation
KevinRansom
force-pushed
the
accessibility
branch
4 times, most recently
from
7b951fc to
dd8cd2d
Compare
KevinRansom
force-pushed
the
accessibility
branch
3 times, most recently
from
cf916e1 to
8b27fdb
Compare
KevinRansom
force-pushed
the
accessibility
branch
2 times, most recently
from
1c07e1e to
a5d2be2
Compare
KevinRansom
force-pushed
the
accessibility
branch
5 times, most recently
from
22a4bd2 to
e9ed9b9
Compare
KevinRansom
force-pushed
the
accessibility
branch
6 times, most recently
from
23de074 to
f714203
Compare
KevinRansom
force-pushed
the
accessibility
branch
5 times, most recently
from
2af1d80 to
bbbbd7e
Compare
KevinRansom
force-pushed
the
accessibility
branch
3 times, most recently
from
f9076e2 to
1b4d64e
Compare
| @@ -14,47 +14,104 @@ module SeqExpressionStepping = | |||
| |> withNoOptimize | |||
| |> withEmbeddedPdb | |||
| |> withEmbedAllSource | |||
| |> withRealInternalSignatureOn | |||
There was a problem hiding this comment.
Some tests in this file have withRealInternalSignatureOff, but they still then call verifyCompilation, which will add --realsig+ back, no? Did you mean to remove this from here? @KevinRansom
There was a problem hiding this comment.
...And wouldn't the alternating tests overwrite each other's baseline files anyway, since there are no separate baseline suffixes specified?
There was a problem hiding this comment.
...And wouldn't the alternating tests overwrite each other's baseline files anyway, since there are no separate baseline suffixes specified?
@brianrourkeboll
Let me take a look. TBH --- I am now hating all of the IL baseline tests. Just on a general, "I hate them" basis.
There was a problem hiding this comment.
@brianrourkeboll
You are correct I will fix the tests,
thanks
Kevin
There was a problem hiding this comment.
@KevinRansom Or I could in my PR (#16650), if that would be easier? Otherwise I'll just have more merge conflicts to resolve lol
There was a problem hiding this comment.
I got it, here she blows matey: #16795
There was a problem hiding this comment.
@brianrourkeboll , please look it over and I will get it merged.
|
The change sounds great!
Is this going to be a new default one day? |
Maybe one day, if stars align. |
With so much work done here, it would be sad to have it hidden under a feature flag 🙂 |
Sure, as it is with all opt-in features and warnings. It's a huge change in codegen and takes time. |
* The test sources and baselines for these were duplicated in dotnet#15484 to test the realsig feature, but that meant that the test _sources_ needed to be kept in sync by hand. This change uses the approach used in dotnet#16795 instead: it reuses the same test _source_ files and just adds duplicate _tests_ to check the emitted IL with realsig+.
* Consolidate emitted IL `for`-loop tests * The test sources and baselines for these were duplicated in #15484 to test the realsig feature, but that meant that the test _sources_ needed to be kept in sync by hand. This change uses the approach used in #16795 instead: it reuses the same test _source_ files and just adds duplicate _tests_ to check the emitted IL with realsig+. * Update netfx baselines * Fix find/replace bug * Unify netstandard assembly version in IL * Re-update baselines --------- Co-authored-by: Kevin Ransom (msft) <codecutter@hotmail.com>
8 participants
When the F# compile writes out an assembly, it writes all members with internal and private scopes in the source code as internal. All members of types which are internal are written to the assembly with the IL internal scope. This PR introduces a new compiler switch that preserves the source code annotated scope in the IL.
For example the source code:
Module example:
Class type example:
This change of IL scope impacts the initalization code. Originally intialization required the generation of a type per source file with a .cctor containing all of the initialization code. With real IL signatures this initialization has had to move to a classInitialization method on each class that requires initialization. That is because internal values can be accessed from anywhere inside of the assembly, whereas a private type that is initialized can only happen from a location where that value can be accessed. Ie the class it is specified in and any nested class below it.
In C# the initialization method is the .cctor for that class, unfortunately F# initialization is more structured than C#, C# initialization happens when the type is first used, whereas in F# initialization happens in the order of definition of the values within the source file.
Consider this F# program:
It produces output in this order:
So the initializers need to be invoked with care.
It should also be noted that a type reference can activate any of these types first, and so doing the initialization solely in class constructors would cause the intiialization sequenced to be out of order.