Age | Commit message (Collapse) | Author | Files | Lines |
|
The :undef symbol was still leaking all over the place internally. This
caused type inference to sometimes end up with Runtime[ruby, Symbol]. By
using nil instead of :undef, everything can be much more
straightforward. Once the code removal for puppet 4 comes into play even
more oddities around how resource parameters are handled can be
performed.
|
|
For PUP-2857 :undef was changed from being a PNilType to a PRuntimeType.
This stopped the undef literal in the language from being able to be
assigned to Optional parameters. However, this only happened when the
undef was the default expression for the parameter.
|
|
hlindberg/PUP-3117_resource-expression-splat-rocket-alt
(PUP-3117) Complete the Resource Expression implementation
|
|
This completes the implenentation of the Resource Expression.
* The LHS must now be a QualifiedName (i.e. file, notify), or
a QualifiedReference (i.e. File, Notify), or an access expression
with a left QualifiedReference (i.e. Resource[file]), or literal
'class'
* The result of the LHS must be a CatalogEntry type, and it may not
be detailed to title level.
* The * => syntax can be used to to unfold a hash. It may be used
once per titled resource body. Attribute names must be unique across
the attributes set with name => expr, and those set with * => hash.
|
|
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).
|
|
|
|
This fixes a problem in the grammar that made it impossible to have
more than one *=> per body.
This commit also adds a check for duplicate entries in the resulting
hash with the final set of parameter to value mapping.
|
|
It is now possible by checking if the result of a "produce" had
no effect on the catalog by comparing against an empty array.
|
|
This changes the tests of the puppet language, which should become part
of the language specification's example and test suite, to be entirely
expressed in the puppet language. This removes any dependency on ruby!
Well, any dependency on ruby for specifying the language tests.
|
|
PUP-121 was supposed to make all references to classes and resource
types absolute, but it looks like it missed a spot. The class referenced
in an inherits clause was not being looked up in an absolute manner,
which caused it to find the wrong parent class in certain cases. This
changes the future parser so that inherited classes are always absolute
names.
|
|
The resource_expressions_spec contained a useful way of writing language
specification tests. This extracts those out so that they can be reused
in other places.
|
|
The comment had trailing whitespace and a comma. It makes more sense
without either.
|
|
(PUP-2972) Remove += and -=
|
|
The previous error message was very abrupt and didn't provide any kind
of guidance for the user. The new message for += and -= let's them know
that it is *no longer* supported and has a link to where they can get
more information.
|
|
Previously the future parser supported += and -=. += was very similar to
the same operator that is in the current parser, but with a few
differences to make it consistent with the rest of the
language. The += operator no longer performed string concatenation and
instead acted like $a = $a + $b. The -= operator was added to complete
the set of operators available.
However, many people have been confused by these operators (even as they
exist in the current parser):
* It looks like mutation, but the language does not have mutation
* It looks like += from other languages, but doesn't behave like them
* Shadowing a variable is something that needs to be explicit,
otherwise it becomes confusing.
This removes += and -= from the future parser. They are still parsed,
but the validation step will issue errors if they are encountered.
|
|
This reverts the change in PUP-867 by (again) calling the same 3x logic
for looking up defaults. The implementation of PUP-867 also added tests,
and one of those are now changed to reflect the changed behavior.
|
|
Ruby 1.8.7 doesn't allow trailing commas in parameter lists. This
problem was present in the resource_expressions_spec file and is removed
by this commit.
Ruby 1.8.7 doesn't have an empty? method for Symbol. This changes the
evaluator_impl to compare against the EMPTY_STRING constant instead,
which does work on 1.8 and 1.9.
|
|
This adds a combined example of most of the features being used
together: title expressions, type expressions, splatted parameters,
exported resource, and resource reference.
|
|
This adds checks for the specification's assertions that virutal and
exported resources are not in the produced catalog, but are available
for later operations (realization) and reference (reading a parameter
value). This cannot check that the exported resources are made available
to catalog processors, since that is implementation dependent.
In order to check this the compile_to_catalog method needed to be
changed to filter out expoerted resources, just like the catalog
indirection does. This required a change to the create_resources test.
|
|
When a title array is empty, there are no resources created.
|
|
Prior to this commit, empty string titles did not cause an error.
However according to the specifications, a string should have a
minimum length of one. With this commit, the parser will now
raise an issue when an empty string title is given.
|
|
The implementation for *=> looks to have been a copy-paste from the =>
implementation, however the expression attribute on AttributesOperation
is just `expr` and not `value_expr`.
|
|
This adds tests around the behavior of the current and the future
evaluator's resource instantiation expressions. There are many cases in
the current system where the tests are commented out because there isn't
any consistent behavior.
|
|
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.
|
|
I believe most of these predated our clearing the settings before each
test in the central puppet/test/test_helper.rb. And since we then set
some base settings (such as :environment_timeout) in the test_helper,
the effect of a secondary clear in the test itself is to wipe out the
baseline setup test_helper just laid down.
In particular this is a problem with environment_timeout, as it leads to
tests which end up creating environments, getting them cached with the
default 180s timeout, which can leak to subsequent tests and create
unpleasant spec order issues.
|
|
(PUP-2891) Treat override of class as an error.
|
|
An attempt to collect classes led to an error message that said
that 'class' is not a known resource type (in a way that can be
misinterpreted).
This commit make the error message specific, and clear.
|
|
This test had a flaw in it before where if the collection was not even
done, the test would still pass. In order to check that collection
applies to realized resources the resources need to be changed. This
adds an override so that we can see the effect of the collection
expression on realized resources.
|
|
(PUP-500) Add additional tests cases
|
|
This makes an attempt to override a class parameter issue an
error from the runtime layer rather than expecting the underlying
3x implementation to do it when the left expression does not
result in a resource, or a resource that has 'class' as resource type.
|
|
The lookup of resource parameters via the type e.g. Notify[id][message]
performed the lookup in the calling scope, not the resource's closure
scope which resulted in parameter default values were being seen from
the perspective of the caller (they may be very different).
This corrects the lookup to use the resource's closure scope.
|
|
Test cases added that test that the current implementation does
not regress from its current behavior.
Regular resources are collected. Collection with override can be
done multiple times. Changing and amedning values work for
regular resources as well as virtual.
|
|
The +> form of collection hadn't been covered in any test cases that I
could find. This adds some coverage.
|
|
The tags and array handling of collection queries is "special". This
adds some test coverage around that behavior.
|
|
The virtual resource collection uses the comparator for include?, but a
previous commit changed the signature. This wasn't caught until the
acceptance tests ran because it turns out that the collection tests were
not being run against the future parser.
This fixes the problem by passing the scope that is available for
collection to the method. It also removes two of the acceptance tests in
favor of adding a new integration test and running the collection tests
with the future parser.
|
|
zaphod42/issue/master/pup-1299-magic-array-parameters
(PUP-1299) Stop stripping arrays in future parser
|
|
Resource values that were arrays used to be converted to a single value
iff the array only had one element. This created a lot of confusion for
type and provider authors when the value they would set in a manifest
would not be the value they would get in the type. The conversion causes
large amounts of code that would check for values that aren't arrays and
convert them to arrays in various places. There were also often tests
that would be written directly against providers that would then not
catch errors in real use because the author was unaware, or just forgot,
that the array conversion would happen.
Under the future parser this is no longer done. The old behavior,
however, won't issue a deprecation warning because there isn't anything
that can be done about it from a user's perspective. The most likely
outcome from this change is that some manifests may stop working because
a value just happened to be a single-valued array that was on a
parameter that is not supposed to take an array. In such cases the error
would have been masked previously, but now will be uncovered.
|
|
The future parser needs to be as close as possible to what will be the
default in Puppet 4. By making the node inheritance a warning instead of
an error, it makes it so that Puppet 4 will be significantly different
from puppet 3 with --parser future. This changes it so that both Puppet
4 and Puppet 3 with parser future will disallow node inheritance. The
error message is retained, which should provide good guidance whenever a
user does encounter this.
This change leaves all of the tests for node inheritance only working on
the --parser current. In addition an acceptance test that simply checked
variable scoping with an ENC has been converted to an integration test
along with all of the other tests about variable scope.
|
|
This renames the top most type in the type system to Any from
the name Object. This is done because the word Object carries
connotations of "Object Oriented Programming" that simply adds confusion
about how puppet works.
This commit is basically a rename refactoring.
|
|
This makes a deprecation warning being logged whenever a
node is instantiated with a parent in 3x, and a warning is issued
during validation of the source text when future parser is used.
The intent is to remove the support for node inheritance in
Puppet 4.0.0.
|
|
(PUP-514) Add support for optionally typed parameters.
|
|
Object is now the top class and so there is no need to use
Optional[Object] everywhere. This removes the type factory method
optional_object and replaces all occurrances with just object. It also
updates all of the uses of Optional[Object] to use just Object.
|
|
|
|
The previous implementation checked the argument types twice against the
signature. This reduces it to a single check. The error for a missing
argument is now caught in a place that used to be unreachable and so the
error has been converted into an issue, which also provides the
information about where the failure occurred.
|
|
This adds a check when the signature for a closure is being calculated
to catch invalid parameter specifications where required arguments are
placed after optional onces. Allowing that would mean that the argument
range information would be incorrect.
|
|
This updates Closure code to implement type checking for the parameter
values.
|
|
The work so far has not been able to deal with type checking lambdas.
This adds tests for the conditions that will need to be handled for
lambdas to properly type check their arguments. Currently none of these
new tests pass.
|
|
|
|
This changes the warning issued on the code path when a resource type
is required in order to do deserialization (apply phase). When this
happens on the server side (or during apply), the full source is
available, and the type in "known resource types" is loaded code that
may have typed parameters. This second time, no validation can and will
not take place because it is happening where there is no top scope
available. (This is fine, and should use result in a debug output).
This also fixes a couple of typos.
|
|
|