My project uses HoundCI as a code linter, which I believe internally uses rubocop.
Recently I started noticing this sort of warning -
It appears on every class definition (e.g. class User < ActiveRecord::Base).
I understand the concept of freezing string literals, but why would it expect me to freeze class definitions? Also more importantly, how do I disable it? It's quite annoying to have 10+ of these "errors" polluting our pull requests.
Thank you!
Edit: Looks like it also started appearing on require statements that use string literals, like with rspec tests. This is definitely new and wasn't being flagged previously
It looks like Hound/Rubocop is detecting a violation of the FrozenStringLiteralComment cop.
This cop is designed to help upgrade to Ruby 3.0. It will add the comment # frozen_string_literal: true to the top of files to enable frozen string literals. Frozen string literals will be default in Ruby 3.0. The comment will be added below a shebang and encoding comment. The frozen string literal comment is only valid in Ruby 2.3+.
You can either add the magic comment manually to the top of your files
# frozen_string_literal: true
Or have Rubocop do it for you
$ bundle exec rubocop --auto-correct --only FrozenStringLiteralComment
You can also ignore the cop in your rubocop.yml, Style/FrozenStringLiteralComment
Related
I wrote a lib/animal.rb with several lists of params, and I want to reference that list in my controller and add it my params list. I did this because I use this list in several locations and didn't want to litter my code with a bunch of references to the library.
Controller
ANIMAL_TYPE_INPUT_PARAMS = *Animals::ANIMAL_TYPE_PARAMS.freeze
....
def familar_params
params.permit(ANIMAL_TYPE_INPUT_PARAMS, OTHER_PARAM_LIST....)
end
Lib/animal.rb
module Animal
# param lists
ANIMAL_TYPE_PARAMS = [
:animal_has_fur, :animal_id, :animal_weight
].freeze
end
Functionally it works just fine, but I am seeing a weird rubocop error. I would prefer to not disable MutableConstant for this section (disabling rubocop is usually a band aid that you pay for at some point).
Rubocop error
app/controllers/api/v1/example_controller.rb:55:24: C: Freeze mutable objects assigned to constants.
ANIMAL_TYPE_INPUT_PARAMS = *Animals::ANIMAL_TYPE_PARAMS.freeze
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I looked into this question: Ruby rubocop: how to freeze an array constant generated with splat But mine are already arrays, so I feel like it doesn't apply to me / shouldn't have to call to_a.
As #drenmi suggested, it was an older version of rubocop giving me this error. Once I upgraded to 0.46.0 the error was no longer.
I primarily work in Rails and I'm using a command line data conversion gem, "Mongify" and I am stumped about how to extend core classes in a Ruby cli app.
I want to extend the String class with an .is_date? method to check whether a string can be converted to a Date. I've got it working in the Rails Console,
I added a string.rb file to lib/ext with the following;
class String
def is_date?
begin
return true if Date.parse(self)
rescue
#do nothing
end
return false
end
end
Then in a Rails console I do a require 'ext/string' and it will work.
But I can't figure out how to get it to work in the Mongify cli app. I copied string.rb into the lib folder of the gem and I've tried adding require 'string' to a number of different files in the gem, but I keep getting undefined method errors.
Can someone point me in the right direction?
How about you require it from lib/mongify.rb like so:
require 'string/extensions.rb'
And then put your code in lib/string/extensions.rb
Let us know the exact undefined method errors you're getting in case this isn't the solution.
To help you with the debugging exercise that would give you the answer you need. Start by putting a breakpoint right before the place of the function call.
In the debugger, load the required document and then step past your breakpoint to the next one after the call has occurred.
Once you have this working, then start earlier in the stack trace – in a file that loaded before that one. Keep moving backwards until you get to a sufficiently early part in the load process of the gem, and make that be the place you load your code.
I'm upgrading my Rails app to work with Ruby 1.9 and I keep encountering errors like this:
Anonymous modules have no name to be referenced by
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:585:in `to_constant_name'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:391:in `qualified_name_for'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:104:in `rescue in const_missing'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:94:in `const_missing'
/home/foo/app/config/environment.rb:66:in `block in <top (required)>'
etc.
Google finds all kinds of hits for this, but each of them pertains to a specific fix for one specific gem or app. None of them explain what the message really means.
What is an "anonymous module"?
Where is this error message coming from? (The Ruby interpreter itself?)
What is different about Ruby 1.9 that causes this? (Rails 2.3.8 with Ruby 1.8.7 does not encounter this.)
What is the general/proper way to fix this error?
Line 66 of environment.rb is the configuration for super_exception_notifier (old version, 2.0.8):
ExceptionNotifier.configure_exception_notifier do |config|
config[:sender_address] = %("Foo" <foo#foo.com>)
config[:exception_recipients] = %w(foo#foo.com)
config[:skip_local_notification] = false
end
From what I can tell, ExceptionNotifier is undefined, and ActiveSupport is trying to magically load it, but fails and then fails again trying to print a nice error message.
An anonymous module is a module that is declared like so:
Fred = Module.new do
def meth1
"hello"
end
def meth2
"bye"
end
end
instead of by using the regular Module mod_name <block> syntax. Since they have no module name, you can't retrieve the module name. to_constant_name is attempting to call desc.name.blank? where desc is an anonymous module (with no name).
This error is coming from the ActiveSupport module, which may indicate a bug in the active_support gem or may indicate that some other piece of code is using ActiveSupport incorrectly. The error message alone doesn't give enough information to identify the culprit (to me at least, someone with more rails experience might be able to provide more insight).
Without knowing the offending code it's also hard to say exactly why this error is popping up with 1.9, or what needs to be done to fix it. Considering that there are a lot of un- and under-maintained gems out there that have not been updated for 1.9 yet, I would suspect that ActiveSupport is not the source of the problem. Upgrade all of your gems that have 1.9-compatible versions, and then try disabling your other gems one at a time (if you can) and see if you still get the error.
If you provide a list of the other gems that you are using, someone else who may have encountered the error before may be able to provide some details.
This may happen if you try to exploit ActiveRecord's internal class and module contexts in the wrong way. I had this error yesterday while working on a gem which extends deep inner workings of ActiveRecord. I finally managed to get around this problem by redesigning my code which exploits the inner contexts. It would be interesting to see the surrounding lines of environment.rb:66 for further analysis.
This may happen when the class name doesn't match the filename, in
my case it was a file named application.rb contaning the ApplicationController
class. Renaming the file to application_controller.rb solved the problem.
When I got this error, it was due to a misspelling while defining a class. If you are getting this error, it may be worth examining your module and class definitions for typos.
I have an issue while running my specs for a rails application with rake, it freezes on a certain spec. I would like to see what spec is running.
I have pretty funny answer for you.
The problem as I see it is that the name of the spec is written after the success or failure. And in your case it will never happen.
So you can bring a custom formatter! Yes, it will work. The problem is that base formatter defines a lot of points like when group starts, when example starts, but available formatters ( http://github.com/rspec/rspec-core/tree/master/lib/rspec/core/formatters/ ) don't use the example_started method which is exactly the one you need.
Creating custom formatter is simple - just put this file into the spec/support/formatters/anxious_formatter.rb
class AnxiousFormatter < RSpec::Core::Formatters::DocumentationFormatter
def example_started(example)
message = "- #{example.description}"
output.puts message
output.flush
end
end
Then you can run this with:
spec -r spec/support/formatters/anxious_formatter.rb -f AnxiousFormatter spec/models/...
The example above is for Rails 3 and RSpec 2.0 - for previous version it will slightly differ. More about custom formatters (for Rails 2 and RSpec 1.x) can be found on the project wiki: https://github.com/dchelimsky/rspec/wiki/custom-formatters
Funny, isn't it?
I'm trying to port over some of my old rails apps to Ruby 1.9 and I keep getting warnings about how "Ruby 1.9 doesn't support Unicode normalization yet." I've tracked it down to this function, but I'm getting about 20 warning messages per request:
rails-2.3.5/activesupport/lib/active_support/inflector.rb
def transliterate(string)
warn "Ruby 1.9 doesn't support Unicode normalization yet"
string.dup
end
Any ideas how I should start tracking these down and resolving it?
If you are aware of the consequences, i.e. accented characters will not be transliterated in Ruby 1.9.1 + Rails 2.3.x, place this in config/initializers to silence the warning:
# http://stackoverflow.com/questions/2135247/ruby-1-9-doesnt-support-unicode-normalization-yet
module ActiveSupport
module Inflector
# Calling String#parameterize prints a warning under Ruby 1.9,
# even if the data in the string doesn't need transliterating.
if Rails.version =~ /^2\.3/
undef_method :transliterate
def transliterate(string)
string.dup
end
end
end
end
Rails 3 does indeed solve this issue, so a more future-proof solution would be to migrate towards that.
The StringEx Gem seems to work pretty well. It has no dependency on Iconv either.
It adds some methods to the String class, like "to_ascii" which does beautiful transliteration out of the box:
require 'stringex'
"äöüÄÖÜßë".to_ascii #=> "aouAOUsse"
Also, the Babosa Gem does a great job transliterating UTF-8 strings, even with language support:
"Jürgen Müller".to_slug.transliterate.to_s #=> "Jurgen Muller"
"Jürgen Müller".to_slug.transliterate(:german).to_s #=> "Juergen Mueller"
Enjoy.
That method definition is wrapped in an if-statement for Ruby 1.9. Right above it, you will find the regular definition, which shows a bit more of what this is doing. It's a method used to convert accented characters into their regular variants. E.g.: á => a, or ë => e
But this method is only used in parameterize, which is in turn defined right above transliterate. This is all still in ActiveSupport. I can't find anything that is directly calling parameterize.
So perhaps you're using parameterize or transliterate yourself, somewhere in your Rails application?
Common usage (according to the parameterize documentation) is for creating friendly permalinks from arbitrary strings, much like SO does, for example:
http://stackoverflow.com/questions/2135247/ruby-1-9-doesnt-support-unicode-normalization-yet
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Replace the body of the method with
raise "transliterate called"
and observe a backtrace which will show you where the stuff is coming from at the first call. Your app will of course collapse as well but that will likely give you the culprit from the first try.
I appreciate that this is a dirty way to solve the problem, but having read the error message I'm aware of the issue. So I want to get rid of the warnings. I dropped this code in environment.rb:
module ActiveSupport
module Inflector
# Calling String#parameterize prints a warning under Ruby 1.9,
# even if the data in the string doesn't need transliterating.
# Maybe Rails 3 will have fixed it...?
if RAILS_GEM_VERSION =~ /^2\.3/
undef_method :transliterate
def transliterate(string)
string.dup
end
end
end
end
If you'd rather not monkey patch the Inflector module, you can also do this...
Both of the following worked for me to silence this annoying "Ruby 1.9 doesn't support Unicode normalization yet" warning:
silence_stream(STDERR) {
whatever_code_caused_transliterate_to_be_called
}
or
silence_warnings {
whatever_code_caused_transliterate_to_be_called
}
This does have the disadvantage that it requires cluttering up your calling code, but it is a technique you can use generally whenever you don't want to see warnings or other output.
activesupport provides silence_stream and silence_warnings in activesupport-2.3.11/lib/active_support/core_ext/kernel/reporting.rb
String#unicode_normalize, String#unicode_normalize!, String#unicode_normalized? will be introduced in Ruby 2.2. Sample code and implementation can be seen in test case, lib/unicode_normalize.rb and lib/unicode_normalize/normalize.rb.
// U+00E1: LATIN SMALL LETTER A WITH ACUTE
// U+U+0301: COMBINING ACUTE ACCENT
puts "\u00E1" == "a\u0301".unicode_normalize(:nfc)
puts true == "a".unicode_normalized?(:nfc)