| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 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.
|
|
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.
|
|
The change in PUP-1220 (turning off access to dynamic scope)
accidentally also turned off access to inherited scope.
This is a big problem because it blocks the most used pattern of getting
parameters into classes in modules (and then accessing them in
templates).
|
|
As suggested by Henrik Lindberg, make the parser only behave correctly
when parser=future is configured. If working manifests rely on the
regression, the next point release won't break them. Instead, users can
test for this using the configuration setting.
The next major release should adopt the fix as standard behavior and
the legacy support should be removed. Since the variable lookups in
templates relies on the accessing of local attributes, there is no
way to issue deprecation warnings to users.
|
|
The fix for #1427 added an instance method to the scope class
for exporting all variables from the local scope. This method
apparently re-implemented the dynamic scoping rules.
When those were removed, the #to_hash method was left as was.
As a result, dynamic scoping still worked from within templates,
when using the @variable syntax in the erb code.
Fix this by using the new #enclosing_scope method so that proper
scoping rules are used instead.
|
|
This changes scope_spec to run for both current and future parser.
(At this point, the future evaluator still has issues; to be
fixed in coming committs).
|
|
This cleans up source formatting (spaces/tabs), dead todo, blank lines,
ending without a linebreak, and corrects indentation.
|
|
This adds tests to ensure that the way scope is handled in the case of a
variable name colliding with a class name is nailed down. It also adds a
case to call out that nodescope is different from topscope.
|
|
|
|
* upstream/2.7rc:
(#14297) Don't remove tty1 or rsyslog during upstart acceptance
(#14297) Define agent in upstart acceptance test
(#14297) Update upstart provider acceptance tests
(#14297) Clean up upstart provider and tests
(#14343) Test cases for more forms of variable lookup
(#14297) Add acceptance test for upstart provider
(#14297) Update spec tests for upstart provider
(#14297) Handle upstart services better
(#14343) Lookup in correct inherited scope
(Maint) Added test for fully qualified variables
Update CHANGELOG puppet.spec for 2.7.15rc2
Conflicts:
CHANGELOG
conf/redhat/puppet.spec
lib/puppet/parser/scope.rb
spec/unit/parser/scope_spec.rb
|
|
* upstream/2.7.x:
Apply commit from master that varies ports during tests
(#8174) Allow defines to reference topscope
Evaluate node classes either in top or node scope
Removed topscope being overridden by node
Update CHANGELOG lib/puppet.rb puppet.spec for 2.7.15rc1
Conflicts:
acceptance/tests/language/node_overrides_topscope_when_using_enc.rb
lib/puppet.rb
spec/integration/network/server/mongrel_spec.rb
spec/unit/parser/scope_spec.rb
|
|
Scoping for classes included by an ENC follow some rules that are not
immediately obvious. These tests should nail down and clarify that
behaviour
|
|
These test cases cover what happens in what used to be dynamic lookup
situations.
|
|
The += operator was changing the value of the variable that it was
supposed to clone when the value was an array.
|
|
Since these are using the entire parser/compiler system they don't
really qualify as unit tests.
|
