Skip to main content

Browse the archive

https://github.com/JuliaLang/julia
30 August 2024, 22:04:04 UTC
sort by:
Revision Author Date Message Commit Date
0bc1842 KristofferC 14 May 2024, 13:36:57 UTC show some printouts 14 May 2024, 13:36:57 UTC
830f23b Kristoffer 15 April 2024, 14:37:49 UTC Fix `JULIA_CPU_TARGET` being propagated to workers precompiling stdlib pkgimages Apparently (thanks ChatGPT) each line in a make file is executed in a separate shell so adding an `export` line on one line does not propagate to the next line. 14 May 2024, 13:09:05 UTC
5949e0b Daniel Karrasch 14 May 2024, 07:49:06 UTC Cast back `svd`/`eigen` of symmetric `Float16` matrices to `Float16` (#54403) 14 May 2024, 07:49:06 UTC
828655c Jishnu Bhattacharya 14 May 2024, 07:37:42 UTC LinearAlgebra: compile-time stride check in `gemv!` to reduce latency (#54449) 14 May 2024, 07:37:42 UTC
c3f1479 Shuhei Kadowaki 14 May 2024, 05:14:59 UTC Follow ups to #54341 (Move nargs/isva to CodeInfo) (#54453) 14 May 2024, 05:14:59 UTC
931f6de Kristoffer Carlsson 13 May 2024, 18:27:44 UTC Revert "add unsetindex support to more copyto methods (#51760)" (#54332) This reverts commit f0a28e9a45a34f1c524b3cf02cbbac1351f1da81. This introduced in general a try catch inside the inner loop for `copyto!` and it also has performance regression in other cases https://github.com/JuliaLang/julia/issues/53430. Since this was added without any tests and "is not-quite-public API" it seems easiest to just revert it. This was added for Memory-to-Array and vice versa but dedicated methods could be added for that if it is desirable Fixes https://github.com/JuliaLang/julia/issues/53430, https://github.com/JuliaLang/julia/issues/52070 13 May 2024, 18:27:44 UTC
b9f68ac Neven Sajko 13 May 2024, 13:57:49 UTC fixes to colonful `reshape` (#54261) Fixes #54245 13 May 2024, 13:57:49 UTC
bbae417 Cody Tapscott 13 May 2024, 13:09:22 UTC show: improve processed StackTrace check (#54381) This change is necessary for widely-typed vectors of stack traces to work correctly: ```julia Base.show_backtrace(stdout, convert(Vector{Any}, Base.stacktrace())) ``` which currently outputs a confusing error: ```julia Stacktrace: ERROR: MethodError: no method matching iterate(::Base.StackTraces.StackFrame) ... ``` 13 May 2024, 13:09:22 UTC
7ff3d6f Neven Sajko 13 May 2024, 11:35:56 UTC delete unused function `Base.Iterators.tail_if_any` (#54442) Apart from being unused, it was a duplicate of `Base.safe_tail`. A JuliaHub search shows the function being completely unused across the ecosystem: https://juliahub.com/ui/Search?q=tail_if_any&type=symbols 13 May 2024, 11:35:56 UTC
7e9676d KristofferC 13 May 2024, 11:34:55 UTC Revert "Support broadcasting over structured block matrices (#53909)" This reverts commit 243ebc389eec78f060a47c53375b3fd48c462d76. 13 May 2024, 11:34:55 UTC
2f92015 Morten Piibeleht 13 May 2024, 11:03:50 UTC Fix docs builds when not in Git tree (#54445) The documentation builds can fail if the Julia source code is not properly in a Git repo (tarballs, Buildkite). This should ensure that Documenter knows which remote repository corresponds to the Julia source tree. Hopefully will fix https://github.com/JuliaCI/julia-buildkite/issues/336 13 May 2024, 11:03:50 UTC
04a91bf KristofferC 09 May 2024, 09:52:46 UTC Revert "Use `copyto!` in converting `Diagonal`/`Bidiagonal`/`Tridiagonal` to `Matrix` (#53912)" This reverts commit 19919b70d342250c69b59e006d2b1e1dd704c06a. 13 May 2024, 10:59:38 UTC
f8a7496 Kristoffer 06 May 2024, 10:08:05 UTC Revert "Add `_unsetindex!` methods for `SubArray`s and `CartesianIndex`es (#53383)" This reverts commit 1a9040908b9bb89927b2d318da3f9fe1e457abea. 13 May 2024, 10:59:38 UTC
ff7e7b8 Kristoffer 02 May 2024, 14:18:48 UTC Revert "add unsetindex support to more copyto methods (#51760)" This reverts commit f0a28e9a45a34f1c524b3cf02cbbac1351f1da81. 13 May 2024, 10:59:38 UTC
20c3628 Kristoffer Carlsson 13 May 2024, 10:16:18 UTC comment out an assertion that fires when loading Parquet2 (#54408) Removes the milestone from https://github.com/JuliaLang/julia/issues/53109, see https://github.com/JuliaLang/julia/issues/53109#issuecomment-2072747065 Co-authored-by: KristofferC <kristoffer.carlsson@juliacomputing.com> 13 May 2024, 10:16:18 UTC
8742d3c Kristoffer Carlsson 13 May 2024, 09:39:37 UTC Move ConsoleLogging.jl into Base (#54428) Fixes https://github.com/JuliaLang/julia/issues/51493, fixes https://github.com/JuliaLang/julia/issues/52075 13 May 2024, 09:39:37 UTC
3638c84 KristofferC 10 May 2024, 10:11:42 UTC move ConsoleLogger into Base 13 May 2024, 07:28:17 UTC
e844228 KristofferC 10 May 2024, 09:50:20 UTC Revert "Use StyledStrings for Logging (#51829)" This reverts commit 250916f3a4e515e6edcfcf831e381c38828c4ccc. 13 May 2024, 07:28:17 UTC
5006312 Jishnu Bhattacharya 12 May 2024, 16:17:01 UTC Reduce matmul latency by splitting small matmul (#54421) This splits the `matmul2x2` and `matmul3x3` into components that depend on `MulAddMul` and those that don't depend on it. This improves compilation time, as the `MulAddMul`-independent methods won't need to be recompiled in the `@stable_muladdmul` branches. TTFX (each call timed in a separate session): ```julia julia> using LinearAlgebra julia> A = rand(2,2); B = Symmetric(rand(2,2)); C = zeros(2,2); julia> @time mul!(C, A, B); 1.927468 seconds (5.67 M allocations: 282.523 MiB, 12.09% gc time, 100.00% compilation time) # nightly v"1.12.0-DEV.492" 1.282717 seconds (4.46 M allocations: 228.816 MiB, 4.58% gc time, 100.00% compilation time) # This PR julia> A = rand(2,2); B = rand(2,2); C = zeros(2,2); julia> @time mul!(C, A, B); 1.653368 seconds (5.75 M allocations: 291.586 MiB, 13.94% gc time, 100.00% compilation time) # nightly 1.148330 seconds (4.46 M allocations: 230.714 MiB, 4.47% gc time, 100.00% compilation time) # This PR ``` Edit: Not inlining the function seems to incur a runtime perfomance cost. ```julia julia> using LinearAlgebra julia> A = rand(3,3); B = rand(size(A)...); C = zeros(size(A)); julia> @btime mul!($C, $A, $B); 23.923 ns (0 allocations: 0 bytes) # nightly 31.732 ns (0 allocations: 0 bytes) # This PR ``` Adding `@inline` annotations resolves this difference, but this reintroduces the compilation latency. The tradeoff is perhaps ok, as users may use `StaticArrays` for performance-critical matrix multiplications. 12 May 2024, 16:17:01 UTC
25c8128 Jishnu Bhattacharya 12 May 2024, 10:03:45 UTC Aggressive constprop in istriu/istril for structured matrices (#54437) This makes the following evaluate at compile-time: ```julia julia> U = UpperTriangular(rand(2,2)); julia> @code_typed istriu(U) CodeInfo( 1 ─ return true ) => Bool ``` Also, this reduces latency in this operation: ```julia julia> @time (U -> istriu(U))(U) 0.069995 seconds (158.88 k allocations: 8.715 MiB, 83.72% compilation time) # nightly 0.035610 seconds (156.62 k allocations: 8.594 MiB, 68.18% compilation time) # This PR ``` Similar methods are annotated for other structured matrix types, where the results may be trivially obtained from the structure for certain values of the band index `k`. 12 May 2024, 10:03:45 UTC
d01d256 Keno Fischer 11 May 2024, 04:45:50 UTC Move nargs/isva to CodeInfo (#54341) This changes the canonical source of truth for va handling from `Method` to `CodeInfo`. There are multiple goals for this change: 1. This addresses a longstanding complaint about the way that CodeInfo-returning generated functions work. Previously, the va-ness or not of the returned CodeInfo always had to match that of the generator. For Cassette-like transforms that generally have one big generator function that is varargs (while then looking up lowered code that is not varargs), this could become quite annoying. It's possible to workaround, but there is really no good reason to tie the two together. As we observed when we implemented OpaqueClosures, the vararg-ness of the signature and the `vararg arguments`->`tuple` transformation are mostly independent concepts. With this PR, generated functions can return CodeInfos with whatever combination of nargs/isva is convenient. 2. This change requires clarifying where the va processing boundary is in inference. #54076 was already moving in that direction for irinterp, and this essentially does much of the same for regular inference. As a consequence the constprop cache is now using non-va-cooked signatures, which I think is preferable. 3. This further decouples codegen from the presence of a `Method` (which is already not assumed, since the code being generated could be a toplevel thunk, but some codegen features are only available to things that come from Methods). There are a number of upcoming features that will require codegen of things that are not quite method specializations (See design doc linked in #52797 and things like #50641). This helps pave the road for that. 4. I've previously considered expanding the kinds of vararg signatures that can be described (see e.g. #53851), which also requires a decoupling of the signature and ast notions of vararg. This again lays the groundwork for that, although I have no immediate plans to implement this change. Impact wise, this adds an internal field, which is not too breaking, but downstream clients vary in how they construct their `CodeInfo`s and the current way they're doing it will likely be incorrect after this change, so they will require a small two-line adjustment. We should perhaps consider pulling out some of the more common patterns into a more stable package, since interface in most of the last few releases, but that's a separate issue. 11 May 2024, 04:45:50 UTC
a910a99 Sukera 10 May 2024, 13:55:43 UTC Define `==`/`isequal`/`hash` for `Some` by forwarding to the wrapped value (#52421) The equality of two `Some` depends on the equality of the wrapped value, once the `Some` is unwrapped. --------- Co-authored-by: Alex Arslan <ararslan@comcast.net> Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com> 10 May 2024, 13:55:43 UTC
4793328 Orestis Ousoultzoglou 10 May 2024, 11:26:01 UTC Document supertype(T::UnionAll) (#54419) Fixes #54286. 10 May 2024, 11:26:01 UTC
0c6ee07 Shuhei Kadowaki 10 May 2024, 09:51:01 UTC compiler: minor inference adjustments (#54420) This PR consists of a collection of minor adjustments to inference. I've tried to ensure that the purpose of each change is communicated by each commit message. - tfuncs: cosmetic changes (63bdfe0addf71eee8250ea3e5aa87251ad28b305) * rm no longer necessary type assertions * rm extra newlines * mk some indents more consistent with the others - tfuncs: refactor common `varargtype` check into `hasvarargtype` (b92adff1ecfcb7d561f67f8d63d028212375f0bf) - tfuncs: improve nothrow modeling of `tuple` and `svec` (9689fc00d3fb70f84df3812d810356b65ad14739) - inlining: replace `[builtin|intrinsic]_nothrow` checks with flag-base ones (ee736aecbdc76e57f1ae9c0ea53abe642c7925d7) - tfuncs: rm the weird `UnionAll` special case (f2f6256770865136cc17f97a393fb4cc92dacc31) 10 May 2024, 09:51:01 UTC
4b4c4f9 KristofferC 10 May 2024, 09:47:31 UTC Revert "More cautious legacy_color conversion in Logging (#53280)" This reverts commit 61c3521613767b2af21dfa5cc5a7b8195c5bdcaf. 10 May 2024, 09:47:31 UTC
62b5159 Gabriel Baraldi 10 May 2024, 09:29:16 UTC Make Memory{T} respect the max alignment of the heap (#53748) Fixes https://github.com/JuliaLang/julia/issues/53683 10 May 2024, 09:29:16 UTC
6582eaa Timothy 10 May 2024, 07:08:01 UTC Highlight julia-repl code in Markdown specially (#54423) Fixes #54399 by re-introducing the code seperated out from the styled Markdown PR at Jameson's request (https://github.com/JuliaLang/julia/pull/51928#discussion_r1483598716). The code itself is modelled after [equivalent code in OhMyREPL](https://github.com/KristofferC/OhMyREPL.jl/blob/b0071f5ee785a81ca1e69a561586ff270b4dc2bb/src/MarkdownHighlighter.jl#L15-L31). The new `markdown_julia_prompt` face allows people to make the "prompt" shown in Markdown code visually distinct, to [avoid confusing it with the REPL prompt at a glance](https://github.com/KristofferC/OhMyREPL.jl/issues/100). By way of example, I make it italic by augmenting my `faces.toml` with ```toml [markdown] julia_prompt = { italic = true } ``` 10 May 2024, 07:08:01 UTC
01556a7 jonathan-conder-sm 10 May 2024, 06:36:29 UTC Artfifacts: track Artifacts.toml by hash instead of mtime (#54426) 10 May 2024, 06:36:29 UTC
3197075 Shuhei Kadowaki 09 May 2024, 18:12:50 UTC tfuncs: remove unnecessary varargtype check from `_builtin_nothrow` 10 May 2024, 02:25:03 UTC
eabc375 Shuhei Kadowaki 09 May 2024, 14:09:45 UTC tfuncs: rm the weird `UnionAll` special case `UnionAll` isn't a builtin function, so its `:nothrow` modeling shouldn't live in `_builitin_nothrow`. The existence of its special casing within `stmt_effect_flags` is also weird, and I confirmed it doesn't actually give us any refinement withe following patch, so is safe to be removed: ```diff diff --git a/base/compiler/optimize.jl b/base/compiler/optimize.jl index 85942d3ca8..9e17832d4f 100644 --- a/base/compiler/optimize.jl +++ b/base/compiler/optimize.jl @@ -294,7 +294,9 @@ end Returns a tuple of `(:consistent, :removable, :nothrow)` flags for a given statement. """ -function stmt_effect_flags(𝕃ₒ::AbstractLattice, @nospecialize(stmt), @nospecialize(rt), src::Union{IRCode,IncrementalCompact}) +function stmt_effect_flags(𝕃ₒ::AbstractLattice, @nospecialize(stmt), @nospecialize(rt), + src::Union{IRCode,IncrementalCompact}, + original_flag::Union{Nothing,UInt32}=nothing) # TODO: We're duplicating analysis from inference here. isa(stmt, PiNode) && return (true, true, true) isa(stmt, PhiNode) && return (true, true, true) @@ -318,9 +320,19 @@ function stmt_effect_flags(𝕃ₒ::AbstractLattice, @nospecialize(stmt), @nospe f = singleton_type(f) f === nothing && return (false, false, false) if f === UnionAll - # TODO: This is a weird special case - should be determined in inference - argtypes = Any[argextype(args[arg], src) for arg in 2:length(args)] - nothrow = _builtin_nothrow(𝕃ₒ, f, argtypes, rt) + nothrow = false + if length(args) == 3 + argtype3 = argextype(args[3], src) + if !isvarargtype(argtype3) + argtype2 = argextype(args[2], src) + if argtype2 ⊑ TypeVar && argtype3 ⊑ Type + nothrow = true + @assert (original_flag !== nothing && + has_flag(original_flag, IR_FLAG_NOTHROW) && + has_flag(original_flag, IR_FLAG_CONSISTENT)) "refinement detected" + end + end + end return (true, nothrow, nothrow) end if f === Intrinsics.cglobal || f === Intrinsics.llvmcall @@ -377,9 +389,10 @@ function stmt_effect_flags(𝕃ₒ::AbstractLattice, @nospecialize(stmt), @nospe end function recompute_effects_flags(𝕃ₒ::AbstractLattice, @nospecialize(stmt), @nospecialize(rt), - src::Union{IRCode,IncrementalCompact}) + src::Union{IRCode,IncrementalCompact}, + original_flag::Union{Nothing,UInt32}=nothing) flag = IR_FLAG_NULL - (consistent, removable, nothrow) = stmt_effect_flags(𝕃ₒ, stmt, rt, src) + (consistent, removable, nothrow) = stmt_effect_flags(𝕃ₒ, stmt, rt, src, original_flag) if consistent flag |= IR_FLAG_CONSISTENT end diff --git a/base/compiler/ssair/inlining.jl b/base/compiler/ssair/inlining.jl index 28b79cbfd3..db41b76bbb 100644 --- a/base/compiler/ssair/inlining.jl +++ b/base/compiler/ssair/inlining.jl @@ -1218,7 +1218,7 @@ end add_inst_flag!(inst::Instruction, ir::IRCode, state::InliningState) = add_inst_flag!(inst, ir, optimizer_lattice(state.interp)) function add_inst_flag!(inst::Instruction, ir::IRCode, 𝕃ₒ::AbstractLattice) - flags = recompute_effects_flags(𝕃ₒ, inst[:stmt], inst[:type], ir) + flags = recompute_effects_flags(𝕃ₒ, inst[:stmt], inst[:type], ir, inst[:flag]) add_flag!(inst, flags) return !iszero(flags & IR_FLAGS_REMOVABLE) end diff --git a/base/compiler/tfuncs.jl b/base/compiler/tfuncs.jl index 92b03964a1..3b3588a7da 100644 --- a/base/compiler/tfuncs.jl +++ b/base/compiler/tfuncs.jl @@ -2177,7 +2177,7 @@ end end # Query whether the given builtin is guaranteed not to throw given the argtypes -@nospecs function _builtin_nothrow(𝕃::AbstractLattice, f, argtypes::Vector{Any}, rt) +function _builtin_nothrow(𝕃::AbstractLattice, @nospecialize(f::Builtin), argtypes::Vector{Any}, @nospecialize(rt)) ⊑ = partialorder(𝕃) if f === memoryref return memoryref_builtin_common_nothrow(argtypes) @@ -2225,8 +2225,6 @@ end elseif f === (<:) na == 2 || return false return subtype_nothrow(𝕃, argtypes[1], argtypes[2]) - elseif f === UnionAll - return na == 2 && (argtypes[1] ⊑ TypeVar && argtypes[2] ⊑ Type) elseif f === isdefined return isdefined_nothrow(𝕃, argtypes) elseif f === Core.sizeof ``` 10 May 2024, 02:25:03 UTC
a6a082c Shuhei Kadowaki 09 May 2024, 11:42:51 UTC inlining: replace `[builtin|intrinsic]_nothrow` checks with flag-based ones 10 May 2024, 02:25:02 UTC
262a288 Lilith Orion Hafner 09 May 2024, 20:03:41 UTC Fix typo in test/filesystem.jl (#54425) Fixup for #54197. Sorry for breaking CI on master. 09 May 2024, 20:03:41 UTC
dbf0475 Lilith Orion Hafner 09 May 2024, 19:32:36 UTC Make `write` return `Int` instead of `UInt` in an obscure code-path. (#54197) 09 May 2024, 19:32:36 UTC
72e5525 Lilith Orion Hafner 09 May 2024, 19:30:49 UTC Make `repr(::Ptr)` parsable Julia code. (#54305) 09 May 2024, 19:30:49 UTC
b53b348 Shuhei Kadowaki 09 May 2024, 11:22:12 UTC tfuncs: improve nothrow modeling of `tuple` and `svec` 09 May 2024, 18:00:24 UTC
824a2ae Shuhei Kadowaki 09 May 2024, 11:18:07 UTC tfuncs: refactor common varargtype check into `hasvarargtype` 09 May 2024, 18:00:24 UTC
d543508 Shuhei Kadowaki 09 May 2024, 15:48:26 UTC optimize cases when there are no handles in the method body (#54415) 09 May 2024, 15:48:26 UTC
e5e6bb0 Shuhei Kadowaki 09 May 2024, 11:12:55 UTC tfuncs: cosmetic changes - rm no longer necessary type assertions - rm extra newlines - mk some indents more consistent with the others 09 May 2024, 13:11:37 UTC
3c966a5 Lilith Orion Hafner 09 May 2024, 11:53:59 UTC Optimize issorted for rev=true (#54220) 09 May 2024, 11:53:59 UTC
df89440 Kristoffer Carlsson 09 May 2024, 10:43:03 UTC account for extensions indirectly depending on each other in parallel package precompilation (#53972) In the parallel package precompilation code we are mapping what packages depend on what other packages so that we precompile things in the correct order ("bottom up") and so what we can also detect cycles and avoid precompiling packages in those cycles. However, we fail to detect one type of dependency which is that an extension can "indirectly" depend on another extension. This happens when the transitive dependencies of the extension (it's parent + triggers) are a superset of the dependencies of another extension. In other words, this means that the other extension will get loaded into the first extension once it gets loaded, effectively being a dependency. The failure to model this leads to some issues, for example using one of the examples in our own tests: ```julia julia> Base.active_project() "/home/kc/julia/test/project/Extensions/HasDepWithExtensions.jl/Project.toml" (HasDepWithExtensions) pkg> status --extensions Project HasDepWithExtensions v0.1.0 Status `~/julia/test/project/Extensions/HasDepWithExtensions.jl/Project.toml` [4d3288b3] HasExtensions v0.1.0 `../HasExtensions.jl` ├─ ExtensionFolder [ExtDep, ExtDep2] ├─ Extension [ExtDep] └─ LinearAlgebraExt [LinearAlgebra] julia> Base.Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 196.1 ms ✓ HasExtensions 244.4 ms ✓ ExtDep2 207.9 ms ✓ SomePackage 201.6 ms ✓ ExtDep 462.5 ms ✓ HasExtensions → ExtensionFolder 200.1 ms ✓ HasExtensions → Extension 173.1 ms ✓ HasExtensions → LinearAlgebraExt 222.2 ms ✓ HasDepWithExtensions 8 dependencies successfully precompiled in 2 seconds julia> Base.Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 213.4 ms ✓ HasExtensions → ExtensionFolder 1 dependency successfully precompiled in 0 seconds. 7 already precompiled. julia> Base.Precompilation.precompilepkgs(; timing=true) julia> ``` We can see here that `ExtensionFolder` gets precompiled twice which is due to `Extension` actually being an "indirect dependency" of `ExtensionFolder` and therefore should be precompiled before it. With this PR we instead get: ```julia julia> Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 347.5 ms ✓ ExtDep2 294.0 ms ✓ SomePackage 293.2 ms ✓ HasExtensions 216.5 ms ✓ HasExtensions → LinearAlgebraExt 554.9 ms ✓ ExtDep 580.9 ms ✓ HasExtensions → Extension 593.8 ms ✓ HasExtensions → ExtensionFolder 261.3 ms ✓ HasDepWithExtensions 8 dependencies successfully precompiled in 2 seconds julia> Precompilation.precompilepkgs(; timing=true) julia> ``` `Extension` is precompiled after `ExtensionFolder` and nothing happens on the second call. Also, with this PR we get for the issue in https://github.com/JuliaLang/julia/issues/53081#issue-2103686391: ```julia (jl_zuuRGt) pkg> st Status `/private/var/folders/tp/2p4x9ygx48sgsdl1ccg1mp_40000gn/T/jl_zuuRGt/Project.toml` ⌃ [d236fae5] PreallocationTools v0.4.17 ⌃ [0c5d862f] Symbolics v5.16.1 Info Packages marked with ⌃ have new versions available and may be upgradable. julia> Precompilation.precompilepkgs(; timing=true) ┌ Warning: Circular dependency detected. Precompilation will be skipped for: │ SymbolicsPreallocationToolsExt │ SymbolicsForwardDiffExt ``` and we avoid precompiling the problematic extensions. This should also allow extensions to precompile in parallel which I think was prevented before (from the code that is removed in the beginning of the diff). 09 May 2024, 10:43:03 UTC
3920694 Nathan Daly 09 May 2024, 10:16:20 UTC Type-stable codegen for specialized `in(v, ::Tuple)` (#54026) Since we were already specializing in for Tuples anyway, we should be generating code that can take advantage of the tuple type, rather than doing a generic, type-unstable traversal. Before: ```julia julia> @btime Base.in($(5), (1, 2.0, 3, "hey", 5.2)) 53.541 ns (6 allocations: 224 bytes) false ``` After: ```julia julia> @btime Base.in($(5), (1, 2.0, 3, "hey", 5.2)) 1.666 ns (0 allocations: 0 bytes) false ``` The new code statically unrolls the tuple comparisons, and thus also compiles away any of the comparisons that are statically known to be not equal, such as the `==(::Int, ::String)` comparison for element 4 in the example above. --------- Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com> 09 May 2024, 10:16:20 UTC
6f6bb95 Nero Blackstone​ 08 May 2024, 18:24:38 UTC Add musical symbols for unicode completions (#54182) I found that julia was missing some useful music notation unicode completions and sometimes [had to copy and paste these unicodes to use the published package](https://github.com/JuliaMusic/MusicTheory.jl/issues/27). So I picked out some unicode music symbols that might be useful, named from the [unicode standard](https://www.unicode.org/charts/PDF/U1D100.pdf). I didn't add the test, I don't think it's necessary. Thanks for reviewing. Please reply if any changes are needed. --------- Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com> 08 May 2024, 18:24:38 UTC
812848b DilumAluthgeBot 08 May 2024, 17:02:35 UTC 🤖 [master] Bump the SparseArrays stdlib from cb602d7 to a09f90b (#54406) Stdlib: SparseArrays URL: https://github.com/JuliaSparse/SparseArrays.jl.git Stdlib branch: main Julia branch: master Old commit: cb602d7 New commit: a09f90b Julia version: 1.12.0-DEV SparseArrays version: 1.12.0 Bump invoked by: @dkarrasch Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: https://github.com/JuliaSparse/SparseArrays.jl/compare/cb602d7b7cf46057ddc87d23cda2bdd168a548ac...a09f90b43105229e42ac687ab4e3f6cf50deed8c ``` $ git log --oneline cb602d7..a09f90b a09f90b Adjust matvec and matmatmul! to new internal LinAlg interface (#519) 3b30333 ci: run aqua test as a standalone ci job (#537) df0a154 Add versioned Manifest files to .gitignore (#534) 4606755 Extend `copytrito!` for a sparse source (#533) 33fbc75 SparseMatrixCSC constructor with a Tuple of Integers (#523) 08d6ae1 CI: don't run `threads` tests in Windows GHA CI (attempt 2) (#530) 7408e4b Revert "Don't fail CI if codecov upload fails." (#527) 287e406 Bump julia-actions/setup-julia from 1 to 2 (#524) b5de0da Don't fail CI if codecov upload fails. (#525) 78dde4c cast to Float64 directly instead of using float (#521) a5e95ec CI: Add Apple Silicon (macOS aarch64) to the CI matrix (#505) ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com> 08 May 2024, 17:02:35 UTC
88d6633 Kristoffer Carlsson 08 May 2024, 08:00:56 UTC fix `code_warntype` on `OpaqueClosure`s (#54378) Fixes https://github.com/JuliaLang/julia/issues/54375 --------- Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com> 08 May 2024, 08:00:56 UTC
29ced9e Daniel Karrasch 08 May 2024, 07:57:11 UTC Stabilize `MulAddMul` strategically (#52439) Co-authored-by: Ashley Milsted <ashmilsted@gmail.com> 08 May 2024, 07:57:11 UTC
999dde7 Jishnu Bhattacharya 08 May 2024, 04:10:46 UTC Unicode: assume foldable ccall in category_code (#54394) Following on from https://github.com/JuliaLang/julia/pull/54346, this marks the `ccall` in `category_code` as foldable. This lets us compute the results of several functions at compile time, such as: ```julia julia> @code_typed (() -> isletter('C'))() CodeInfo( 1 ─ return true ) => Bool julia> @code_typed (() -> isnumeric('C'))() CodeInfo( 1 ─ return false ) => Bool julia> @code_typed (() -> ispunct('C'))() CodeInfo( 1 ─ return false ) => Bool ``` 08 May 2024, 04:10:46 UTC
5f7bfc0 Cody Tapscott 07 May 2024, 21:17:52 UTC specialize `VersionNumber` constructors less aggressively (#54386) There's no need to specialize this code for every set of Tuple types that it might see, especially when the primary callers don't know their Tuple type any more precisely than this anyway. Eliminates a dynamic dispatch from `tryparse(VersionNumber, "...")` Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com> 07 May 2024, 21:17:52 UTC
1d7c771 Orestis Ousoultzoglou 07 May 2024, 20:49:15 UTC Document copy! for vector types (#54142) (#54392) Fixes https://github.com/JuliaLang/julia/issues/54142. Also documents the `firstindex(dst) == firstindex(src)` check, since the `axes(dst) == axes(src)` is already documented. 07 May 2024, 20:49:15 UTC
dbf0bab Keno Fischer 07 May 2024, 17:01:49 UTC interpreter: Use world-age-partitioned cache for @generated results (#54362) This fixes #54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here. 07 May 2024, 17:01:49 UTC
c77671a Jishnu Bhattacharya 07 May 2024, 16:19:44 UTC LinearAlgebra: improve type-inference in Symmetric/Hermitian matmul (#54303) 07 May 2024, 16:19:44 UTC
54dc748 Kristoffer Carlsson 07 May 2024, 14:15:42 UTC Revert "Move profiling manual section to a new tutorials toplevel heading (#52056)" (#54374) This reverts commit 137783f1663ae0f7c1129c7d8031c874083b49fe. I think there are many problems with the new Tutorial toplevel section: - It should be very important since it adds a full new toplevel section (to the existing five). However, it basically does not contain anything. It was created by a somewhat arbitrary move of a manual-entry to the tutorial section as well as a single page that more or less only contains an external link. - There is a non-obvious overlap between the Manual entries and the Tutorial entries. The profiling entry was moved to tutorials but you could take more or less any other entry in the manual entry and move it as well. - The comment in https://github.com/JuliaLang/julia/pull/52056#pullrequestreview-1721618599 says > We need a proper place for tutorials so tutorial-like PRs don't get rejected and so that people can write actual tutorials content with the correct audience in mind While this might be true I don't think it is obvious at all that the manual needs to be the place where people can "dump" general tutorials about things. Right now, the Tutorial-section has more or less "unbounded scope" and it isn't clear at all what should go in there. - It has been there for 7 months without any real activity (except taking a (again somewhat arbitrary) piece of the Pkg documentation into it) so it seems it isn't really used for anything. Considering all of the above, I think it is best to go back to the status quo of 1.10 instead of "locking this in" for 1.11. 07 May 2024, 14:15:42 UTC
70b7442 Cody Tapscott 07 May 2024, 14:14:58 UTC fix handling of `nothing` in init_load_path (#54382) As-written, this was checking for `nothing` after the `String` convert, which will obviously throw a MethodError. --------- Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com> 07 May 2024, 14:14:58 UTC
d9fecf1 Cody Tapscott 07 May 2024, 14:13:55 UTC handle `nothing` result for `JULIA_VERBOSE_LINKING` (#54383) As written, this function would error if the environment variable has ambiguous "truthiness". 07 May 2024, 14:13:55 UTC
1614e11 Timothy 07 May 2024, 10:25:01 UTC Styled markdown, with a few tweaks (#51928) With `StyledStrings` and `JuliaSyntaxHighlighting` we can make the rendering of `Markdown.MD`: - prettier - customisable - more composable Let's do so! 07 May 2024, 10:25:01 UTC
a267cec Cody Tapscott 07 May 2024, 09:45:57 UTC unicode: specialize `utf8proc_map` sufficiently (#54385) This specialization is more consistent with the callees of this function, which are specialized on the type / identity of this transform function. This cleans up an unnecessary dynamic dispatch in this code. Co-authored-by: gbaraldi <baraldigabriel@gmail.com> 07 May 2024, 09:45:57 UTC
d2399e6 Jishnu Bhattacharya 07 May 2024, 09:08:25 UTC Assume `:foldable` in `isuppercase`/`islowercase` for `Char` (#54346) With this, `isuppercase`/`islowercase` are evaluated at compile-time for `Char` arguments: ```julia julia> @code_typed (() -> isuppercase('A'))() CodeInfo( 1 ─ return true ) => Bool julia> @code_typed (() -> islowercase('A'))() CodeInfo( 1 ─ return false ) => Bool ``` This would be useful in https://github.com/JuliaLang/julia/pull/54303, where the case of the character indicates which triangular half of a matrix is filled, and may be constant-propagated downstream. --------- Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com> 07 May 2024, 09:08:25 UTC
99bda02 Cody Tapscott 07 May 2024, 04:31:27 UTC improve inference of `CPU_THREADS` in `Sys.__init__` (#54384) Without this change, the compiler fails to notice that `env_threads isa Int` in the fall-through case, leading to a union-split with a branch that is in fact unreachable: ``` 43 ┄ %109 = φ (#41 => %105, #42 => %108)::Union{Nothing, Int64} │ %110 = (%109 isa Int64)::Bool └─── goto #45 if not %110 ... 45 ─ %126 = π (%109, Nothing) │ Base.convert(Int64, %126)::Union{} └─── unreachable ``` After this change, the union-split is eliminated. Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> 07 May 2024, 04:31:27 UTC
e47fedd N5N3 07 May 2024, 03:26:34 UTC typeintersect: fix another stack overflow caused by circular constraints (#54363) The added MWE has been broken since 1.8. The intersect result still looks quite unsoundness, but at least stack overflow get fixed. close #54356 07 May 2024, 03:26:34 UTC
0d1d4ba Steven G. Johnson 06 May 2024, 21:04:34 UTC clarify tip about untyped globals: const globals need no annotation (#54379) The performance tip from #43671 by @simeonschaub > If a global is known to always be of the same type, [the type should be annotated](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#man-typed-globals). was a bit unclear to me, because it does not apply to `const` globals (whose type requires no annotation). This PR clarifies that point 06 May 2024, 21:04:34 UTC
1221160 Ian Butterworth 06 May 2024, 17:03:10 UTC REPL: fix hinting without expanding user (#54311) Fixes https://github.com/JuliaLang/julia/issues/53884 Hints will show without expanding `~`, then a tab will complete the shown hint, then a second tab on the resulting valid path expands `~`. I think it makes sense? https://github.com/JuliaLang/julia/assets/1694067/05a4fa97-2a85-4f90-8591-162256cf0704 06 May 2024, 17:03:10 UTC
f3561ae Miles Cranmer 06 May 2024, 09:14:32 UTC Add latex mappings for subscript `<` and `>` (#52980) Adds new latex mappings `\_<` => `˱` and similar for `>` to complement the existing `\_=`, `\_+`, `\_-`. Useful for describing set indices in a variable name like `x˱ᵢ`. 06 May 2024, 09:14:32 UTC
800f67a Diogo Netto 06 May 2024, 04:33:08 UTC add test case to check live_bytes doesn't grow arbitrarily on String(::Array{UInt8})) (#54371) Follow-up to https://github.com/JuliaLang/julia/pull/54331. 06 May 2024, 04:33:08 UTC
92ccc74 Diogo Netto 06 May 2024, 00:36:09 UTC correctly track freed bytes in jl_genericmemory_to_string (#54331) Master version of https://github.com/JuliaLang/julia/pull/54309. Should fix https://github.com/JuliaLang/julia/issues/54275. --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> 06 May 2024, 00:36:09 UTC
9d8e0e7 Alexis Montoison 05 May 2024, 14:40:17 UTC [LBT] Upgrade to v5.9.0 (#54361) 05 May 2024, 14:40:17 UTC
2cf469d Keno Fischer 05 May 2024, 01:26:31 UTC A better mechanism for coordinating internal breaking changes. (#53849) This was origiginally supposed to be an issue, but I just started writing out the whole code in the issue text to explain what I want all the behavior to be, so instead, here's the actual implementation of it, with the motativation in the commit message, and the details of the actual behavior in the code change ;) Sometimes packages rely on Julia internals. This is in general discouraged, but of course for some packages, there isn't really any other option. If your packages needs to hook the julia internals in a deep way or is specifically about introspecting the way that julia itself works, then some amount of reliance on internals is inevitable. In general, we're happy to let people touch the internals, as long as they (and their users) are aware that things will break and it's on them to fix things. That said, I think we've been a little bit too *caveat emptor* on this entire business. There's a number of really key packages that rely on internals (I'm thinking in particular of Revise, Cthulhu and its dependency stacks) that if they're broken, it's really hard to even develop julia itself. In particular, these packages have been broken on Julia master for a more than a week now (following #52415) and there has been much frustration. I think one of the biggest issues is that we're generally relying on `VERSION` checks for these kinds of things. This isn't really a problem when updating a package between released major versions, but for closely coupled packages like the above you run into two problems: 1. Since the VERSION number of a package is not known ahead of time, some breaking changes cannot be made atomically, i.e. we need to merge the base PR (which bumps people's nightly) in order to get the version number, which we then need to plug into the various PRs in all the various packages. If something goes wrong in this process (as it did this time), there can be extended breakage. 2. The VERSION based comparison can be wrong if you're on an older PR (that's a head of the base branch, but with different commits). As a result, when working on base PRs, you not infrequently run into a situation, where you get a VERSION false-positive from updating a package, introducing errors you didn't see before. This one isn't usually that terrible, because a rebase will fix it (and you'll probably need to rebase anyway), but it can be very confusing to get new and unexpected errors from random packages. I would propose that going forward, we strongly discourage closely coupled packages from using `VERSION` comparisons and intead: 1. Where possible, probe for the feature or method signature that they're actually looking for, if it's something small (e.g. a rename of base type). 2. That we as julia base establish a mechanism for probing whether your current pre-release julia has a certain change. My sketch proposal is in this PR. 05 May 2024, 01:26:31 UTC
da6892f DilumAluthgeBot 04 May 2024, 02:54:17 UTC 🤖 [master] Bump the Pkg stdlib from a0851bcfd to ed7a8dca8 (#54352) Stdlib: Pkg URL: https://github.com/JuliaLang/Pkg.jl.git Stdlib branch: master Julia branch: master Old commit: a0851bcfd New commit: ed7a8dca8 Julia version: 1.12.0-DEV Pkg version: 1.12.0 Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: https://github.com/JuliaLang/Pkg.jl/compare/a0851bcfd73aad084fe7b05919c8e6cfc5c1b7a4...ed7a8dca87fa58d80053abf68fb7dfefa54d554e ``` $ git log --oneline a0851bcfd..ed7a8dca8 ed7a8dca8 add note about `activate -` to command help (#3888) c26ad23e9 Use `Base.format_bytes` (#3763) c59b37ffd add hint kwarg to complete_line (#3886) ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com> 04 May 2024, 02:54:17 UTC
5c549a1 Kristoffer Carlsson 04 May 2024, 01:14:37 UTC add a precompile signature to Artifacts code that is used by JLLs (#54350) ``` # before julia> @time using GR_jll 0.202372 seconds (421.29 k allocations: 23.172 MiB, 4.93% gc time, 37.90% compilation time: 2% of which was recompilation) # after julia> @time using GR_jll 0.176863 seconds (151.62 k allocations: 9.064 MiB, 6.16% gc time, 4.11% compilation time: 29% of which was recompilation)'' ``` 04 May 2024, 01:14:37 UTC
9d59ecc Gabriel Baraldi 03 May 2024, 17:04:24 UTC When accessing the data pointer for an array, first decay it to a Derived Pointer (#54335) Fixes https://github.com/JuliaLang/julia/issues/54266, I've not yet minimized something to put into a test but in any case we can add the large test since it executes quite quickly. This also enables IR verification with `Strong=true` when building with assertions, this would've caught this bug much earlier. 03 May 2024, 17:04:24 UTC
2d87ce3 Yi Lin 03 May 2024, 03:37:49 UTC Pass CLANGSA_CXXFLAGS to clangsa tests (#54337) `CLANGSA_CXXFLAGS` are defined in `Make.inc`, https://github.com/JuliaLang/julia/blob/f712512a1159771d9a61e1a768e1a8b297a493c8/Make.inc#L1501 and it is included in the Makefile for clangsa tests. https://github.com/JuliaLang/julia/blob/f712512a1159771d9a61e1a768e1a8b297a493c8/test/clangsa/Makefile#L4 But it does not get passed to clangsa tests properly. This PR fixes this. 03 May 2024, 03:37:49 UTC
cad6d1d Keno Fischer 03 May 2024, 03:37:30 UTC show: Fix non-stacktrace show of toplevel MethodInstance (#54338) While we're here, also check before accessing the `uninferred` field. Top-level MethodInstances should always have this, but the system doesn't enforce this and it's rude for a `show` method to throw on corrupted data (since that's what people use to debug that). 03 May 2024, 03:37:30 UTC
2e1fc88 Keno Fischer 03 May 2024, 03:33:11 UTC Allow optimized OC in :new_opaque_closure (#54329) This isn't officially supported, but some packages are currently using the pattern of creating an optimized opaque closure, pulling out its method and then using that in `:new_opaque_closure` to change the environment. This stopped working properly when I changed optimized ocs to not have a ->source field in the method. Let's keep this working for now, but I'd like to provide a more first class mechanism for these kinds of use cases in the near future. 03 May 2024, 03:33:11 UTC
f712512 Jishnu Bhattacharya 02 May 2024, 16:40:59 UTC Assume :nothrow in iterating over tuples (#54330) On master, ```julia julia> Base.infer_effects(iterate, (Tuple{Int,Int,Int}, Int)) (+c,+e,!n,+t,+s,+m,+u) ``` Since the indexing is only carried out for valid indices, it should be safe to mark this as `nothrow`. After this PR, ```julia julia> Base.infer_effects(iterate, (Tuple{Int,Int,Int}, Int)) (+c,+e,+n,+t,+s,+m,+u) ``` --------- Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com> 02 May 2024, 16:40:59 UTC
b385b4f Kristoffer Carlsson 02 May 2024, 15:12:52 UTC prevent `package_callbacks` to run multiple time for a single package (#54243) Introduced in https://github.com/JuliaLang/julia/pull/52841. 02 May 2024, 15:12:52 UTC
ada49c3 TEC 30 April 2024, 15:26:36 UTC Bump StyledStrings In the course of the markdown PR, an issue with the use of deepcopy in StyledStrings was revealed. This has now been fixed, and to obtain the fix StyledStrings is bumped. 02 May 2024, 10:24:01 UTC
f2e1155 TEC 10 April 2024, 18:20:09 UTC Specially render "styled" Markdown code blocks Since we're already using StyledStrings for rendering Julia in the terminal, we can also handle "styled"-labelled code blocks fancily, thanks to the `styled` function provided by StyledStrings. In all non-terminal contexts, the styling metadata is simply discarded, but could be used in the future (for instance StyledStrings currently supports HTML output too). 02 May 2024, 10:24:01 UTC
80dbf1e TEC 10 April 2024, 18:11:09 UTC Synchronise Markdown rendering to RST with term It seems to make sense not to treat everything other than "rst" as Julia. We may as well follow the same heuristics as the terminal rendering for consistency. 02 May 2024, 10:24:01 UTC
d998d7c TEC 31 October 2023, 10:03:54 UTC Variable spacing markdown list rendering The spacing between list items might as well represent whether the list is a tight or loose list. 02 May 2024, 10:24:01 UTC
337630b TEC 29 October 2023, 04:48:40 UTC Reimplement Markdown printing using StyledStrings Using StyledStrings for styled printing has a number of benefits, including but not limited to: - Italics "just working" on terminals that announce support - Functioning links, for the first time - Greater compossibility of rendered markdown content - Customisability of the printing style Then with JuliaSyntaxHighlighting, we get support for syntax-highlighted Julia code too. 02 May 2024, 10:24:01 UTC
c04d40d TEC 29 October 2023, 04:47:26 UTC Introduce MarkdownElement abstract type It's convenient for dispatch. 02 May 2024, 10:24:01 UTC
e637be1 DilumAluthgeBot 02 May 2024, 10:22:21 UTC 🤖 [master] Bump the Pkg stdlib from 8f772ffa7 to a0851bcfd (#54316) Stdlib: Pkg URL: https://github.com/JuliaLang/Pkg.jl.git Stdlib branch: master Julia branch: master Old commit: 8f772ffa7 New commit: a0851bcfd Julia version: 1.12.0-DEV Pkg version: 1.12.0 Bump invoked by: @KristofferC Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: https://github.com/JuliaLang/Pkg.jl/compare/8f772ffa72d86c81f03cddce2e779d6b330414e3...a0851bcfd73aad084fe7b05919c8e6cfc5c1b7a4 ``` $ git log --oneline 8f772ffa7..a0851bcfd a0851bcfd Relax overly-specific manifest tests (#3884) 299b77093 guard against isdir EACESS in completions (#3877) b9c39a7be Merge pull request #3883 from JuliaLang/kc/resolve_tree_hash 8ab562f72 instantiate the test environment if it is in the current workspace when testing 1d961c1c9 get the correct manifest file for a workspace e468facb5 allow `resolve` to download packages that have been deleted from disk but has a manifest entry 20ceec9b8 do not precompile full env on `using` callback from REPL (#3876) 195e17e3f Replace UnstableIO with IOContext{IO} (#3735) 00aa38cb3 add missing `**5.**` (#3870) ac5672dad Revert "Move "Creating Packages" to Julia docs" (#3818) ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com> 02 May 2024, 10:22:21 UTC
5dcd509 Timothy 02 May 2024, 09:39:37 UTC Add specialised AnnotatedString pipe read/writes (#53715) Ensure that when an AnnotatedIOBuffer is wrapped in an IOContext (or similar AnnotatedPipe-based construct), that writes of annotated strings/chars and reading out an AnnotatedString is unimpeded by the IOContext wrapping. Without these specialisations, the generic pipe_reader/pipe_writer fallbacks will directly access the underlying IOBuffer and annotations will be lost. There are a number of scenarios in which one might want to combine an AnnotatedIOBuffer and IOContext (for example setting the compact property). Losing annotations in such scenarios is highly undesirable. It is of particular note that this can arise in situations where you can't unwrap the IOContext as needed, for example when passing IO to a function you do not control (which is currently extremely hard to work around). Getting this right is a little difficult, and a few approaches have been tried. Initially, I added IOContext{AnnotatedIOBuffer} specialisations to show.jl, but arguably it's a bit of a code smell to specialise in this way (and Jameson wasn't happy with it, with concerns that it could be tricked by IOContext{Any}). # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::IOContext{AnnotatedIOBuffer}, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(io.io, s) write(io::AnnotatedIOBuffer, c::AnnotatedChar) = write(io.io, c) Then I tried making it so that IOContext writes dispatched on the wrapped IO type, but of course that broke cases like IOContext{IOBuffer} with :color=>true. # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::AbstractPipe, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(pipe_writer(io), s) write(io::AbstractPipe, c::AnnotatedChar) = write(pipe_writer(io), c) Finally, we have the current AbstractPipe + Annotated type specialisation, which IOContext is just an instance of. To avoid behaving too broadly, we need to confirm that the underlying IO is actually an AnnotatedIOBuffer. I'm still not happy with this, only idea I've had other than implementing IOContext{AnnotatedIOBuffer} methods that actually seems viable, and I've had trouble soliciting help from other people brainstorming here. If somebody can implement something cleaner here in the future, I'd be thrilled. 02 May 2024, 09:39:37 UTC
185f058 Timothy 02 May 2024, 09:38:40 UTC Specialised substring equality for annotated strs (#54302) The least-bad idea I've had so far for fixing #53042. I figure this fixes the bug raised there, and we can always switch to a clearly-better solution if one appears. The fact that only a string without annotations is equal to a non-annotated string (in order to preserve the transitivity of equality), makes the generic fallback methods for string comparison insufficient. As such, ==(::AnnoatedString, ::AbstractString) is implemented in annotated.jl, but this issue re-appears when dealing with substrings. The obvious solution is to just implement a specialised method for substrings. This does seem potentially a bit whack-a-mole, but I'm worried that cleverer solutions might come with subtle issues of their own. For now, let's try the simple and obvious solution, and improve it later if we can work out a nicer way of handling this issue in general. 02 May 2024, 09:38:40 UTC
c0ce76c Shuhei Kadowaki 02 May 2024, 09:12:03 UTC improve effects of `factorial` (#54320) 02 May 2024, 09:12:03 UTC
685f527 Jishnu Bhattacharya 02 May 2024, 08:33:12 UTC LinearAlgebra: Type-stability in broadcasting numbers over Bidiagonal (#54067) This makes the following type-stable: ```julia julia> B = Bidiagonal(rand(3), rand(2), :U); julia> @inferred (B -> B .* 2)(B) 3×3 Bidiagonal{Float64, Vector{Float64}}: 0.3929 1.93165 ⋅ ⋅ 1.61301 1.00202 ⋅ ⋅ 1.96483 ``` Similarly, for other operations involving a single `Bidiagonal` and numbers. This is not type-stable on master, as the number of `Bidiagonal` matrices in a broadcast operation is not tracked (even though this is used in promoting the `uplo`). Since the `uplo` can't be constant-propagated, we count this by introducing an additional flag in the promotion mechanism, which is entirely determined by the types of the terms in the broadcast operation. --------- Co-authored-by: N5N3 <2642243996@qq.com> 02 May 2024, 08:33:12 UTC
c88f4e2 Sacha Verweij 02 May 2024, 04:02:31 UTC Pass CodeGenOpt::Less to LLVM at O1 (rather than CodeGenOpt::None). (#37893) For context, please see https://github.com/JuliaLang/julia/pull/35086#issuecomment-700944522. Regarding alignment with clang, please see https://reviews.llvm.org/D28409 (/https://github.com/JuliaLang/julia/pull/35086#issuecomment-598282810). ``` Prior to Julia 1.5, Julia passed CodeGenOpt::Aggressive to LLVM at -O1. As of Julia 1.5, Julia passes CodeGenOpt::None to LLVM at -O1. This reduction in optimization effort at -O1 improved compilation latency, but induced appreciable runtime regressions. This commit makes Julia pass CodeGenOpt::Less to LLVM at -O1, mitigating the runtime regressions caused by CodeGenOpt::None, while retaining most of CodeGenOpt::None's latency improvements. This commit also aligns Julia's CodeGenOpt selection at -O1 with that of clang. ``` Best! :) 02 May 2024, 04:02:31 UTC
0f77de4 Klaus Crusius 02 May 2024, 00:54:41 UTC mpfr_overflow_typo (#54284) That looks like an editing error. 02 May 2024, 00:54:41 UTC
57b9b59 Jeff Bezanson 01 May 2024, 18:51:21 UTC update --strip-metadata for new debug format (#53969) 01 May 2024, 18:51:21 UTC
018b066 DilumAluthgeBot 01 May 2024, 14:39:21 UTC 🤖 [master] Bump the NetworkOptions stdlib from aab83e5 to 8eec5cb (#54064) Stdlib: NetworkOptions URL: https://github.com/JuliaLang/NetworkOptions.jl.git Stdlib branch: master Julia branch: master Old commit: aab83e5 New commit: 8eec5cb Julia version: 1.12.0-DEV NetworkOptions version: 1.2.0(Does not match) Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: https://github.com/JuliaLang/NetworkOptions.jl/compare/aab83e5dd900c874826d430e25158dff43559d78...8eec5cb0acec4591e6db3c017f7499426cd8e352 ``` $ git log --oneline aab83e5..8eec5cb 8eec5cb Hardcode doc edit backlink (#32) 0bd3345 also reset SYSTEM_CA_ROOTS and ENV_HOST_PATTERN_CACHE from __init__ (#35) ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com> 01 May 2024, 14:39:21 UTC
1959349 Sergio Sánchez Ramírez 01 May 2024, 14:07:10 UTC Bump LLVM to v17 (#53070) Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com> Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com> Co-authored-by: Zentrik <Zentrik@users.noreply.github.com> 01 May 2024, 14:07:10 UTC
e25ce08 James Wrigley 01 May 2024, 12:31:59 UTC Make Base.shell_escape() and Base.shell_split() public (#53510) `Base.shell_escape()` is particularly useful since it's the only way (AFAICT) to properly convert a `Cmd` to a string. 01 May 2024, 12:31:59 UTC
fe554b7 Timothy 30 April 2024, 15:14:48 UTC Rework annotation ordering/optimisations (#54289) Improvements to the consistency and semantics of AnnotatedStrings, mainly around the ordering of annotations. 30 April 2024, 15:14:48 UTC
831ebe0 Danilo Numeroso 30 April 2024, 12:29:04 UTC Allow rank computation for QRPivoted matrices (#54283) 30 April 2024, 12:29:04 UTC
4c18472 TEC 29 April 2024, 15:33:23 UTC Document the semantics of annotation ordering It's important to specify the way that annotations relate to the characters of the underlying string and each other. Along the way, it's also worth explaining the behaviour of the internal functions _clear_annotations_in_region! and _insert_annotations!. 30 April 2024, 11:15:11 UTC
5c6245e TEC 27 April 2024, 10:35:01 UTC Make _insert_annotations! optimising This is a rather important optimisation, since it prevents the annotation blow-up that can result from say writing to an AnnotatedIOBuffer char-by-char. Originally I was just going to pass the AnnotatedString produced when reading the AnnotatedIOBuffer through annotatedstring_optimize!, but now that's been removed, this seems like the best past forwards (it's also actually a better approach than applying annotatedstring_optimize!, just hard to justify when that code already existed). 30 April 2024, 11:15:11 UTC
84bde3f TEC 27 April 2024, 10:23:32 UTC Remove strong ordering of annotation ranges After a long chat with Lilith Halfner, we've come to the conclusion that the range-based ordering applied to annotations, while nice for making some otherwise O(n) code O(log n) and O(n^2) code O(n), is actually assuming too much about how annotations are used and interact with each other. Removing all assumptions about ordering, and giving annotation order primacy seems like the most sensible thing to do, even if it makes a few bits of the code less algorithmically "nice". As a consequence, we also get rid of annotatedstring_optimize!. Specific producers/consumers of annotated text will know what assumptions can be made to compress/optimise the annotations used, and are thus best suited to do so themselves. The one exception to this is probably when writing to an AnnotatedIOBuffer, here adding a specific optimisation to _insert_annotations! probably makes sense, and will be explored soon. 30 April 2024, 11:14:59 UTC
a294d3d TEC 28 April 2024, 04:33:02 UTC Bump StyledStrings This is in preparation for changes to the way annotation ordering is handled in Base. 30 April 2024, 11:13:34 UTC
cc26f4a Timothy 30 April 2024, 11:03:38 UTC Implement eval-able AnnotatedString 2-arg show (#54308) The generic/fallback AbstractString 2-arg show omits the annotations, meaning that eval(Meta.parse(repr(::AnnotatedString))) doesn't round-trip. The resolution to this is fairly simple, we just need to implement a specialised show method. The implementation is fairly obvious, we're just also able to get away with hiding the vector type annotation since the constructor is fine without it. 30 April 2024, 11:03:38 UTC
69036e1 Shuhei Kadowaki 30 April 2024, 04:54:55 UTC inference: don't taint `:consistent` on use of undefined `isbitstype`-fields (#54136) After #52169, there is no need to taint `:consistent`-cy on accessing undefined `isbitstype` field since the value of the fields is freezed and thus never transmute across multiple uses. 30 April 2024, 04:54:55 UTC
578a8f1 Keno Fischer 30 April 2024, 00:39:15 UTC ir: Add IR_FLAG_UNUSED (#54300) Set on statements whose result is unused. Allows irinterp to skip some type processing on these and eagerly delete statements that become refined to be dead without requiring a subsequent compaction. 30 April 2024, 00:39:15 UTC
3c985f1 Keno Fischer 30 April 2024, 00:39:01 UTC IncrementalCompact: Don't corrupt CFG when finishing early (#54298) Finishing an IncrementalComapact before iterating the whole underlying IRCode is not something that we really do in base, or at least not in places other than a basic block boundary. However, it can be useful for downstream consumers, so make it work anyway. Also create a separate test file for IncrementalCompact tests (of which we really should have more) and move one existing test. 30 April 2024, 00:39:01 UTC
back to top