Jira (PUP-8212) The Variant type without any types matches in strange ways

2 views
Skip to first unread message

Henrik Lindberg (JIRA)

unread,
Nov 28, 2017, 10:24:04 AM11/28/17
to puppe...@googlegroups.com
Henrik Lindberg created an issue
 
Puppet / Bug PUP-8212
The Variant type without any types matches in strange ways
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2017/11/28 7:23 AM
Priority: Normal Normal
Reporter: Henrik Lindberg

The Variant type when used as just Variant (no list of types) has an implementation that uses all? to check if all types in a RHS variant can be assigned to the LHS type. This fails when the RHS Variant is empty.

An empty Variant should only be assignable from a Variant as the only meaningful interpretation of a Variant without any types to perform an OR matching operation on is that it means "all types that are actually Variant".

If an empty Variant was to be interpreted as Variant[Any}, then it is essentially the same as Any, and that is surprising.

If it was to be an error to use Variant as an expression, we need to change the entire implementation how parameterized types are formed using the AST. (It has one expression that evaluates to the base Variant type, followed by an "at" expression [T1, T2,...] that constrains/widens/defines the type instance that will be created.

When fixing this, there are numerous tests that include the Variant in the list of "all types", and this change will require a special section of tests for the Variant type.

As the result when using a "naked" Variant is both conceptually wrong and confusing, this is going to be fixed on our oldest supported version in 4.x.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Atlassian logo

Henrik Lindberg (JIRA)

unread,
Nov 28, 2017, 10:27:02 AM11/28/17
to puppe...@googlegroups.com
Henrik Lindberg commented on Bug PUP-8212
 
Re: The Variant type without any types matches in strange ways

This blocks PUP-8202 because it is searching for types that are assignable to the Task data type and it finds instances of the Variant data type in error.

Henrik Lindberg (JIRA)

unread,
Nov 28, 2017, 10:27:05 AM11/28/17
to puppe...@googlegroups.com

Thomas Hallgren (JIRA)

unread,
Nov 29, 2017, 5:00:05 AM11/29/17
to puppe...@googlegroups.com

Thomas Hallgren (JIRA)

unread,
Nov 29, 2017, 5:01:02 AM11/29/17
to puppe...@googlegroups.com
Thomas Hallgren assigned an issue to Unassigned
 
Change By: Thomas Hallgren
Assignee: Henrik Lindberg

Henrik Lindberg (JIRA)

unread,
Nov 29, 2017, 5:25:02 AM11/29/17
to puppe...@googlegroups.com

Henrik Lindberg (JIRA)

unread,
Nov 29, 2017, 5:25:03 AM11/29/17
to puppe...@googlegroups.com
Henrik Lindberg updated an issue
The {{Variant}} type when used as just {{Variant}} (no list of types) has an implementation that uses {{all?}} to check if all types in a RHS variant can be assigned to the LHS type. This fails when the RHS Variant is empty.

An empty {{Variant}} should only be assignable from a {{Variant}} as the only meaningful interpretation of a {{Variant}} without any types to perform an OR matching operation on is that it means "all types that are actually {{Variant}}".

If an empty {{Variant}} was to be interpreted as {{Variant\[Any}}}, then it is essentially the same as {{Any}}, and that is surprising.


If it was to be an error to use {{Variant}} as an expression, we need to change the entire implementation how parameterized types are formed using the AST. (It has one expression that evaluates to the base {{Variant}} type, followed by an "at" expression {{\[T1, T2,...]}} that constrains/widens/defines the type instance that will be created.

When fixing this, there are numerous tests that include the {{Variant}} in the list of "all types", and this change will require a special section of tests for the {{Variant}} type.

As the result when using a "naked" {{Variant}} is both conceptually wrong and confusing, this is going to be fixed on our oldest supported version in 4.x.

Henrik Lindberg (JIRA)

unread,
Nov 29, 2017, 5:28:02 AM11/29/17
to puppe...@googlegroups.com
Henrik Lindberg commented on Bug PUP-8212
 
Re: The Variant type without any types matches in strange ways

While this is a bug that it would be nice to have on 4.10.z it proved to be expensive to backport this fix due to refactored tests. Since the problem this ticket fixes is not what users normally see under normal use we decided to not backport this. (It is possible if later we find that it is required).

Henrik Lindberg (JIRA)

unread,
Nov 29, 2017, 5:42:03 AM11/29/17
to puppe...@googlegroups.com
Henrik Lindberg updated an issue
Change By: Henrik Lindberg
Release Notes Summary: A problem has been fixed regarding the use of an empty {{Variant}} data type (not containing any types) and using the type comparison operators (<, >, <=, >=, =~, and !~). The problem occurred when an empty {{Variant}} was on the RHS and it would erroneously be accepted as a match for almost all other data types. This problem will not occur under normal use (when a variant does list types). An empty {{Variant}} now correctly represents all variants, and it only matches itself, {{Any}}, and {{NotUndef\[Variant]}}.
Release Notes: Bug Fix

Geoff Nichols (JIRA)

unread,
Jan 3, 2018, 3:17:04 PM1/3/18
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Jan 9, 2018, 11:46:05 AM1/9/18
to puppe...@googlegroups.com

Michael Smith (JIRA)

unread,
Jan 9, 2018, 2:42:03 PM1/9/18
to puppe...@googlegroups.com
Michael Smith updated an issue
Change By: Michael Smith
Sprint: Platform Core KANBAN

John Duarte (JIRA)

unread,
Oct 21, 2019, 10:50:05 AM10/21/19
to puppe...@googlegroups.com
John Duarte updated an issue
Change By: John Duarte
QA Risk Assessment: Needs Assessment No Action
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages