| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Improve some DateAndTime calculations
|
| | |
|
|/
|
|
|
|
|
|
|
| |
DeepCover revealed that most of these `wday != 0 ? wday - 1 : 6`
were not entirely covered, i.e. the case of `wday == 0` was not tested:
https://deep-cover.github.io/rails-cover/activesupport/activesupport/lib/active_support/core_ext/date_and_time/calculations.rb.html#L351
There's actually no valid reason to consider Sunday a special case,
so this commit simply reajusts the values used for calculations.
|
|
|
|
|
|
|
|
| |
Since it is documented in the guides
http://edgeguides.rubyonrails.org/active_support_core_extensions.html#include-questionmark-and-cover-questionmark
we can add it to API docs http://edgeapi.rubyonrails.org too.
[ci skip]
|
|
|
|
|
|
|
|
|
|
| |
internal API [ci skip]
`:nodoc:` is specified, but unfortunately, it is exposed in the API doc.
http://edgeapi.rubyonrails.org/classes/Enumerable.html#method-i-_original_sum_with_required_identity
If the method of the `alias` destination is public, the specification of
`:nodoc:` does not seem to work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ruby/ruby@989e07c features switching `Range#===` to use internal `r_cover_p`
instead of rubyland `include?`. This breaks expected behavior of
`ActiveSupport::CoreExt::Range` documented since at least 8b67a02.
This patch adds overrides on `Range#cover?` and `Range#===` and places all
three in a single module, `CompareWithRange`.
*Requiring core_ext/range/include_range now causes a deprecation warnning*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the app I'm working on I've wished that index_by had a buddy that would
assign the hash value instead of the key multiple times.
Enter index_with. Useful when building a hash from a static list of
symbols. Before you'd do:
```ruby
POST_ATTRIBUTES.map { |attr_name| [ attr_name, public_send(attr_name) ] }.to_h
```
But now that's a little clearer and faster with:
````ruby
POST_ATTRIBUTES.index_with { |attr_name| public_send(attr_name) }
```
It's also useful when you have an enumerable that should be converted to a hash,
but you don't want to muddle the code up with the overhead that it takes to create
that hash. So before, that's:
```ruby
WEEKDAYS.each_with_object(Hash.new) do |day, intervals|
intervals[day] = [ Interval.all_day ]
end
```
And now it's just:
```ruby
WEEKDAYS.index_with([ Interval.all_day ])
```
It's also nice to quickly get a hash with either nil, [], or {} as the value.
|
|
|
|
|
|
|
|
| |
See #29632 for details. In short, it's possible to enter `LoadError#is_missing?` when `LoadError#path` returns `nil`, leading to `path.sub` throwing an none-to-helpful `NoMethodError`.
This tiniest of patch inserts `#to_s` before the `sub` call to make sure it succeeds. Affected surface area should be just as tiny since something has already gone wrong to get us into `#is_missing?` and the current behavior when `#path` returns `nil` seems clearly not intended.
[Gannon McGibbon + Neil Souza]
|
| |
|
|
|
|
| |
It's not public API so don't document it.
|
| |
|
|
|
|
|
|
|
|
| |
This prevents duplication of code.
Prevent duplication of tests by moving them to `DateAndTimeBehavior`.
Related to #32185.
|
|\
| |
| | |
Add `before?` and `after?` methods to date and time classes
|
| |
| |
| |
| |
| |
| |
| |
| | |
Equality comparisons between dates and times can take some extra time to
comprehend. I tend to think of a date or time as "before" or "after"
another date or time, but I naturally read `<` and `>` as "less than"
and "greater than." This change seeks to make date/time comparisons more
human readable.
|
| | |
|
| |
| |
| |
| | |
since revision 62897 https://github.com/ruby/ruby/commit/234a30459cdae6aa7da6e28a1082d9c11f315696
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We test the failing case we're trying to patch; only if it throws an
Exception do we patch.
Currently this will *always* throw, but upstream Ruby has patched this
bug: https://git.io/vAxKB
Signed-off-by: Ashe Connor <ashe@kivikakk.ee>
|
|\ \
| |/
|/| |
URI.unescape "extension" fails with Unicode input
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, URI.enscape could handle Unicode input (without any actual
escaped characters), or input with escaped characters (but no actual
Unicode characters) - not both.
URI.unescape("\xe3\x83\x90") # => "バ"
URI.unescape("%E3%83%90") # => "バ"
URI.unescape("\xe3\x83\x90%E3%83%90") # =>
# Encoding::CompatibilityError
We need to let `gsub` handle this for us, and then force back to the
original encoding of the input. The result String will be mangled if
the percent-encoded characters don't conform to the encoding of the
String itself, but that goes without saying.
Signed-off-by: Ashe Connor <ashe@kivikakk.ee>
|
|/
|
|
|
|
|
|
|
| |
We have a bunch of documentation in
lib/active_support/core_ext/object/json.rb which is currently appearing
as documentation for the top-level ActiveSupport module. We hide it
from rdoc here.
Signed-off-by: Ashe Connor <ashe@kivikakk.ee>
|
|
|
|
|
|
|
|
|
| |
Convert the user to atheism by ditching the extra example that demonstrates
the same thing as date_of_birth.
Demonstrate the NoMethodError on date_of_birth first, then call age that
uses date_of_birth internally. Thus showing that accessing it publicly fails,
but using it internally succeeds.
|
|
|
|
|
|
| |
Numeric#positive? and Numeric#negative? was added to Ruby since 2.3,
see https://github.com/ruby/ruby/blob/ruby_2_3/NEWS
Rails 6 requires Ruby 2.4.1+ since https://github.com/rails/rails/pull/32034
|
|
|
|
|
| |
Ruby 2.4+ provides `Hash#compact` and `Hash#compact!` natively,
so `active_support/core_ext/hash/compact` is no longer necessary.
|
|
|
|
|
|
|
|
| |
correct value
Remove extra comments `# Asking for private method` in activesupport/test/core_ext/module_test.rb
Improve docs of using `delegate` with `:private`
Update changelog of #31944
|
| |
|
|
|
| |
Since #32034, Rails 6 requires Ruby 2.4.1+.
|
|
|
|
|
| |
This faithfully preserves grapheme clusters (characters composed of other
characters and combining marks) and other multibyte characters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```ruby
"foo".freeze.strip_heredoc.frozen? # => true
```
Fixes the case where frozen string literals would inadvertently become
unfrozen:
```ruby
foo = <<-MSG.strip_heredoc
la la la
MSG
foo.frozen? # => false !??
```
|
|
|
|
|
|
| |
Skipping over 2.4.0 to sidestep the `"symbol_from_string".to_sym.dup` bug.
References #32028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed this in my memory profiler report.
```
153 "@default_url_options"
152 /home/sam/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/activesupport-5.1.4/lib/active_support/core_ext/class/attribute.rb:84
```
152 copies of the string `@default_url_options` are retained on the heap in Discourse post boot.
Since this is just used for ivar lookups there is no need to use a string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
### Summary
This PR changes .rubocop.yml.
Regarding the code using `if ... else ... end`, I think the coding style
that Rails expects is as follows.
```ruby
var = if cond
a
else
b
end
```
However, the current .rubocop.yml setting does not offense for the
following code.
```ruby
var = if cond
a
else
b
end
```
I think that the above code expects offense to be warned.
Moreover, the layout by autocorrect is unnatural.
```ruby
var = if cond
a
else
b
end
```
This PR adds a setting to .rubocop.yml to make an offense warning and
autocorrect as expected by the coding style.
And this change also fixes `case ... when ... end` together.
Also this PR itself is an example that arranges the layout using
`rubocop -a`.
### Other Information
Autocorrect of `Lint/EndAlignment` cop is `false` by default.
https://github.com/bbatsov/rubocop/blob/v0.51.0/config/default.yml#L1443
This PR changes this value to `true`.
Also this PR has changed it together as it is necessary to enable
`Layout/ElseAlignment` cop to make this behavior.
|
| |
|
|\
| |
| | |
Fix performance issue with NameError#missing_name on ruby >= v2.3.0.
|
| |
| |
| |
| |
| | |
Since ruby v2.3.0 `did_you_mean` gem shipped and ENABLED by default.
It patches NameError#message with spell corrections which are SLOW.
|
|\ \
| | |
| | | |
Add support for multiple encodings in String.blank?
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Motivation:
- When strings are encoded with `.encode("UTF-16LE")` `.blank?` throws
an `Encoding::CompatibilityError` exception.
- We tested multiple implementation to see what the fastest
implementation was, rescueing the execption seems to be the fastest
option we could find.
Related Issues:
- #28953
Changes:
- Add a rescue to catch the exception.
- Added a `Concurrent::Map` to store a cache of encoded regex objects
for requested encoding types.
- Use the new `Concurrent::Map` cache to return the correct regex for
the string being checked.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`BigDecimal.new` has been deprecated in BigDecimal 1.3.3
which will be a default for Ruby 2.5.
Refer
https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503
* This commit has been made as follows:
```
cd rails
git grep -l BigDecimal.new | grep -v guides/source/5_0_release_notes.md | grep -v activesupport/test/xml_mini_test.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g"
```
- `activesupport/test/xml_mini_test.rb`
Editmanually to remove `.new` and `::`
- guides/source/5_0_release_notes.md
This is a Rails 5.0 release notes.
|
| | |
| | |
| | |
| | |
| | | |
Example codes that use `has_many` or `before_create` in `Module::Concerning` look like active record models.
So I've made them inherit `ApplicationRecord`.
|
| | |
| | |
| | |
| | |
| | | |
(#31275)
https://www.ruby-lang.org/en/news/2016/09/08/ruby-2-4-0-preview2-released/
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These methods were originally added in https://github.com/rails/rails/pull/26600
This includes a couple of refactors to make these methods behave more similarly to other Date/Time extensions added by Active Support:
1. Use `advance` instead of `since` and `ago` to time-travel — this is particularly important to keep the returned instance’s class matching `self`. Before this change:
today = Date.today # => Tue, 28 Nov 2017
today.class # => Date
today.next_occurring(:wednesday) # => Wed, 29 Nov 2017 00:00:00 UTC +00:00
today.next_occurring(:wednesday).class # => ActiveSupport::TimeWithZone
After this change, a Date (or Time, or DateTime) instance is properly returned (just like is shown in the new docs). This is generally how everything else in DateAndTime::Calculations works.
2. Move the tests from the DateTime tests to the DateAndTimeBehavior tests. The latter location is mixed in to the core_ext tests for _all_ of Date, Time, and DateTime to test the behavior across all of the classes. The previous location is for testing core_ext functionality added specifically just to DateTime.
3. Better docs!
|
| | |
| | |
| | | |
[ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In #11474 we prevented TWZ ranges being iterated over which matched
Ruby's handling of Time ranges and as a consequence `include?` stopped
working with both Time ranges and TWZ ranges. However in
ruby/ruby@b061634 support was added for `include?` to use `cover?` for
'linear' objects. Since we have no way of making Ruby consider TWZ
instances as 'linear' we have to override `Range#include?`.
Fixes #30799.
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
bogdanvlviv/method_signature_prev-next-day-month-year_for_time
Mirror the API of Ruby stdlib for #prev_day, #next_day, #prev_month, #next_month, #prev_year, #next_year
|
| | | |
|
| | | |
|