Skip to content

Add specs for reserved keywords #1187

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

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

amomchilov
Copy link
Contributor

Add specifications for all the reserved keywords, documenting which of them can be used as:

  1. local variables
  2. instance variables
  3. global variables
  4. positional parameter names
  5. keyword parameter names
  6. method names

Comment on lines 4 to 5
# Copied from Prism::Translation::Ripper
keywords = [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: It would be nice to have one canonical list that can be used in all these places:

  1. spec/ruby/language/hash_spec.rb
  2. spec/ruby/language/reserved_keywords.rb
  3. lib/prism/translation/ripper.rb
  4. Ideally, it would also be nice to generate doc/keywords.rdoc from that list, to ensure that all keywords are documented.

Where should such a canonical list live?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no way to avoid duplication there, since it's files in different repositories.
So for ruby/spec let's have it as a new file under language/fixtures.
I think a %w[] array would be nice for this BTW.

FWIW in ruby/ruby there is also defs/keywords.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, done: 0f54929 (#1187)

Copy link
Member

@eregon eregon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding these specs seems good but they should match the existing style and structure of ruby/spec, I'll review in more details once it does.

@amomchilov amomchilov requested a review from eregon May 11, 2025 18:01
__LINE__
]

keywords.each do |kw|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
keywords.each do |kw|
keywords.each do |name|

kw feels too confusing here, especially since there is a spec about keyword arguments below.
Since we are mostly testing names for variables/methods, name seems clearer in usages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmmm I disagree, in a spec focused on describing the behaviour of keywords, I would expect "keyword" to a be prominent term. It's an overloaded term, but that's just how Ruby is already. Perhaps keyword is better than kw?

Anyway, I renamed to name

@eregon
Copy link
Member

eregon commented May 22, 2025

Thanks for taking another stab at this.
Could you address my comments? Then I think it should be good to merge.

Copy link
Contributor Author

@amomchilov amomchilov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think that's everything addressed.

I kept the history in tract to make it easier to review, but I'll squash and rebase before merging

__LINE__
]

keywords.each do |kw|
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmmm I disagree, in a spec focused on describing the behaviour of keywords, I would expect "keyword" to a be prominent term. It's an overloaded term, but that's just how Ruby is already. Perhaps keyword is better than kw?

Anyway, I renamed to name

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

Successfully merging this pull request may close these issues.

3 participants