This project is archived and is in readonly mode.

#1671 ✓resolved
Barry Hess

Inappropriate "@variable will no longer be implicitly assigned to variable" message

Reported by Barry Hess | December 30th, 2008 @ 09:53 PM | in 2.3.10

With Rails 2.2.2, I've started receiving a massive amount of deprecation messages for the pattern of setting a default partial variable to an instance (@) variable for easy use in my helpers.

For instance, I have the following in a partial:

<% @entry = entry -%>

Then I have a helper method, like the following, using @entry:

def date_class
  ' ' + @entry.created_at.to_s(:compact)

Which results in a multitude of:

DEPRECATION WARNING: @entry will no longer be implicitly assigned to entry. (called from date_class at .../app/helpers/notes_helper.rb:139)

I see a similar complaint registered on github, but I could not uncover any tickets.


Comments and changes to this ticket

  • Frederick Cheung

    Frederick Cheung December 30th, 2008 @ 10:42 PM

    Where's entry coming from at the top of your partial ?

  • Barry Hess

    Barry Hess December 30th, 2008 @ 10:45 PM


    <%= render :partial => "notes/entry", :collection => entries.sort_by(&:created_at)%>
  • Cyril Mougel

    Cyril Mougel December 31st, 2008 @ 03:39 PM

    @entry is a instance variable of ActionController::Base

    so use this value can be an error.

  • josh

    josh January 2nd, 2009 @ 04:05 AM

    • Milestone cleared.
    • State changed from “new” to “open”
    • Assigned user set to “josh”

    Seems that deprecation notice is causing alot of false negatives.

    Maybe we should just remove it? Unless someone has a proper fix.

  • josh

    josh February 3rd, 2009 @ 11:20 PM

    • State changed from “open” to “incomplete”
  • Chris Blackburn

    Chris Blackburn May 5th, 2009 @ 06:37 PM

    Is this still being looked at for a fix? Since 2.3.2 still has this problem I assume not. Please advise?

  • Jared

    Jared May 13th, 2009 @ 03:36 PM

    I'm having the same issue since upgrading from 2.1.0 to 2.3.2. Our partials never use instance variables, only the local variable. And passing in the :as => :varname does not remove the deprecation warnings.

  • josh

    josh August 19th, 2009 @ 03:47 PM

    • Assigned user cleared.
  • Rohit Arondekar

    Rohit Arondekar October 6th, 2010 @ 06:46 AM

    • State changed from “incomplete” to “stale”
    • Importance changed from “” to “Low”

    Marking ticket as stale. If this is still an issue please leave a comment with suggested changes, creating a patch with tests, rebasing an existing patch or just confirming the issue on a latest release or master/branches.

  • Ryan Bigg

    Ryan Bigg October 9th, 2010 @ 09:42 PM

    • Tag cleared.

    Automatic cleanup of spam.

  • Paul Cantrell

    Paul Cantrell October 21st, 2010 @ 04:21 PM

    This is still a problem in Rails 2.3.10. So, for example, this code in a (haml) partial generates the warning:


    This a particular problem for me. I can't just change it to, because I use this partial in several contexts -- some where I pass in :locals => { :user => foo }. So to fix the problem, I tried:

    - user ||= @user

    This code would fix the thing the deprecation warns about: user would be nil, so @user would be copied to it. But because user is set to the proxy object that gives the warnings, so I still get a bunch of now-bogus warnings.

    For now, I'm fixing it like this:

    - user = @user if @user

    That works, but it's more brittle. My partial will break if @user ever happens to be set and somebody passes in user as a local. The user ||= @user approach is more solid, but generates the warning.

    SUGGESTED FIX: Give me a flag to go ahead and have @user be nil, i.e. let me actually turn on the thing that the deprecation warns about.

  • Rohit Arondekar

    Rohit Arondekar October 23rd, 2010 @ 01:43 PM

    • State changed from “stale” to “open”
    • Assigned user set to “Andrew White”
  • Andrew White

    Andrew White October 25th, 2010 @ 01:59 PM

    • Milestone set to 2.3.10

    Okay, I finally managed to reproduce this. The key fact is that the passed local assign needs to be nil, otherwise the proxy object isn't created. We can fix this by checking to see if the local assigns has a key for :object or the variable name and not creating the proxy object if it exists. Steps to reproduce:

    # app/controllers/pages_controller.rb
    class PagesController < ApplicationController
      def index
        @message = "Foo"
    # app/views/pages/_message.html.erb
    <%= h message %>
    # 1. This will raise a deprecation warning in index.html.erb
    <%= render :partial => 'message', :locals => { :message => nil } %>
    # 2. This will raise a deprecation warning in index.html.erb
    <%= render :partial => 'message' %>
    # 3. This will not raise a deprecation warning in index.html.erb
    <%= render :partial => 'message', :locals => { :message => "Bar" } %>

    Adding the check for the key in local assigns will fix example 1 but example 2 will still raise the error which is what's desired. Performance impact should be negligible since most of the time the conditional will be short-circuited.

  • Repository

    Repository October 26th, 2010 @ 01:03 PM

    • State changed from “open” to “resolved”

    (from [0e52a609fd38856100ef5ab4ce8fe1207e417eca]) Don't create a deprecation proxy object if the variable was passed in local_assigns [#1671 state:resolved]

  • bingbing

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

Referenced by