I'm posting this here because I can't get it posted to the trac.
ActiveRecord::Calculations#construct_count_options_from_legacy_args
raises a deprecation warning. The only trouble is, it's only ever
called from ActiveRecord::Calculations::count, so it repeatedly tells
me I've called the offending deprecated function from within rails
itself.
The quick fix is to add 'caller(2)' to the arglist for
ActiveSupport::Deprecation#warn.
A better solution might be to use something akin to the Perlish
'carp', which walks up the call stack to find the first caller frame
(above the frame that made the call to carp) that isn't from the same
package/class as the call to carp and uses that as the place to report
the error from.
Piers Cawley <pdcawley@bofh.org.uk> writes:
I'm posting this here because I can't get it posted to the trac.
ActiveRecord::Calculations#construct_count_options_from_legacy_args
raises a deprecation warning. The only trouble is, it's only ever
called from ActiveRecord::Calculations::count, so it repeatedly tells
me I've called the offending deprecated function from within rails
itself.
Further to this, the deprecation warning in 'image_path' has similar
problems; it's not always called directly, sometimes it gets called
via image_tag, so again the deprecation warning isn't necessarily
useful. This isn't something that can be easily fixed by just adding
an extra argument to the call to Deprecation#warn though.
I ended up just throwing an exception to find my guilty code. And that
proved interesting too; I got a scad of deprecation warnings about
using @session and @params being called from
vendor/rails/actionpack/lib/action_view/template_error.rb:51, which is
weird because there's no reference to either of those variables at
that point.
