Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add future parser's Puppet Types token type #435

Merged
merged 1 commit into from Jun 24, 2016

Conversation

mcanevet
Copy link
Contributor

@mcanevet mcanevet commented Aug 1, 2015

No description provided.

@raphink
Copy link
Contributor

raphink commented Aug 4, 2015

👍 , definitely needed

@strider
Copy link

strider commented Aug 4, 2015

👍

@jlambert121
Copy link

Absolutely needed

@bastelfreak
Copy link
Contributor

Hi @rodjek, could you please have a look here?

@ahpook
Copy link
Collaborator

ahpook commented Jun 24, 2016

Merging, thanks for the 👍 s - for future reference that | separated list of types seems kind of brittle, any thoughts on how to refactor that?

@ahpook ahpook merged commit 9bb0f06 into rodjek:master Jun 24, 2016
@hlindberg
Copy link
Collaborator

The list of types is both brittle, and not correct since data types can be namespaced. The Rule for data types is actually the same as for a CLASSREF, this because all references to things like File, User, etc. are also data types, and so are the references to user defined resource types (created with 'define').
Not sure what puppet-lint does with the CLASSREF that would make it unsuitable for all data types. The problem here is that it is impossible to statically know what a CLASSREF is referring to as that requires loading the actual referenced entity (a resource type in ruby, a data type, type alias, or a user defined resource type).
The static list in this PR is already behind, and there will be additional types added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants