| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
snippets
In the puppet 4.0 parser, the file resource's mode property will be
required to be a string containing an octal (or symbolic) representation
of mode.
For consistency then, this commit changes all cases where mode was
specified as a Numeric to be a string containing an octal representation
of mode (always prefaced with a 0, again for clarity and consistency).
|
|
There was a regression in the future parser in d25e462 which caused
resources with multiple attributeless bodies constructed like this:
file {
'/foo':;
'/bar':;
}
to fail because the future parser grammar was not allowing the terminal
semicolon. The acceptance suite picked this up running with parser
future. It slipped past specs because, even though we have a spec
testing multiple attributeless resource bodies, it lacked a terminal
semicolon.
Henrik Lindberg figured out the minor egrammar fix here to correct the
expression, and a test case is added to catch it in specs.
|
|
This changes the following:
* Assignment has lower precedence than resource expressions
* Local defaults are supported in resource instantiation expressions
* A Resource body may have a new expression AttributesOperation that
must evaluate to a hash.
* Stricter validation of resource titles
* Changes to TreeModelDumper wrt how BlockExpression is rendered (to
improve debugging output). As a consequence many tests needed
adjustments.
* Tests that previously passed have been modified because of stricter
validation.
This also includes maintenance. Removing dead code/fixing stale comments
and documentation.
|
|
The future parser removed the support to name a class "class". This
led to missing that it is possible to create a virtual or exported
class using resource expression syntax e.g. @class { 'theunreal': }.
This is now fixed by adding an explicit parer rule for the @/@@ class
case.
|
|
The API and Impl modules were an interesting idea that has just been
leading to confusion about where things live. Moving forward the public
vs. private distinction for API purposes should be handled with @api
annotations in documentation and clear responsibilities of classes and
modules.
|
