Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-2315

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

    XMLWordPrintable

    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:
    • 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

          Issue Links

          is blocked by

          Improvement - An improvement or enhancement to an existing feature or task. PUP-4438 Add required_repeated_param to 4.x function API

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. PUP-4458 Refactor validation of 4.x parameter signatures

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. PUP-2845 Move epp() and inline_epp() to 4x function API

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. PUP-2755 Move iterative functions to 4x function API

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. PUP-2794 Specify signatures for blocks of block-accepting methods

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. PUP-5207 spacing around commas incorrect when complaining about missing EPP values

          • Normal - Regular issue, some loss of functionality under specific circumstances.
          • Closed
          links to

          Web Link Document with examples

          Web Link PR-4037

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

            Activity

              People

              Assignee:
              henrik.lindberg Henrik Lindberg
              Reporter:
              henrik.lindberg Henrik Lindberg
              QA Contact:
              Kurt Wall
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support