Ruby already does this freeze for us.

A few have been left for aesthetic reasons, but have made a pass
and removed most of them.

Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Having collection caching that wraps templates and automatically tries
to infer if they are cachable proved to be too much of a hassle.

We'd rather have it be something you explicitly turn on.

This removes much of the code and docs to explain the previous automatic
behavior.

This change also removes scoped cache keys and passing cache_options.

The instrument method creates new strings, the most common action to instrument is "!render_template` so we can detect when that action is occurring and use a frozen string instead.

This change buys us 113,714 bytes of memory and 1,790 fewer objects per request.

I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?

To look at memory:

```ruby
require 'get_process_mem'

mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb

after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"

```

Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.

To look at raw speed:

```ruby
require 'benchmark/ips'

number_of_objects_reduced = 1_114

Benchmark.ips do |x|
  x.report("freeze")    { number_of_objects_reduced.times { " ".freeze } }
  x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```

We get the results

```
Calculating -------------------------------------
              freeze     1.428k i/100ms
           no-freeze   609.000  i/100ms
-------------------------------------------------
              freeze     14.363k (± 8.5%) i/s -     71.400k
           no-freeze      6.084k (± 8.1%) i/s -     30.450k
```

Now we can do some maths:

```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration 

ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration 

diff = call_time_before - call_time_after

number_of_objects_reduced * diff * 100

# => 0.4530373333993266 miliseconds saved per request
```

So we're shaving off 1 second of execution time for every 220 requests. 

Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep. 

p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings. 

Keep those strings Frozen

![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)

If a template includes `# Template Collection: ...` anywhere in its
source, that name will be used as the cache name for the partial that is
rendered for the collection.

This allows users to enable collection caching even if the template
doesn't start with `<% cache ... do %>`.

Moreover, the `# Template Collection: ...` notation is recognized in all
template types (and template types other than ERB can define a
resource_cache_call_pattern method to allow the `cache ... do` pattern
to be recognized too).

Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.

The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.

So with a notifications/_notification.html.erb template like:

```ruby
<% cache notification %>
  <%# ... %>
<% end %>
```

A collection would be able to use `multi_read` if rendered like:

```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```

the ERB has already been compiled to Ruby code by the time we're calling
module_eval.  Nothing that module eval raises will be caught by a blank
`rescue`, so I think we can remove this

[ci skip]

This is an option for to HTML content with a content type of
`text/html`. This rendering option calls `ERB::Util.html_escape`
internally to escape unsafe HTML string, so you will have to mark your
string as html safe if you have any HTML tag in it.

Please see #12374 for more detail.

Avoid unnecessary catching of Exception instead of StandardError (converting Exceptions into StandardErrors)

This worked in Rails 3.2, but was a regression in 4.0.0.beta1

* core_ext/object/blank
* concern
* core_ext/class/attribute
* deprecation

It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.

AV::Template::Types is a small abstraction to allow to specify template types
that can be used in ActionView. When Action Pack is loaded it's replaced with
Mime::Type.

Action View should not be responsible for translating mime types. Any
translation that's needed should be handled at controller level.

This addresses an issue where in multi-threaded environments
multiple threads can attempt to compile a template at the same time,
which occasionally causes particular templates to end up in a bad
state.

So, add synchronization such that only a single thread can attempt to
compile a template at one time.

Template concurrency fixes
Conflicts:

	actionpack/lib/action_view/template.rb