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

Addressing blocking issues from test plan for inferred tuple names #19016

Merged
merged 10 commits into from
Apr 28, 2017

Conversation

jcouv
Copy link
Member

@jcouv jcouv commented Apr 26, 2017

This PR is not ready for review yet. I will add more tests as Neal goes through the test plan today and provides feedback.

Test plan #18606
FYI @gafter

@jcouv jcouv added Area-Compilers PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. labels Apr 26, 2017
@gafter
Copy link
Member

gafter commented Apr 26, 2017

I'm going through the test plan today, using the branch you prepared for this PR as a reference. #Resolved

@jcouv
Copy link
Member Author

jcouv commented Apr 26, 2017

@gafter
Known issues:

@jcouv jcouv force-pushed the tuple-names-complete branch 3 times, most recently from 5ad2722 to 62257a1 Compare April 27, 2017 07:36
@jcouv jcouv removed the PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. label Apr 27, 2017
@jcouv jcouv force-pushed the tuple-names-complete branch 2 times, most recently from 8b71d5e to dfa1b4b Compare April 27, 2017 19:07

var inferredPositions = inferNames ? tupleNames.SelectAsArray(n => n != null) : default(ImmutableArray<bool>);
return new BoundTupleLiteral(syntax, tupleNames, inferredPositions, arguments: valuesBuilder.ToImmutableAndFree(), type: type);
Copy link
Member

Choose a reason for hiding this comment

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

This should probably save the positions even if it isn't in the type, however, this is probably not observable until we permit tuple element names on the left of a deconstruction.

Compilation,
shouldCheckConstraints: false);
shouldCheckConstraints: false,
inferredPositions: inferredPositions);
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps should be language version dependence here.

Compilation,
shouldCheckConstraints: false);
shouldCheckConstraints: false,
inferredPositions: inferredPositions);
return new BoundTupleLiteral(syntax, default(ImmutableArray<string>), default(ImmutableArray<bool>), subExpressions, tupleType);
Copy link
Member

Choose a reason for hiding this comment

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

And needs to be passed here I think.

Copy link
Member

@gafter gafter left a comment

Choose a reason for hiding this comment

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

LGTM with a few noted suggestions.

@gafter
Copy link
Member

gafter commented Apr 27, 2017

Sorry, a number of my comments are in #19021

Copy link
Member

@VSadov VSadov left a comment

Choose a reason for hiding this comment

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

LGTM

@jcouv jcouv force-pushed the tuple-names-complete branch from 563e43f to 5176e5d Compare April 28, 2017 04:26
@jcouv
Copy link
Member Author

jcouv commented Apr 28, 2017

@dotnet-bot test windows_debug_vs-integration_prtest please

@jcouv
Copy link
Member Author

jcouv commented Apr 28, 2017

@dotnet-bot test windows_release_vs-integration_prtest please

@jcouv jcouv merged commit 5734799 into dotnet:features/tuple-names Apr 28, 2017
@jcouv
Copy link
Member Author

jcouv commented Apr 28, 2017

@dotnet/roslyn-compiler Sorry, I forgot to tag the team on this. Let me know.

}
var uniqueFieldNames = PooledHashSet<string>.GetInstance();
RemoveDuplicateInferredTupleNames(namesBuilder, uniqueFieldNames);
uniqueFieldNames.Free();
Copy link
Member

Choose a reason for hiding this comment

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

Can uniqueFieldNames be moved to RemoveDuplicateInferredTupleNames as an implementation detail?

Copy link
Member Author

Choose a reason for hiding this comment

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

Unfortunately, no. Two of the usages use a fresh hashset (because they can't have explicit names in those scenarios, for instance in deconstruction), but one needs a hashset that already has explicit names (that's in BindTupleExpression).

@@ -47,13 +54,15 @@ internal sealed class TupleTypeSymbol : WrappedNamedTypeSymbol
internal const string TupleTypeName = "ValueTuple";
internal const string RestFieldName = "Rest";

private TupleTypeSymbol(Location locationOpt, NamedTypeSymbol underlyingType, ImmutableArray<Location> elementLocations, ImmutableArray<string> elementNames, ImmutableArray<TypeSymbol> elementTypes)
private TupleTypeSymbol(Location locationOpt, NamedTypeSymbol underlyingType, ImmutableArray<Location> elementLocations,
ImmutableArray<string> elementNames, ImmutableArray<TypeSymbol> elementTypes, ImmutableArray<bool> inferredNamesPositions)
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason to call the parameter inferredNamesPositions here rather than errorPositions as elsewhere?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a lapse. I'll fix in next PR.

@@ -210,10 +210,12 @@ Namespace Microsoft.CodeAnalysis.VisualBasic.Symbols
Inherits TupleElementFieldSymbol

Private _name As String
Private _cannotUse As Boolean ' With LanguageVersion 15, we will produce named elements that should not be used
Copy link
Member

Choose a reason for hiding this comment

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

ReadOnly for both fields.

/// If none of the element names were inferred, or inferred names can be used (no tracking necessary), leave as default.
/// This information is ignored in type equality and comparison.
/// </summary>
private readonly ImmutableArray<bool> _errorPositions;
Copy link
Member

Choose a reason for hiding this comment

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

Since the _errorPositions field only applies to use of inferred names at those positions, would it make sense to call this array _cannotUseInferredNames?

@cston
Copy link
Member

cston commented Apr 28, 2017

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants