Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Eric Thompson updated an issue Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Eric Thompson QA Risk Assessment: Low Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Eric Thompson updated an issue Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Eric Thompson QA Status: Reviewed Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Eric Thompson updated an issue Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Eric Thompson QA Risk Assessment: Low Medium Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Henrik Lindberg assigned an issue to qa Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Henrik Lindberg Status: Ready for Merge Test Assignee: Henrik Lindberg qa Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Peter Huene assigned an issue to Henrik Lindberg Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Peter Huene Assignee: Peter Huene Henrik Lindberg Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Henrik Lindberg assigned an issue to Peter Huene Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Henrik Lindberg Assignee: Henrik Lindberg Peter Huene Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Henrik Lindberg assigned an issue to Henrik Lindberg Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Henrik Lindberg Assignee: Henrik Lindberg Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Peter Huene updated an issue Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Peter Huene Scope Change Category: Adopted Scope Change Reason: Related to other validation work in the native parser Sprint: Language Triage 2016-06-29 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Henrik Lindberg commented on NPUP-12 Re: Incorrect logic for detecting "value produced but forgotten" errors. afaik, the Ruby impl does flag ($foo=1) + 1 since the + _expression_ is idem. I think it helps if the two implementations behave the same way. Not sure if you are saying that there is something missing/wrong with the Ruby impl, if so I can imagine changing it. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Peter Huene commented on NPUP-12 Re: Incorrect logic for detecting "value produced but forgotten" errors. I think the confusion here is that I attempted to be stricter than the Ruby implementation in terms of detecting "expressions without effect". For example, the native compiler will error (with the outstanding PR that fixes a bug) if you attempt to compile ($foo = 1) + 1 because, while the nested _expression_ does have an effect, the subsequent addition operation produces a value that is not used and thus makes the overall _expression_ superfluous. Contrast this with just $foo = 1, which has an effect and produces a value that was "used". The question of "is the entire _expression_ 'productive' (in the sense that it accomplished something)?" was related to checking "statement-level" expressions. The question of "does this _expression_ have a side-effect?" would be a different question to ask default parameter values because it is always assumed those expressions to be "productive" as they are implicitly being assigned to a variable. This is why I was discussing the need for two different functions earlier. I can certainly limit the "has effect" checking to any part of the _expression_ rather than the whole _expression_, which in this case we would only need one function instead of the two I proposed above: _expression_::has_side_effect. I have no qualms about matching the Ruby implementation's behavior or making the requirement that statement-level expressions have a side-effect (rather than checking for "unused" result) and do an additional warning-level diagnostic for expressions that produce "unused" results like the one above. Personally I think detecting statement-level expressions without effect, such as 1 + 1, to be the realm of a linter and not a compiler, but I understand the reasons why we do this in the compiler. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Peter Huene assigned an issue to Peter Huene Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Peter Huene Assignee: Peter Huene Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Henrik Lindberg commented on NPUP-12
Re: Incorrect logic for detecting "value produced but forgotten" errors.
The Ruby implementation has a function that determines if an _expression_ modifies "state". The 'idem' function in the checker return true if the _expression_ leaves state unchanged ('idem' is latin and means 'same'; i.e. state is the same before and after evaluation). Since functions (and EPP (which are essentially functions) can contain logic that could possibly alter state, they are considered to be "state changing" since it is too expensive to figure out if they actually alter state (and also quite impossible when a function in written in Ruby).
It is somewhat odd for an _expression_ to answer if its result is ignored, since it is really a combination of what it does on its own, and where it appears. I like 'has_side_effect' better, (the 'idem' function is equivalent to '! has_side_effect').
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in theblock(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to never produce an ignored result only if the operand does ; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsNote, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
This
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in theblock(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to never produce an ignored result; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsNote, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
This message was sent by Atlassian
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in the block(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsAdditionally, class and defined type expressions should not allow any ignored results in their blocks , including the last expressions in the block _expression_ . Currently they allow the last _expression_ to have an ignored result as if they return the value, which is incorrect.Note, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser was originally written, it attempted to copy the Ruby implementation 's "unproductive expressions may only appear last in a block" error message. At the time, I confused assumed the word "unproductive" to mean meant "accomplishes nothing", i.e. an _expression_ that is effectively useless since it produced a value that was then ignored (e . This error message has since changed to a less confusing g. {{ <_expression_> has no effect. A value was produced and then forgotten (one or more expressions may have the wrong form) 1 + 1 }} by itself) . It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature. Because the original intent of {{_expression_::is_productive}} was to mean " has side effect accomplishes something " and not "does this produce a value that is ignored ?", I propose renaming {{_expression_::is_productive}} to {{_expression_:: has_effect has_ignored_result }}. This The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are assumed to never produce an ignored result; however, they should be checked for "returning" a value from their blocks that isn't assigned to / returned.* Unary expressions are assumed to never produce an ignored result; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressions
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in the block(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressions Additionally, class and defined type expressions should not allow any ignored results, including the last expressions in the block. Currently they allow the last _expression_ to have an ignored result as if they return the value, which is incorrect. Note, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in the block(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsAdditionally, class, defined type, and node expressions should not allow any ignored results in their blocks, including the last _expression_. Currently they allow the last _expression_ to have an ignored result as if they return the value, which is incorrect.Note, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a any side effect to the evaluation state when evaluated . ? This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in the block(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsAdditionally, class and , defined type , and node expressions should not allow any ignored results in their blocks, including the last _expression_. Currently they allow the last _expression_ to have an ignored result as if they return the value, which is incorrect.Note, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are assumed to never produce an ignored result; however, they should be checked for "returning" a value from their blocks that considered ignored if containing no expressions in theblock(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are assumed to never produce an ignored result; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressions Note, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are assumed to never produce an ignored result; however, they should be checked for "returning" a value from their blocks that isn't assigned to / returned is ignored .* Unary expressions are assumed to never produce an ignored result; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressions
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native parser evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in theblock(s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsNote, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
This
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title
Peter Huene updated an issue
Native Puppet / NPUP-12
Incorrect logic for detecting "value produced but forgotten" errors.
Change By:
Peter Huene
When the native evaluator was originally written, it attempted to copy the Ruby implementation's "unproductive expressions may only appear last in a block" error message. At the time, I assumed the word "unproductive" meant "accomplishes nothing", i.e. an _expression_ that is effectively useless (e.g. {{1 + 1}} by itself). It seems this meaning is also used in the context of whether or not an _expression_ produces a value that is ignored, which is confusing nomenclature.Because the original intent of {{_expression_::is_productive}} was to mean "accomplishes something" and not "does this produce a value that is ignored?", I propose renaming {{_expression_::is_productive}} to {{_expression_::has_ignored_result}}.The logic for detecting whether or not something produces a result that is ignored is currently incorrect:* Conditional expressions are incorrectly assumed to never produce an ignored result; however, they should be considered ignored if containing no expressions in theblock the block (s) or if the last _expression_ in the block is itself ignored.* Unary expressions are incorrectly assumed to produce an ignored result only if the operand does; however, they should always produce an ignored result.The following expressions should still be considered as producing a result that is *not* ignored:* Assignment expressions* Relationship expressions* Function/method call expressions* All catalog expressions* All EPP expressionsNote, we probably want a different function, such as {{_expression_::has_side_effect}} which behaves like the current implementation of the soon-to-be-renamed "is_productive": does this _expression_ cause a side effect to the evaluation state when evaluated. This can be used for places where expressions with side effects are disallowed (such as parameter default value expressions).
Add Comment
Jira (NPUP-12) Incorrect logic for detecting "value produced but forgotten" errors.
Title: Message Title Peter Huene updated an issue Native Puppet / NPUP-12 Incorrect logic for detecting "value produced but forgotten" errors. Change By: Peter Huene Summary: Incorrect logic for detecting " value produced but forgotten" errors. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
