[PUP-2315] function call error message about mis-matched arguments is hard to understand - Puppet Tickets

Details

Type: Improvement
Status: Closed
Priority: Normal
Resolution: Fixed
Affects Version/s: None
Fix Version/s: PUP 4.3.0
Component/s: Compiler
Labels:
None

Template:
customfield_10700 32539
Story Points:
5
Sprint:
Language 2015-03-04, Language 2015-03-18, Language 2015-04-29, Language 2015-05-13, Language 2015-05-27, Language 2015-07-08, Language 2015-09-30, Language 2015-10-14

Release Notes:
New Feature
Release Notes Summary:

Hide
When giving arguments to functions, defined types, or classes, and they were not acceptable puppet would produce too much information and thereby making it hard to understand exactly were the unacceptable argument value was and why it was unacceptable.

This is now much improved and the presented error message points to what to fix.

Show
When giving arguments to functions, defined types, or classes, and they were not acceptable puppet would produce too much information and thereby making it hard to understand exactly were the unacceptable argument value was and why it was unacceptable. This is now much improved and the presented error message points to what to fix.

Description

The new function API checks the types of given arguments and gives an error. This error is hard to understand in several situations:

when a lambda is given where none is accepted since it only reports the given Callable type as if it was a regular parameter. It should call it out explicitly (since a Callable is an Object, it looks like the error is not legit). Calling the assert_type function with a lambda shows the bad error message.
When a lambda is expected, but does not match
Error spews out all details about the types (an array with thousands of entries is displayed)

We should implement an ExplainingTypeCalculator that:

explains why a match failed
is given the names of the input objects
produces a message with a reference rooted at the given name that shows where the error was found (e.g. $x[key][3] - expected X, got Y)
reduces the detailed type information in dependent types (e.g. Tuple, Array, Hash, Enum) such that repeated sequences are compacted (a sequence of 100 Integers may be displayed as Integer{100}

An error message now, may look like this:

Error while evaluating a Method call, function 'each' called with mis-matched arguments

       expected one of:

         each(Hash[Any, Any] hash, Callable[2, 2] block) - arg count {2}

         each(Hash[Any, Any] hash, Callable[1, 1] block) - arg count {2}

         each(Any enumerable, Callable[2, 2] block) - arg count {2}

         each(Any enumerable, Callable[1, 1] block) - arg count {2}

       actual:

         each(Tuple[Integer, Integer, Integer, Integer, Integer, Integer, Integer], Callable[Any, Any, Any]) - arg count {2} at line 1:29 on node foonode

It takes a while to figure out that the error is that the given block to the each function had three parameters where 1 or 2 were expected.
If each expected result shows the reason for rejection are shown it would display something like:

Error while evaluating a Method call, function 'each' called with mis-matched arguments

       expected one of:

         each(Hash[Any, Any] hash, Callable[2, 2] block) - arg count {2}

           rejected: $block[parameter_count] is 3 where 2 was expected

         each(Hash[Any, Any] hash, Callable[1, 1] block) - arg count {2}

           rejected: $block[parameter_count] is 3 where 1 was expected

         each(Any enumerable, Callable[2, 2] block) - arg count {2}

           rejected: $block[parameter_count] is 3 where 2 was expected

         each(Any enumerable, Callable[1, 1] block) - arg count {2}

           rejected: $block[parameter_count] is 3 where 1 was expected

       actual:

         each(Tuple[Integer, Integer, Integer, Integer, Integer, Integer, Integer], Callable[Any, Any, Any]) - arg count {2} at line 1:29 on node foonode

Or, it may be clearer if it does this:

Error while evaluating a Method call, function 'each' called with mis-matched arguments

       expected one of:

         1. each(Hash[Any, Any] hash, Callable[2, 2] block) - arg count {2}

         2. each(Hash[Any, Any] hash, Callable[1, 1] block) - arg count {2}

         3. each(Any enumerable, Callable[2, 2] block) - arg count {2}

         4. each(Any enumerable, Callable[1, 1] block) - arg count {2}

       actual:

         each(Tuple[Integer, Integer, Integer, Integer, Integer, Integer, Integer], Callable[Any, Any, Any]) - arg count {2} at line 1:29 on node foonode

           rejected because:

           1. $block[parameter_count] is 3 where 2 was expected

           2. $block[parameter_count] is 3 where 1 was expected

           3. $block[parameter_count] is 3 where 2 was expected

           4. $block[parameter_count] is 3 where 1 was expected

And if we are able to detect a pattern (all caused by count being 3), we could point that out and at the end show:

          rejected because:

            $block[parameter_count] is 3

          ... and possibly the details 1-n

Naturally, if there is only one signature, the numbering should be skipped.

Attachments

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

Attachments

results-notes
19 kB
2015/10/01 4:14 PM

Issue Links

is blocked by

PUP-4438 Add required_repeated_param to 4.x function API

Closed

PUP-4458 Refactor validation of 4.x parameter signatures

Closed

relates to

PUP-2845 Move epp() and inline_epp() to 4x function API

Closed

PUP-2755 Move iterative functions to 4x function API

Closed

PUP-2794 Specify signatures for blocks of block-accepting methods

Closed

PUP-5207 spacing around commas incorrect when complaining about missing EPP values

Closed

links to

Document with examples

PR-4037

test case: function call error message about mis-matched arguments should be understandable

(1 relates to, 3 links to)

Options

Sub-Tasks

1.

Create spec test for useful function call error message

Closed

Unassigned

function call error message about mis-matched arguments is hard to understand

Details

Description

Attachments

Attachments

Issue Links

Sub-Tasks

Activity

jsd-sla-details-panel

People

Dates