-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release-1.9: Backports for 1.9.3 #50507
Conversation
* Generalize Bool parse method to AbstractString Fixes JuliaStrings/InlineStrings.jl#57. We currently have a specialization for `parse(Bool, ::Union{String, SubString{String})` where `true` and `false` are parsed appropriately. The restriction to `Union{String, SubString{String}}`, however, means we don't get this behavior for other `AbstractString`s. In the linked issue above, for InlineStrings, we end up going through the generic integer parsing codepath which results in an `InexactError` when we try to do `Bool(10)`. The proposal in this PR takes advantage of the fact that there is only the 2 comparisons where we do `_memcmp` that require the input string to be "dense" (in memory), and otherwise, we just do a comparison against a `SubString` of the input string. Relatedly, I've wanted to introduce the concept of an abstrac type like: ```julia abstract type MemoryAddressableString <: AbstractString ``` where the additional required interface would be being able to call `pointer(::MemoryAddressableString)`, since a lot of our string algorithms depend on doing these kind of pointer operations and hence makes it quite a pain to implement your own custom string type. * Apply suggestions from code review Co-authored-by: Stefan Karpinski <[email protected]> Co-authored-by: Nick Robinson <[email protected]> Co-authored-by: Stefan Karpinski <[email protected]> Co-authored-by: Nick Robinson <[email protected]> (cherry picked from commit 63830a6)
(cherry picked from commit c470dc3)
(cherry picked from commit 7e3c706)
(cherry picked from commit 236c23b)
(cherry picked from commit 28720ff)
(cherry picked from commit c43e5a1)
Update URLs to JuliaHub blog (cherry picked from commit abae35c)
(cherry picked from commit 48c92c1)
Fixes the case from #50518, but we actually have two test cases in the tests that also hit this (e.g. this one: ``` f40964(xs::Int...=1; k = 2) = (xs, k) ```), but just happened not to hit the bad codegen path. #50556, once merged would have complained on those definitions as well, without this fix. (cherry picked from commit c272236)
(cherry picked from commit cb6d0f2)
…=false only check that values are finite in `generic_lufact` when `check=true` (cherry picked from commit 824cdf1)
The documentation of `Pkg.jl` is instructing developers to rely on the existence of this function, and there doesn't seem to be any alternative which is a part of the API that developers can use instead on to guarantee forward compatibility for the same behavior. `Base.get_extension` is [referred to explicitly](https://pkgdocs.julialang.org/v1.9/creating-packages/#Backwards-compatibility) in the `Pkg.jl` docs to conditionally use package extensions vs `Requires.jl`. The `Pkg.jl` docs suggest ```julia if !isdefined(Base, :get_extension) include("../ext/PlottingContourExt.jl") end ``` to transition from "normal dependency to extension," which will break and automatically load the extension in future versions should `Base.get_extension` go away. `Base.get_extension` is the only way (that I know of) to directly access the module associated with a package extension, which can be a useful utility as well. (cherry picked from commit d1759bc)
(cherry picked from commit 462ac49)
Currently, `Array(r::AbstractRange)` falls back to `vcat(r)`, but certain ranges may choose to specialize `vcat(r::AbstractRange)` to not return an `Array`. This PR ensures that `Array(r)` always returns an `Array`. At present, there's some code overlap with `vcat` (just above the `Array` method added in this PR). Perhaps some of these may be replaced by `unsafe_copyto!`, but the tests for ranges include some special cases that don't support `getindex`, which complicates things a bit. I've not done this for now. In any case, the common bit of code is pretty simple, so perhaps the duplication is harmless. (cherry picked from commit 3cc0590)
@nanosoldier |
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Otherwise we may end up with the state of a dead thread, as the system IDs can alias. This can lead to an early return from the exception handler, resulting in e.g. safepoint exceptions being actually delivered to user code. --------- Co-authored-by: Jameson Nash <[email protected]> Co-authored-by: Cody Tapscott <[email protected]>
Is it possible to also backport #48909 to 1.9? The docs for 1.9.2 also show the issue with the admonition not appearing properly. |
The package evaluation job you requested has completed - possible new issues were detected. |
@nanosoldier |
The package evaluation job you requested has completed - no new issues were detected. |
This change simplifies the boundscheck in loop as LLVM would lift the const subtraction. Simd block would be generated in more cases. Co-authored-by: N5N3 <[email protected]> (cherry picked from commit 1543cdd)
Backported PRs:
!!! note
which was miscapitalized #50474versioninfo()
: include build info and unofficial warning #50635bit_map!
with aliasing #50781DelimitedFiles
#49582generic_lufact
whencheck=true
#50525Base.get_extension
to docs/API #50860Array(::AbstractRange)
should return anArray
#50568Need manual backport:
Non-merged PRs with backport label:
--heap-size-hint
arg handling #48050