Skip to content
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

Looking at match01 --- flakey test #6673

Merged
merged 4 commits into from
May 13, 2019
Merged

Conversation

KevinRansom
Copy link
Member

@KevinRansom KevinRansom commented May 2, 2019

Okay … what was happening is … the StableNameGenerator is global. The fsharpqa tests use a compiler server to reduce build time. Since the fsharpqa test framework parallelizes the tests and they can run in different orders, causing the stablenamegenerator to create different names, the

This change attaches the stablenamegenerator to TcGlobals and plumb in tcGlobals, to a number of low level ast generation apis.

Because tcGlobals is recreated for every compilation, the Match01 optimization test case uses a bsl file, and so we noticed the name change.

I made a new type CompilerGlobalState to hang this type of state, because tcGlobals needs to appear after tast.fs.

Fixes #6657

@KevinRansom KevinRansom closed this May 3, 2019
@KevinRansom KevinRansom reopened this May 3, 2019
@KevinRansom KevinRansom closed this May 7, 2019
@KevinRansom KevinRansom reopened this May 7, 2019
@KevinRansom KevinRansom force-pushed the opttest branch 4 times, most recently from b2fb111 to f3eb3ac Compare May 8, 2019 05:30
@KevinRansom KevinRansom closed this May 8, 2019
@KevinRansom KevinRansom reopened this May 8, 2019
@KevinRansom KevinRansom closed this May 8, 2019
@KevinRansom KevinRansom reopened this May 8, 2019
@KevinRansom KevinRansom closed this May 8, 2019
@KevinRansom KevinRansom reopened this May 8, 2019
@KevinRansom KevinRansom closed this May 8, 2019
@KevinRansom KevinRansom reopened this May 8, 2019
Copy link
Contributor

@dsyme dsyme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR basically looks good apart from the addition of the val_global_state field - we must be able to avoid that. And if we're going to add a field we would add TcGlobals to all the primary objects

@@ -109,7 +109,7 @@
</trans-unit>
<trans-unit id="followingPatternMatchClauseHasWrongType">
<source>All branches of a pattern match expression must return values of the same type as the first branch, which here is '{0}'. This branch returns a value of type '{1}'.</source>
<target state="translated">Todas las ramas de una expresión de coincidencia de patrón deben devolver valores del mismo tipo. La primera rama devolvió un valor de tipo "{0}", pero esta rama devolvió un valor de tipo "\{1 \}".</target>
<target state="new">All branches of a pattern match expression must return values of the same type as the first branch, which here is '{0}'. This branch returns a value of type '{1}'.</target>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

odd change here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@@ -2543,7 +2535,9 @@ and
and ValData = Val
and [<NoEquality; NoComparison; StructuredFormatDisplay("{DebugText}")>]
Val =
{
{ /// Mutable for global state
mutable val_global_state: CompilerGlobalState option
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a problem - it is adding a word to the critical Val data structure, which we have worked very hard to remove every word from.

I will search around for what makes this neccessary

globalStableNameGenerator.GetUniqueCompilerGeneratedName(givenName, x.Range, x.Stamp)
else
givenName
match x.val_global_state with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should just pass g into CompiledName

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love to have passed around TcGlobals, however, it uses types from tast.fs, and so I can't pass tcGlobals that far back

@dsyme
Copy link
Contributor

dsyme commented May 8, 2019

val_global_state only gets consumed here: https://github.com/microsoft/visualfsharp/pull/6673/files#diff-5a2b2c121409423e80d58b7ffaccd472R2904. So I think just try passing g to CompiledName - it's probably always available as per the rest of the PR

@KevinRansom
Copy link
Member Author

@dsyme, I will give that a look.

@@ -4561,7 +4552,7 @@ and
[<DebuggerBrowsable(DebuggerBrowsableState.Never)>]
member x.DebugText = x.ToString()

override x.ToString() = sprintf "TBind(%s, ...)" x.Var.CompiledName
override x.ToString() = sprintf "TBind(%s, ...)" (x.Var.CompiledName None)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ dsyme … This is why CompilerGlobalSources is an option.
There is no way to get tcglobals to here,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: whitespace before sprintf.

@KevinRansom
Copy link
Member Author

@dsyme redone without the extra field. I think there may be even more plumbing in this one, sigh !!!! but it doesn't bloat the val record.

Let me know what you think

@KevinRansom
Copy link
Member Author

passed

@KevinRansom KevinRansom closed this May 9, 2019
@KevinRansom KevinRansom reopened this May 9, 2019
@KevinRansom KevinRansom requested a review from dsyme May 9, 2019 21:36
@KevinRansom
Copy link
Member Author

passed

@KevinRansom KevinRansom closed this May 9, 2019
@KevinRansom KevinRansom reopened this May 9, 2019
@KevinRansom
Copy link
Member Author

passed

@KevinRansom KevinRansom reopened this May 10, 2019
@KevinRansom
Copy link
Member Author

passed

@KevinRansom KevinRansom reopened this May 10, 2019
@KevinRansom
Copy link
Member Author

passed

@KevinRansom KevinRansom reopened this May 10, 2019
@cartermp
Copy link
Contributor

@KevinRansom It's passed for quite some time now...

@KevinRansom
Copy link
Member Author

@cartermp, I know, but it was intermittent failing, I wanted to be sure … the fix really fixed it.

@KevinRansom KevinRansom merged commit daa76ff into dotnet:master May 13, 2019
@KevinRansom KevinRansom deleted the opttest branch August 3, 2019 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Optimizations\Inlining (Match01.fs) test case has suddenly become flakey
4 participants