Frozen-string-literal comment detection does not detect comment headers.

[envygeeks]

A comment header does not affect Frozen-string-literal: true in Ruby, however, when using comment headers Rubocop does not properly detect Frozen-string-literal: true:

# ----------------------------------------------------------------------------
# Frozen-string-literal: true
# Copyright: 2015 - 2016 Jordon Bedwell - Apache v2.0 License
# Encoding: utf-8
# ----------------------------------------------------------------------------

Luna::RSpec::Formatters::Profile::EXAMPLES.frozen? # => true

lib/luna/rspec/formatters/profiles.rb:1:1: C: Missing frozen string literal comment.
# ----------------------------------------------------------------------------
^

[gylaz]

Should that be # frozen_string_literal: true? Either way, RuboCop doesn't seem to pick up on that comment option either.

[envygeeks]

The example I gave clearly indicates that the way I did it works... Rubocop does pick up the comment without the header, try using the master branch instead of the stable release.

[durrantm]

Yes it should be # frozen_string_literal: true as # Frozen_string_literal:true doesn't work

[envygeeks]

@durrantm sorry, but you are wrong.

cat test1.rb && bundle exec ruby test1.rb && printf "\n\n" && \
cat test2.rb && bundle exec ruby test2.rb

# Frozen-string-literal: true
$stdout.puts "".frozen?
true


# Frozen-STRING-Literal: true
$stdout.puts "".frozen?
true

[hendie]

I bumped my head against this one today: @envygeeks in the example you show at the top of this thread, you wrote Frozen-string-literal: true. Rubocop didn't get that one for me either, but when I changed to underscores: Frozen_string_literal: true everything magically started working (as in the later examples above). Those underscores can be ugly gotchas! Maybe Ruby is lenient with minuses and underscores, but Rubocop certainly isn't.

[mikegee]

I'm having a hard time finding a definitive answer on the format of Ruby's magic comments, so I struggled through Ruby's parse.y to figure it out myself.

I'm pretty sure this part means dashes and underscores are equivalent and this case-insensitive comparison means case doesn't matter.

I suspect a minor adjustment to the regex in Rubocop::MagicComment will resolve this issue.

[backus]

@mikegee correct that adjusting that regex will fix the issue.

I'm having a hard time finding a definitive answer on the format of Ruby's magic comments, so I struggled through Ruby's parse.y to figure it out myself.

You are correct that it is barely documented. I included three relevant links in the docs for that MagicComment file just search for @see. Beyond that there is the parse.y which you have correctly dug through to find the correct behavior. It looks like changing the separators in that regex to be [_\-] and to add the i regex option would address this issue. If you do fix this issue by updating the magic comment implementation can you add @see links for the examples you found in the parse.y? Otherwise it becomes extremely annoying to verify that the RuboCop magic comment handling matches ruby's

[mikegee]

@envygeeks While looking into this issue I found that the Encoding comment must be the first line of code (except an optional shebang line) for Ruby to respect your declaration.

Since UTF-8 is the default source encoding since Ruby 2.0, this issue is moot in the particular snippet you posted.

This can be enforced by enabling Style/Encoding and configuring it to always expect an encoding comment:

Style/Encoding:
  Enabled: true
  EnforcedStyle: always

Style/Encoding is disabled by default and would enforce never including an encoding comment if simply enabled.