## Summary
`BigDecimal.new` is deprecated since BigDecimal 1.3.3 for Ruby 2.5.
This PR suppresses the following warnings.
```console
% ruby -v
ruby 2.6.0dev (2018-09-06 trunk 64648) [x86_64-darwin17]
% RUBYOPT=-w bundle exec rake
(snip)
/Users/koic/src/github.com/Shopify/liquid/lib/liquid/utils.rb:49:
warning: BigDecimal.new is deprecated; use Kernel.BigDecimal method
instead.
/Users/koic/src/github.com/Shopify/liquid/lib/liquid/utils.rb:53:
warning: BigDecimal.new is deprecated; use Kernel.BigDecimal method
instead.
```
## Other Information
The following is a change of BigDecimal 1.3.3 for Ruby 2.5 related to this PR.
- 533737338d
- 16738ad0ac
Measures:
1) A while loop is faster than iterating with #each.
2) Check string, variable and block tokens first. They are far more
frequent than interrupt tokens. In their case, checking for an
interrupt can be avoided.
3) String tokens just map to themselves and don't need the special
treatment of BlockBody#render_node (except the resource limit
check).
Benchmark
=========
$ bundle exec rake benchmark:run
Before
------
Run 1)
parse: 41.630 (± 0.0%) i/s - 420.000 in 10.089309s
render: 75.962 (± 3.9%) i/s - 763.000 in 10.066823s
parse & render: 25.497 (± 0.0%) i/s - 256.000 in 10.040862s
Run 2)
parse: 42.130 (± 0.0%) i/s - 424.000 in 10.064738s
render: 77.003 (± 1.3%) i/s - 777.000 in 10.093524s
parse & render: 25.739 (± 0.0%) i/s - 258.000 in 10.024581s
Run 3)
parse: 41.976 (± 2.4%) i/s - 420.000 in 10.021406s
render: 76.184 (± 1.3%) i/s - 763.000 in 10.018104s
parse & render: 25.641 (± 0.0%) i/s - 258.000 in 10.062549s
After
-----
Run 1)
parse: 42.283 (± 0.0%) i/s - 424.000 in 10.028306s
render: 83.158 (± 2.4%) i/s - 832.000 in 10.009201s
parse & render: 26.417 (± 0.0%) i/s - 266.000 in 10.069718s
Run 2)
parse: 41.159 (± 4.9%) i/s - 412.000 in 10.031297s
render: 81.591 (± 3.7%) i/s - 816.000 in 10.018225s
parse & render: 25.924 (± 3.9%) i/s - 260.000 in 10.035653s
Run 3)
parse: 42.418 (± 2.4%) i/s - 424.000 in 10.003100s
render: 84.183 (± 2.4%) i/s - 847.000 in 10.069781s
parse & render: 26.726 (± 0.0%) i/s - 268.000 in 10.029857s
It should now be harder to read the docs and miss the extra letter required for reversed compared to reverse, which causes a fairly generic syntax warning when trying to reverse sort a collection in a for loop.
This could be used to preserve the old default of rendering
non-Liquid::Error messages or for providing default behaviour like error
reporting which could be missed if the exception renderer needed to be
specified on each render.
These errors may contain sensitive information, so is safer to
render a more vague message by default.
This is done by replacing non-Liquid::Error exceptions with a
Liquid::InternalError exception with the non-Liquid::Error accessible on
through the cause method. This also allows the template name and line
number to be attached to the template errors.
The exception_handler render option has been changed to exception_renderer
since now it should raise an exception to re-raise on a liquid rendering
error or return a string to be rendered where the error occurred.
The argument `truncate_string` is now coerced into a string to avoid
`NoMethodError`s. This is mostly for added resiliency. It is doubtful
that someone would actually intent to use a number as truncate string,
but accidentally supplying one is entirely possible.
When including a template which is not defined, the exception raised is
*undefined method `split` for nil:NilClass*
This occurs for a scenario like the following:
`{% include nil %}`
or
`{% include undefined-var %}`
Making the code raise an argument error to allow better understanding of
the include error
