If a Error object was serialized in the database as YAML in the Rails
4.2 version, if we load in the Rails 5.0 version it will miss the
@details instance variable so methods like #clear and #add will start to
fail.
Now a few tests in ActiveModel rely on Ruby implementation and the fact
that in MRI `97.18` as a float is greater than `97.18` as a BigDecimal.
This is only relevant for MRI. On JRuby, comparing float to BigDecimal
would be conversion of them to the same type and they will be equal.
I'd like the ActiveModel test suite to be Ruby implementation-agnostic.
Here we test ActiveModel, not the Ruby internals.
This PR fixes a couple more JRuby tests.
This removes the following warnings.
```
activemodel/test/cases/type/big_integer_test.rb:15: warning: ambiguous first argument; put parentheses or a space even after `-' operator
```
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
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.
In Ruby ^ and $ mean start and end of *line*.
A regexp that validates an email should not check if
some line of the string looks like an email, and maybe
be surrounded by the entire Joyce's Ulysses. What the
regexp has to check is if the string itself looks like
an email.
This validator is used only in tests, the ^/$ anchors
implied no risk.
- The `Project` model should have been removed in 468939297db91f8e595a93c94a16e23b26eee61a.
- The superfluous require was added in 605c6455ac722ed9679e17458a47cc649cdedab0.
Closes#25215
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
We now use default procs inside of the errors object, which gets
included by default when marshaling anything that includes
`ActiveModel::Validations`. This means that Active Record objects cannot
be marshalled. We strip and apply the default proc ourselves. This will
ensure the objects are YAML serializable as well, since YAML falls back
to marshal implementations now. This is less important, however, as the
errors aren't included when dumping Active Record objects.
This commit does not include a changelog entry, as 5.0 is still in RC
status at the time of writing, and 5.0.0 will not release with the bug
this fixes.
Fixes#25165
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
- Pass object to I18n helper so that when calling message proc, it will
pass that object as argument to the proc and we can generate custom
error messages based on current record being validated.
- Based on https://github.com/rails/rails/issues/856.
[Łukasz Bandzarewicz, Prathamesh Sonpatki]
Since precision is always larger than scale, it can actually change
rounding behavior. Given a precision of 5 and a scale of 3, when you
apply the precision of 5 to `1.25047`, the result is `1.2505`, which
when the scale is applied would be `1.251` instead of the expected
`1.250`.
This issue appears to only occur with floats, as scale doesn't apply to
other numeric types, and the bigdecimal constructor actually ignores
precision entirely when working with strings. There's no way we could
handle this for the "unknown object which responds to `to_d`" case, as
we can't assume an interface for applying the scale.
Fixes#24235
From: https://github.com/rails/rails/issues/24279
Problem:
By doing `record.errors.include? :foo`, it adds a new key to the
@messages hash that defaults to an empty array.
This happens because of a combination of these 2 commits:
b97035df64
(Added in Rails 4.1)
and
6ec8ba16d8 (diff-fdcf8b65b5fb954372c6fe1ddf284c78R76)
(Rails 5.0)
By adding the default proc that returns an array for non-existing keys,
ruby adds that key to the hash.
Solution:
Change `#include?` to check with `has_key?` and then check if that value is
`present?`.
Add test case for ActiveModels::Errors#include?
