Last active
July 10, 2026 16:54
-
-
Save Keno/9cf3576cea240898c6a76aadbc743b4f to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # JuliaLang/julia — close candidates from issue triage (2026-07-09) | |
| From the first 1,744 of 3,764 open issues triaged (46%; triage suspended mid-run). 241 issues were classified as close candidates. Each was read in full by a triage agent; where a self-contained repro existed it was executed on julia 1.14-DEV nightly. Nothing has been closed — this list is for human review. | |
| ## Verified fixed — repro re-run on current nightly now behaves correctly (87) | |
| These have runtime evidence: the originally-reported misbehavior no longer occurs on 1.14-DEV. | |
| - [ ] [#18861](https://github.com/JuliaLang/julia/issues/18861) **should @static work with nested conditional statements** (P3, macros, high confidence) | |
| - @static only statically evaluated the first if-condition, leaving elseif branches unevaluated. On nightly @static now recurses into elseif/else chains and prunes non-taken branches statically. Resolved. | |
| - *Evidence:* Ran `macroexpand(Main, :(@static if false; a; elseif true; b; else; c; end))` on 1.14-DEV => `begin b end`, i.e. the elseif condition is evaluated statically and the untaken branches removed. | |
| - [ ] [#23321](https://github.com/JuliaLang/julia/issues/23321) **`sizeof` returns erroneous results for Union arrays** (P3, arrays, medium confidence) | |
| - Original bug: `sizeof` on isbits-Union arrays read wrong memory and returned huge random values (e.g. 1762099360). On nightly the results are now sensible and deterministic (Union{Int,Nothing}[...] -> 80; the covariant Tuple forms both return 32 consistently). The reported memory-corruption bug is fixed. | |
| - *Evidence:* vtjnash 2022 showed nondeterministic 8 vs 32 across sessions; ran on nightly 3x: `sizeof(Vector{Tuple{Union{UInt8,UInt16}}}(undef,4))` == `sizeof(Vector{Union{Tuple{UInt8},Tuple{UInt16}}}(undef,4))` == 32 every time; `sizeof(Union{Int,Nothing}[...len 10])` == 80. | |
| - [ ] [#25744](https://github.com/JuliaLang/julia/issues/25744) **Extending a constructor is possible without explicit `import` or module prefix** (P3, dispatch, medium confidence) | |
| - Type constructors imported via `using X: T` could be extended without explicit import/module-prefix (unlike normal functions), notably the `=>`/Pair case that crashed the REPL. On nightly the acute cases are addressed: extending `Base.=>` now errors, and extending an imported constructor now emits a deprecation warning; full removal is milestone 'Potential 2.0'. | |
| - *Evidence:* Ran on 1.14-DEV: `(a::Int=>b::Int)=...` gives 'function Base.=> must be explicitly imported to be extended'; extending Dates.Date constructor now WARNS 'This behavior is deprecated and may differ in future versions'. LilithHafner 2023: patching the `=>` case alone is acceptable — done. | |
| - [ ] [#26796](https://github.com/JuliaLang/julia/issues/26796) **String search throws an error when finding invalid sequence in valid string** (P3, strings, high confidence) | |
| - findfirst with an invalid-byte needle that would match inside a multibyte char used to throw StringIndexError; it now correctly returns nothing on nightly. Appears fixed. | |
| - *Evidence:* Original: `findfirst("\xa9", "aé")` -> ERROR StringIndexError. Ran on 1.14-DEV: returns `nothing`. | |
| - [ ] [#27101](https://github.com/JuliaLang/julia/issues/27101) **Too big Unions segfault** (P3, types, high confidence) | |
| - Segfault when building/printing/dispatching on a Union of >3265 types (0.7). No longer reproduces on nightly: building and printing a Union of 3266 types works fine. Recommend closing. | |
| - *Evidence:* ran repro on 1.14-DEV: Union of 3266 types built and printed successfully (21760-char string), no segfault. JeffBezanson 2018 linked it to #26065/#25388/#22123/#21191 (large-union subtype work since fixed). | |
| - [ ] [#28384](https://github.com/JuliaLang/julia/issues/28384) **__precompile__(false) does not work** (P3, precompile, high confidence) | |
| - `__precompile__(false)` at top of a package used to error/loop during precompilation. Reported fixed by brenhinkeller in 2022 and confirmed fixed on nightly by me (package loads and precompilation is skipped cleanly). Closing PR #28386 was closed unmerged but the behavior now works. | |
| - *Evidence:* brenhinkeller 2022: '[ Info: Skipping precompilation since __precompile__(false)'; ran the exact NPC repro on 1.14-DEV: 'NPC.foo() = 1' with no error. | |
| - [ ] [#29152](https://github.com/JuliaLang/julia/issues/29152) **bug in MaybeUndef handling pass for PhiC** (P3, compiler:codegen, medium confidence) | |
| - Codegen MaybeUndef/PhiC handling bug caused 'Unreachable reached' crash in a try/finally where the tried function is noreturn. The specific reproducer no longer crashes on nightly (old optimizer IR shown has since been rewritten); vtjnash noted a latent underlying problem may remain but no repro exists. | |
| - *Evidence:* vtjnash 2020: 'We handled the known cases, but think there may still an underlying problem here.' Liozou 2020: 'I can't reproduce on master.' Ran repro on 1.14-DEV: no crash, exception caught cleanly, program survives. | |
| - [ ] [#31730](https://github.com/JuliaLang/julia/issues/31730) **Broadcasting loses constant propagation in cases where the constant saves type stability** (P3, broadcast, high confidence) | |
| - 2019 report that broadcasting loses constant propagation, making getindex.(v,2) ~20x slower than an equivalent loop. On nightly the const-prop/type-stability now works and the broadcast form is actually faster than the loop, so the performance bug is gone. | |
| - *Evidence:* Ran repro on 1.14-DEV: acc (loop) 0.0127s vs acc2 (broadcast) 0.0046s, ratio 0.36 (broadcast faster); original 2019 report showed acc2 ~20x slower with 2M allocations. No longer reproduces. | |
| - [ ] [#32552](https://github.com/JuliaLang/julia/issues/32552) **Function redefinition can improve performance/inlining/inference** (P3, compiler:inference, medium confidence) | |
| - Inference instability where redefining a function fixed inference of a broadcast expression (recursion-limiting heuristics). The minimal reduced reproducer now infers correctly on the first try on nightly, so the reported case appears fixed; recommend closing unless a still-failing case is provided. | |
| - *Evidence:* Ran tkf's reduced repro (g(p)=p[1]=>identity.(p[2]); f()=g.(...)): @inferred FAILS on julia +1.10 ('does not match inferred return type ... <:Tuple{Any,Any}'), but returns OK on 1.14-DEV nightly. Fixed-on-nightly. | |
| - [ ] [#32983](https://github.com/JuliaLang/julia/issues/32983) **Multithreading julia segfaults on exit when a background task is infinite-looping on a thread** (P3, threads, medium confidence) | |
| - Julia 1.3-alpha segfault on process exit when a background Threads.@spawn task is stuck in an allocating infinite loop. Reran the core MWE (spawn allocating infinite loop, sleep, exit) on nightly with 6 threads and it exits cleanly; the old thread-teardown crash appears resolved. | |
| - *Evidence:* Reported on 1.3.0-alpha.32 (2019). Ran the spawn+infinite-loop+exit MWE on 1.14-DEV, JULIA_NUM_THREADS=6: EXIT=0, no segfault. | |
| - [ ] [#33126](https://github.com/JuliaLang/julia/issues/33126) **Constant propagation of in** (P3, compiler:inference, high confidence) | |
| - Type instability from `sym in (:a, :b)` not being constant-folded (constant propagation through a Tuple of Symbols). Verified resolved on nightly: both the minimal case and the getproperty example now infer/fold correctly. | |
| - *Evidence:* ran repro on 1.14-DEV: `test()=in(2,(1,2))` code_typed folds to `return true`; the ThisDoesnt getproperty example infers Body::Float64 (was Union{CantInfer,Float64}). Original diagnosis (yuyichao): 'constant propagation struggles with iterating through a constant Tuple of Symbol.' | |
| - [ ] [#33735](https://github.com/JuliaLang/julia/issues/33735) **Better parsing errors: indicate position with a caret** (P3, parser, medium confidence) | |
| - Request (timholy, 8 reactions) for caret-based positional parse-error diagnostics, which Keno called the biggest usability problem, pointing at FancyDiagnostics.jl and an effort to bring it into base. That effort landed: JuliaSyntax is the base parser since 1.10 and now emits caret diagnostics. Largely obsolete; note the specific '2x = 22' case is a lowering error and still lacks a caret. | |
| - *Evidence:* Keno: 'FancyDiagnostics.jl fixes this ... ongoing effort to bring it into base.' Ran on 1.14-DEV: genuine parse errors show carets (e.g. 'x = 1 +* 2' -> '╙ ── not a unary operator'), confirming JuliaSyntax diagnostics landed. The issue's own example '2x = 22' is a lowering error and still prints no caret. | |
| - [ ] [#34600](https://github.com/JuliaLang/julia/issues/34600) **`SimpleLogger` and `ConsoleLogger` are not thread-safe?** (P3, logging, high confidence) | |
| - Requested thread-safety for SimpleLogger/ConsoleLogger (unguarded message_limits Dict). Current source now guards all access with a ReentrantLock and documents the loggers as thread-safe, so the reported issue is resolved. | |
| - *Evidence:* base/logging/logging.jl and base/logging/ConsoleLogger.jl now contain 'lock::ReentrantLock', '@lock logger.lock' around message_limits access, and docstrings 'This Logger is thread-safe'. | |
| - [ ] [#35172](https://github.com/JuliaLang/julia/issues/35172) **`fatal: error thrown and no exception handler available` when project is passed a path that does not exist** (P3, pkg, high confidence) | |
| - In 1.3.1, `julia --project=<nonexistent path>` aborted with 'fatal: error thrown and no exception handler available' (a systemerror thrown during __init__). vtjnash confirmed it as a known bug in 2020; it is now fixed on nightly. | |
| - *Evidence:* vtjnash: 'This is the same bug I mentioned at #34255... but forgot to make an issue for.' Ran on nightly 2026-07: `julia --project=/tmp/does/not/exist -e 'println(...)'` starts normally, exit 0 — no fatal error. | |
| - [ ] [#35230](https://github.com/JuliaLang/julia/issues/35230) **atexit isn't thread-safe** (P3, threads, high confidence) | |
| - atexit registration from multiple threads raced on the shared hooks array (abort in array_resize_buffer on Julia 1.3.1). Current Base guards registration with a lock, so the reported race is fixed. | |
| - *Evidence:* base/initdefs.jl now: 'const _atexit_hooks_lock = ReentrantLock()' and atexit(f) does '@lock _atexit_hooks_lock begin ... end'. Original report was on 1.3.1. | |
| - [ ] [#35914](https://github.com/JuliaLang/julia/issues/35914) **50% performance regression in map!** (P3, arrays, high confidence) | |
| - Reported ~50% map! regression from Julia 1.0->1.2 (map!((a,b,c)->a+b+c, D,A,B,C) slower than A+B+C), traced to a non-eliding @boundscheck dimension check and O(n) LinearIndices ==. Largely fixed by 1.10 per vtjnash; on current nightly the map! is now clearly faster than the array op, so the regression no longer reproduces. | |
| - *Evidence:* vtjnash 2024-02: 'The problem resolved itself in v1.10'; ran repro on 1.14.0-DEV.2332: test8! map! 1.243 ms vs A+B+C 3.663 ms (map! now faster than in the original 1.0 baseline of 1.817 ms). | |
| - [ ] [#36003](https://github.com/JuliaLang/julia/issues/36003) **expanduser should expand ~ to C:\Users\username on Windows** (P3, filesystem, medium confidence) | |
| - Request that expanduser expand '~/' to the home directory on Windows (old code left it unchanged, citing tilde temp files). The current base/path.jl expanduser now expands an empty-username '~' to homedir() on all platforms (with a Windows separator-normalization branch), so this appears fixed on master; recommend closing after Windows confirmation. | |
| - *Evidence:* Current base/path.jl expanduser: empty username -> home = homedir() unconditionally, plus a `Sys.iswindows()` separator branch; ran on nightly: expanduser("~/.configfile") -> /root/.configfile. Old code that returned path unchanged on Windows is gone. | |
| - [ ] [#36338](https://github.com/JuliaLang/julia/issues/36338) **Test should not strip line numbers** (P3, test, high confidence) | |
| - Reported (Julia 1.3) that @test_throws stripped LineNumberNodes from the wrapped expression, so a macro invoked inside it saw fewer args (BoundsError instead of the intended error). Fixed on current master: @test_throws now wraps ex as Expr(:block, __source__, esc(ex)) without stripping line numbers. | |
| - *Evidence:* Ran repro on nightly and 1.10: length(ex.args)==2 inside @test_throws (same as direct), no BoundsError. Current stdlib/Test/src/Test.jl @test_throws builds `testex = Expr(:block, __source__, esc(ex))` — no line-number stripping. | |
| - [ ] [#36566](https://github.com/JuliaLang/julia/issues/36566) **Cannot juxtapose string literal error for QuotedNode with str macro** (P3, parser, high confidence) | |
| - `:(:A.a"xx")` (quoted symbol before a string-macro dotted name) errored with 'cannot juxtapose string literal' on flisp parser. c42f noted JuliaSyntax already adopts the proposed behavior (fixed by JuliaSyntax integration #46372). Confirmed fixed on nightly. | |
| - *Evidence:* c42f 2023-05: 'JuliaSyntax adopts the proposed behavior already, so this will be fixed by #46372'. Ran on 1.14-DEV nightly: `:(:A.a"xx")` now parses to a macrocall (no error). | |
| - [ ] [#36994](https://github.com/JuliaLang/julia/issues/36994) **Confusing error message when using package without a module** (P3, precompile, high confidence) | |
| - Confusing KeyError/invalid-cache-header error when a package file defines no module. This has been fixed: nightly now emits a clear message. Recommend closing. | |
| - *Evidence:* ran repro (package src file with only `print("Hello World!")`) on nightly: now errors with 'package `TestPkgNM` did not define the expected module `TestPkgNM`, check for typos in package module name' via Base.check_package_module_loaded_error (loading.jl:3330), instead of the old KeyError. | |
| - [ ] [#40267](https://github.com/JuliaLang/julia/issues/40267) **Multiarg `eachindex` slower on 1.6** (P3, compiler:optimizer, medium confidence) | |
| - Multi-arg `eachindex(a,b)` loops were slower than single-arg since 1.6 (bisected to #35982 'skip inferring calls that lead to throw', which introduced a GC frame). Labeled 'fixed on master'; my benchmark on nightly shows f! and g! now essentially equal, confirming it. Only remaining ask is a possible backport to 1.12. | |
| - *Evidence:* Label 'fixed on master'; adienes 2025-05: 'fixed on master (1.13)... potentially could be backported to 1.12'. Ran repro on 1.14-DEV: f! 3.05ms vs g! 3.16ms per 100k iters — parity, no regression. | |
| - [ ] [#40315](https://github.com/JuliaLang/julia/issues/40315) **Conversion from Float64 to Float16 not always rounded to nearest** (P3, math, high confidence) | |
| - Float64->Float16 conversion rounded incorrectly (not round-to-nearest) on Linux x86 in Julia 1.6 due to the C `__truncdfhf2` table-based fallback. Appears fixed on nightly — conversion now rounds correctly. | |
| - *Evidence:* Ran on 1.14-DEV: `convert(Float16,63343.99805)` => 6.333e4 (63328.0), and `== 63328.0` is true (correct round-to-nearest, since 63343.998 < midpoint 63344). | |
| - [ ] [#42051](https://github.com/JuliaLang/julia/issues/42051) **Precompilation error `ArgumentError: Invalid header in cache file ...`** (P3, precompile, high confidence) | |
| - Precompiling a project whose src file doesn't define the project-named module produced a cryptic 'Invalid header in cache file' error. The agreed fix (a clear error message) has since been implemented; nightly now gives an explicit message. | |
| - *Evidence:* martinholters: 'this boils down to giving a better error when trying to precompile a project that is not a package'. Ran the empty-module repro on 1.14-DEV: error is now 'package `Example42051` did not define the expected module `Example42051`, check for typos in package module name' — the cryptic header error is gone. | |
| - [ ] [#42259](https://github.com/JuliaLang/julia/issues/42259) **Possible type instability in Base.reducedim_init** (P3, reduce, medium confidence) | |
| - Reported type instability in Base.reducedim_init (returned Union{Matrix{Float32},Matrix{Float64}} for a Float32 input). On current nightly code_typed of reducedim_init(identity,max,x,1) returns Matrix{Float32}, so the reported instability no longer reproduces. | |
| - *Evidence:* Ran on nightly: code_typed(Base.reducedim_init,(typeof(identity),typeof(max),Matrix{Float32},Int)) => Matrix{Float32} (was Union{Matrix{Float32},Matrix{Float64}} on 1.7-beta4). Related refactor draft #58418 still open but the specific instability is gone. | |
| - [ ] [#43332](https://github.com/JuliaLang/julia/issues/43332) **`Base.runtests(, revise=true)` fails** (P3, test, high confidence) | |
| - Base.runtests(...; revise=true) failed with 'Package Revise not found in current path'. Fixed on nightly: test/runtests.jl now activates a dedicated deps/jlutilities/revise environment (with Revise/JuliaInterpreter/LoweredCodeUtils) and installs it before tracking, implementing the suggested fix. Safe to close. | |
| - *Evidence:* DilumAluthge: 'Someone needs to implement Elliot's suggestion in #42681'. On nightly test/runtests.jl lines 32-46 activate joinpath(@__DIR__,'..','deps','jlutilities','revise') and `using Revise`; deps/jlutilities/revise/Project.toml exists with Revise as a dep. | |
| - [ ] [#44589](https://github.com/JuliaLang/julia/issues/44589) **`@threads` does not work with `JULIA_COPY_STACKS=1`** (P3, threads, medium confidence) | |
| - Reported (2022, 1.9-DEV) that Threads.@threads silently ran only on thread 1 when JULIA_COPY_STACKS=1. On nightly the loop now distributes across multiple threads, so the reported failure no longer reproduces; likely fixed. | |
| - *Evidence:* Ran with JULIA_COPY_STACKS=1, JULIA_NUM_THREADS=4 on nightly: all(isone,a)==false and unique thread ids were [2,5,3,4] (multiple threads wrote), versus the reported all(isone,a)==true. | |
| - [ ] [#45901](https://github.com/JuliaLang/julia/issues/45901) **GC preserve lifetime doesn't wrap include return statements?** (P3, compiler:codegen, high confidence) | |
| - GC.@preserve did not extend lifetime across a `return foo(p)` because llvm-alloc-opt dropped the alloca before the call, causing wrong result (0x00). Fixed by #50277 (chriselrod: 'Closed by #50277'); the 2024 follow-up shows the correct 0x08 result and only raises a theoretical unoptimized-IR concern (missing gc_preserve_end at optimize=false). | |
| - *Evidence:* chriselrod 2023-10: 'Closed by #50277. #48491 was the same issue.'; chriselrod 2024-05 repro shows `stacktest()` => 0x08. Ran on 1.14-DEV: stacktest() returns 8 (correct). | |
| - [ ] [#3374](https://github.com/JuliaLang/julia/issues/3374) **append mode in open() is not posix** (P4, io, high confidence) | |
| - 2013 report that open(...,"a+") was not POSIX/fopen compliant (reads did not start at beginning; file ended up doubled after write). Behavior now matches fopen: append writes go to end without doubling, and reads work after seek. Appears already fixed. | |
| - *Evidence:* brenhinkeller 2022: 'it looks like the current behavior now matches fopen'. Ran repro on 1.14-DEV and 1.10: after write+flush final file size is 26 bytes (not doubled), content correct, seek(0)+read returns full 23 bytes. The original doubling bug no longer reproduces. | |
| - [ ] [#11873](https://github.com/JuliaLang/julia/issues/11873) **Optimize sum(::BitArray, dim)** (P4, arrays, medium confidence) | |
| - 2015 request to optimize sum(::BitArray, dims) which used to enter the generic _mapreducedim! path and be ~3x slower than a manual column loop. On nightly the built-in now matches the manual popcount-based loop, so the reported gap is resolved. | |
| - *Evidence:* KristofferC 2019: 'sum(A;dims=1) we enter the generic _mapreducedim!'. Ran on 1.14-DEV, 10^4x10^4: sum(dims=1)=0.0415s vs manual col=0.0406s (equal); sum(dims=2)=0.064s. Original 3x gap gone. | |
| - [ ] [#14821](https://github.com/JuliaLang/julia/issues/14821) **Document performance problem (and work-around) for arithmetic operations with many arguments** (P4, docs, medium confidence) | |
| - Request to document the old afoldl boxing/allocation performance cliff for chained +/* with many arguments. The threshold has since been raised dramatically; the basic case no longer allocates on nightly, so the documentation request is largely obsolete (only extreme expressions still allocate). | |
| - *Evidence:* KristofferC 2019: 'This doesn't seem to happen anymore from what I can see so closing'; doc PR #15211 was reverted pending the fix; ran on 1.14-DEV: 18-argument sum in a loop => 0 allocations. saschatimme 2019 shows a degree-20 polynomial still allocates, so only extreme cases remain. | |
| - [ ] [#16560](https://github.com/JuliaLang/julia/issues/16560) **different expression trees in macro argument versus other context** (P4, parser, medium confidence) | |
| - Complaint that a macro saw `Expr(:quote)` where the REPL parse produced `QuoteNode` for `:a`. On nightly the macro now also receives a `QuoteNode` for the inner `:a`, so the reported inconsistency is gone; the remaining outer `quote` head is the expected representation of the quoted argument (TotalVerb: 'that is the intended behaviour'). | |
| - *Evidence:* TotalVerb 2016: 'macros only see Expr(:quote), and that is the intended behaviour'. Ran repro on 1.14-DEV: inner `:a` now dumps as QuoteNode inside the macro too, matching the REPL. | |
| - [ ] [#16944](https://github.com/JuliaLang/julia/issues/16944) **Splitting up the Bible is slow** (P4, strings, medium confidence) | |
| - String split of a large text was much slower than Python (originally 2.6s and 8.24M allocations, mostly GC). On nightly this is resolved: split of a comparably large string now runs in ~0.14s with only ~34 allocations, essentially on par with Python (~0.11s). | |
| - *Evidence:* oscardssmith 2020 reopened as still slower, but his own numbers were already close (0.54s vs 0.31/0.47s). Ran on 1.14-DEV: split(big) 0.14s / 34 allocs vs Python 0.11s — allocation blowup and GC cost gone. | |
| - [ ] [#17784](https://github.com/JuliaLang/julia/issues/17784) **Docstrings are misassigned for `(::Type{T}){T}(args...)` constructors** (P4, docs, medium confidence) | |
| - Docstrings for parametric-type constructors written with the old 0.5-era `(::Type{Foo}){T}(...)` syntax were misattributed to `Type`. That syntax has since been removed and modern constructor docs attach correctly to the type. | |
| - *Evidence:* Ran on 1.14-DEV: `"..."; struct Foo{T} end; "Construct..."; Foo(junk::T) where {T}=...; doc(Foo)` shows BOTH the type doc and the constructor doc under `Foo`, not `Type`. Old `(::Type{Foo}){T}` syntax no longer exists. | |
| - [ ] [#18747](https://github.com/JuliaLang/julia/issues/18747) **Generated functions as closures** (P4, compiler:lowering, medium confidence) | |
| - Inner/closure @generated functions gave a confusing 'type DataType has no field x' error. On nightly this now produces a clear lowering error. The deeper feature (allow generated functions to capture variables) was discussed (Jeff: reasonable to capture by value; vtjnash: 'implementation sounds quite annoying') but never committed. The reported bad-error bug is resolved. | |
| - *Evidence:* Ran `function f(x); @generated g()=x; g; end; f(1)()` on 1.14-DEV: now errors 'Global method definition ... needs to be placed at the top level, or use "eval".' (was the confusing DataType error in 2016). | |
| - [ ] [#18840](https://github.com/JuliaLang/julia/issues/18840) **readandwrite deadlock** (P4, io, high confidence) | |
| - readandwrite(`cat -`) deadlocked for large writes because the returned pipes were blocking rather than async. The `readandwrite` function was deprecated and removed years ago (not defined on nightly), and the recommended fix (link_pipe with julia_only flags) has since been incorporated into process setup. Obsolete. | |
| - *Evidence:* Ran `isdefined(Base, :readandwrite)` on 1.14-DEV => false; JeffBezanson's proposed patch to setup_stdio in base/process.jl targets code long since restructured. | |
| - [ ] [#19192](https://github.com/JuliaLang/julia/issues/19192) **fd(::IOStream) return type** (P4, io, high confidence) | |
| - Request that `fd(::IOStream)` return `RawFD` instead of `Int` (like `fd(::Filesystem.File)`). This has since been implemented — the main ask is resolved; only a minor cryptic-naming aside remains. | |
| - *Evidence:* Ran on nightly: `typeof(fd(open(...,"w")))` returns `RawFD`. The requested change has landed, so the issue is obsolete. | |
| - [ ] [#19658](https://github.com/JuliaLang/julia/issues/19658) **RFC: Macro for expression noalias hints** (P4, compiler:optimizer, medium confidence) | |
| - RFC for a noalias/restrict-style annotation to enable vectorization of small loops. The design converged on Keno's 'Option 1' aliasscope+Const approach, which was subsequently implemented as Base.Experimental.@aliasscope and Base.Experimental.Const. Later tangent about freeze/larval objects is a separate topic. | |
| - *Evidence:* Ran on nightly: isdefined(Base.Experimental, Symbol("@aliasscope")) == true and Base.Experimental.Const exists. Keno 2017-01 'Option 1' (@const/aliasscope lowering) matches the shipped @aliasscope; StefanKarpinski/KristofferC endorsed the macro approach. Core ask delivered; RFC otherwise stale since 2018. | |
| - [ ] [#19686](https://github.com/JuliaLang/julia/issues/19686) **depwarn warnings should show location of the problem** (P4, deprecations, high confidence) | |
| - Old (0.4) complaint that depwarn pointed at the top-level call site rather than the actual deprecated call. Modern depwarn captures a backtrace and reports the correct caller location. The specific deprecations cited (bool/int/[a]) are long removed. | |
| - *Evidence:* Ran a @deprecate repro on nightly: warning shows 'caller = do_complex_thing(x::Int64) at dep1.jl:3' and '@ Main /tmp/dep1.jl:3' — the actual calling line, not the top-level call. yuyichao 2016: 'Should not be an issue on 0.5 or master anymore with improved backtrace.' | |
| - [ ] [#20855](https://github.com/JuliaLang/julia/issues/20855) **On 32-bit systems `fill` expects `dims` to always be a `Tuple{Int32}`** (P4, arrays, high confidence) | |
| - fill(v, dims) originally only accepted Tuple{Int32}-shaped dims on 32-bit (rejecting Tuple{Int64} from size of ranges/DateTime StepRanges). Fixed: fill now has method fill(v, dims::NTuple{N,Integer}), so any Integer tuple works. | |
| - *Evidence:* ran on 1.14-DEV: methods(fill) includes 'fill(v, dims::NTuple{N, Integer}) where N @ array.jl:578'; fill(Int64(10),(2,)) and fill(5,(Int128(2),Int128(3))) both work. Matches nalimilan's requested fix (accept any tuple of Integer). | |
| - [ ] [#23033](https://github.com/JuliaLang/julia/issues/23033) **Printing of test errors for @test_warn could be better** (P4, test, medium confidence) | |
| - Complaint (2017, Base.Test era) that @test_warn failure printing exposed an ugly internal transformed expression. On current nightly Test.@test_warn prints a clean, readable failure ('Expression', 'Expected stderr', 'Captured stderr'), so the reported bad output is effectively fixed. | |
| - *Evidence:* Ran on nightly 2026-07: `@test_warn "err" 1+1` prints 'Test Failed ... Expression: 1 + 1 / Expected stderr: "err" (occursin) / Captured stderr: ""' — no longer the raw `(Base.Test.ismatch_warn)(...)` expression from 2017. | |
| - [ ] [#24151](https://github.com/JuliaLang/julia/issues/24151) **x^2 / power_by_squaring broken when type can't be converted.** (P4, math, medium confidence) | |
| - Complaint that power_by_squaring/to_power_type forced a needless conversion of the input to the output type, breaking x^2 for types where the conversion is undefined. power_by_squaring has since been rewritten (to_power_type is gone; it now derives T from typeof(x*x) and only promotes for Number), and a Number-subtype reproducer works on nightly; the remaining non-Number case gives a clean MethodError. | |
| - *Evidence:* TotalVerb 2017: 'The algorithm should be changed nevertheless to avoid doing the needless conversion.' Ran on nightly 1.14-DEV: with `struct ImaginaryNumber <: Number` and `*` defined, `ImaginaryNumber(1)^2` returns -1.0 (no conversion error). base/intfuncs.jl power_by_squaring now uses x_squared_type instead of to_power_type. | |
| - [ ] [#24814](https://github.com/JuliaLang/julia/issues/24814) **at(dt::DateTime, t::Time) and at(d::Date, t::Time)** (P4, dates, medium confidence) | |
| - Requests an at(dt/d, ::Time) helper plus easier DateTime construction from Date+Time. The secondary complaint is resolved: DateTime(::Date, ::Time) now exists and works on nightly. The remaining 'at' function is an unendorsed naming feature now largely redundant with DateTime(Date(d), t). | |
| - *Evidence:* Ran on nightly: DateTime(Date(2010,1,3), Time(13,30)) => 2010-01-03T13:30:00; method DateTime(dt::Date, t::Time) exists in Dates/src/types.jl. No traction on an 'at' function. | |
| - [ ] [#25478](https://github.com/JuliaLang/julia/issues/25478) **make sure string function index bounds are correctly documented** (P4, docs, medium confidence) | |
| - Docs task to precisely document accepted index bounds of thisind/nextind/prevind/reverseind. The 'wide' bounds decision was effectively settled (bkamins landed the cleanup PRs) and the docstrings now spell out the bounds/BoundsError behavior on nightly, so the original task appears substantially completed. | |
| - *Evidence:* bkamins (2018-02): 'We are done with my PRs cleaning up the errors ... they now all work assuming thisind accepts 0 and ncodeunits(s)+1.' Ran on 1.14-DEV: nextind/thisind/prevind docstrings now document ncodeunits(str)+1 bounds and BoundsError cases in detail. | |
| - [ ] [#25487](https://github.com/JuliaLang/julia/issues/25487) **Interpolated output for tests which are `!(expr)`** (P4, test, high confidence) | |
| - Request that @test show interpolated 'Evaluated:' output for negated comparisons like !(a==51). This is now implemented: nightly prints 'Evaluated: !(51 == 51)'. | |
| - *Evidence:* Ran on 1.14-DEV: `@test !(a==51)` prints 'Test Failed ... Expression: !(a == 51) / Evaluated: !(51 == 51)'. Feature requested in body is present. | |
| - [ ] [#25499](https://github.com/JuliaLang/julia/issues/25499) **Base._return_type usages wrong for Type return** (P4, compiler:inference, high confidence) | |
| - Base._return_type usages mishandled functions that return a Type (broadcast(typeof, Float32[]) gave Array{Type{Float32},1}). Fixed on master per gbaraldi and confirmed on nightly (Vector{DataType}). | |
| - *Evidence:* gbaraldi 2023-09: 'We get the correct result in master here at least for the MWE.' Ran on 1.14-DEV: typeof(broadcast(typeof, Float32[])) == Vector{DataType}. | |
| - [ ] [#27881](https://github.com/JuliaLang/julia/issues/27881) **Surprising parsing as `hvcat`** (P4, parser, high confidence) | |
| - Surprising hvcat parse of `[1; 1 .+cumsum(...)]` (unary .+ swallowing the following expression) no longer reproduces on nightly; it now returns the expected 4-element vector [1,2,4,7]. | |
| - *Evidence:* Author dlfivefifty 2018: suggested just closing. Ran repro on 1.14-DEV: `[1; 1 .+cumsum([1,2,3])]` now returns [1,2,4,7] (no DimensionMismatch), i.e. parses as expected. | |
| - [ ] [#28181](https://github.com/JuliaLang/julia/issues/28181) **Broadcast.combine_styles inference failure in 0.7** (P4, compiler:inference, high confidence) | |
| - Inference gave an overly-wide (Any/Union) result for Broadcast.combine_styles / method dispatch on Type{<:Foo}; martinholters reduced it to inference losing precision when dispatching on a union of 5+ members with a later more-specific method. Verified fixed on nightly: the reduced repro now infers the correct Val{:ref}. | |
| - *Evidence:* Ran the reduced repro (foo with Union{4} / Union{5} / Ref, bar(x)=foo(typeof(x))) on 1.14.0-DEV: Base.return_types(bar, Tuple{Ref}) == Any[Val{:ref}] (was Union{Val{:union5}, Val{:ref}} in 0.7). | |
| - [ ] [#30310](https://github.com/JuliaLang/julia/issues/30310) **`@deprecate` should support qualified names** (P4, deprecations, medium confidence) | |
| - Request that @deprecate accept qualified names like Base.open(::Mine). On current nightly this works when passing export_old=false; qualified names only fail with the default (export) form, which cannot export a qualified symbol, and the error message now explains this. Largely resolved by the export_old argument. | |
| - *Evidence:* Ran on 1.14-DEV: `@deprecate Base.open(mine::Mine) open(mine::Mine)` errors with a message telling you the first arg must be a bare symbol unless export_old is given; adding `false` third arg succeeds. JeffBezanson 2018: 'I agree this should work.' | |
| - [ ] [#30333](https://github.com/JuliaLang/julia/issues/30333) **Consider inlining `fldmod` to allow optimizing if an arg is a Const** (P4, compiler:optimizer, medium confidence) | |
| - Asked to @inline fldmod (or make inlining heuristics const-prop aware) so a constant divisor can be optimized. Modern Julia fully inlines fldmod and propagates constant arguments; the broader const-prop-aware inlining machinery has since been implemented. Obsolete. | |
| - *Evidence:* Ran `code_typed(x->fldmod(x,10),(Int,))` on 1.14-DEV: fldmod is fully inlined with the constant 10 threaded through the arithmetic (no function barrier), addressing the original request. | |
| - [ ] [#30438](https://github.com/JuliaLang/julia/issues/30438) **Uninformative Broadcast Error Message** (P4, broadcast, high confidence) | |
| - Request for the broadcast DimensionMismatch error to include the offending array sizes. mbauman's suggested 'easy' improvement (include the mismatched dimension lengths) has since been implemented; the message now reports the axes. | |
| - *Evidence:* mbauman 2018-12: 'The easiest improvement would be to simply say ... computed a dimension with lengths $a and $b.' Ran repro on 1.14-DEV: 'DimensionMismatch: arrays could not be broadcast to a common size: a has axes Base.OneTo(3) and b has axes Base.OneTo(2)' — the requested info is now shown. | |
| - [ ] [#30993](https://github.com/JuliaLang/julia/issues/30993) **Lowering error when type parameter name matches a struct binding** (P4, compiler:lowering, high confidence) | |
| - Lowering error 'Foo is a local variable in its enclosing scope' when a type parameter name shadows a preceding struct binding in the same block. Reported resolved on 1.12 and confirmed fixed on nightly — motivating example now lowers to a normal thunk instead of an error expression. Safe to close. | |
| - *Evidence:* BioTurboNick 2025-12: 'Seems like this might be resolved? On 1.12, the motivating example produces the following instead of an error'. Ran repro on 1.14.0-DEV: printed NO_ERROR_OK (Meta.lower returns a thunk, not an :error Expr). | |
| - [ ] [#31363](https://github.com/JuliaLang/julia/issues/31363) **Dateparsing Returning Inconsistent Integer Types** (P4, dates, high confidence) | |
| - On 32-bit systems, parsing month/day names (uUeE) returned system Int (Int32) while other date fields returned Int64. Fixed by PR #31448 which changed DateLocale dicts to Dict{String,Int64}; already merged on master. | |
| - *Evidence:* git log: commit 34fd6f0748 'Force "uUeE" dateformats to return Int64 values (#31448)' changed month_value::Dict{String,Int} -> Dict{String,Int64} in stdlib/Dates/src/query.jl; present in current tree. | |
| - [ ] [#31472](https://github.com/JuliaLang/julia/issues/31472) **Redundant `:($(...))` in expression printing** (P4, printing, medium confidence) | |
| - Report that nested quotes printed with redundant `:($(Expr(:quote, ...)))`. On nightly this is fixed: `:(:(:(1+2)))` now prints cleanly as `:(:(1 + 2))`. (esc still shows `$(Expr(:escape, :a))`, a separate minor aside.) Recommend closing as resolved. | |
| - *Evidence:* Ran on 1.14-DEV: `:(:(:(1+2)))` prints `:(:(1 + 2))` (no `$(Expr(:quote,...))` wrapper), matching StefanKarpinski's suggested ideal 'same as the input'. | |
| - [ ] [#32301](https://github.com/JuliaLang/julia/issues/32301) **Macro Inconsistency using Module Qualification** (P4, parser, high confidence) | |
| - Reported inconsistency where `Module.@macro(args) do ... end` failed to parse while `@Module.macro(...) do ... end` worked. Fixed by the JuliaSyntax parser: both forms now parse correctly. | |
| - *Evidence:* Ran the reproducer on 1.14-DEV and 1.10: `FooModule.@foo(a, b, c) do x, y, z; println(1) end` now parses into the expected `FooModule.@foo a b c do ... end` macrocall with no error. | |
| - [ ] [#33428](https://github.com/JuliaLang/julia/issues/33428) **round(x, sigdigits) differs on some systems** (P4, math, medium confidence) | |
| - `round(1e23, sigdigits=1)` reportedly gave platform-dependent results (1.0000000000000001e23 vs 1.0e23) in 2019. The sigdigits rounding was subsequently reworked; it no longer reproduces the spurious value on tested versions and returns a consistent 1.0e23. | |
| - *Evidence:* Ran on 1.14-DEV.2332: round(1e23, sigdigits=1) => 1.0e23; also on 1.10.11 => 1.0e23. Consistent, correct value; the divergent 1.0000000000000001e23 no longer reproduces here. | |
| - [ ] [#33912](https://github.com/JuliaLang/julia/issues/33912) **Repeated sizehint! can leak memory** (P4, arrays, medium confidence) | |
| - Repeated popfirst!/sizehint!/push! grew Vector capacity without bound (219998 on 1.2). The unbounded growth is fixed by the 1.11 GenericMemory rewrite; a minor residual remains (capacity ping-pongs 23538<->10000 each iteration) but the memory leak per the title is resolved. | |
| - *Evidence:* Ran original repro on 1.14-DEV: final capacity=10000 (was 219998). oscardssmith 2025-01: 'This is improved but not yet fixed on 1.11' referring only to per-iteration resize churn; my nightly run shows values oscillate 23538/10000, no unbounded growth. | |
| - [ ] [#34072](https://github.com/JuliaLang/julia/issues/34072) **printing of keywords as symbols** (P4, printing, high confidence) | |
| - Interpolated keyword-symbols like `:(a = $:while)` used to print as invalid `:(a = while)`. On nightly they now print with `var"..."` quoting (`a = var"while"`) and round-trip correctly, so the reported bug is fixed. | |
| - *Evidence:* Ran on 1.14-DEV.2332: `:(a = $:while)` prints `a = var"while"`, `:(a = $:do)` prints `a = var"do"`; `Meta.parse(string(e)) == e` is true. The invalid-output described in the issue no longer occurs. | |
| - [ ] [#34366](https://github.com/JuliaLang/julia/issues/34366) **behavior of `wait` on closed and/or triggered Timers** (P4, io, low confidence) | |
| - Design note by JeffBezanson on inconsistent wait semantics for closed/triggered one-shot Timers: waiting on a timer closed after it triggered used to succeed once (no error). On nightly this now errors (EOFError), matching his proposed fix #1 (wait always errors after explicit close). The reported inconsistency no longer reproduces; likely obsolete though the multi-waiter level-trigger nuance is unverified. | |
| - *Evidence:* Ran on nightly: Timer(.01); close(t); wait(t) now throws EOFError() (previously returned without error), aligning with proposal #1 'Make wait always error after close'. 0 comments, stale since 2020. | |
| - [ ] [#34661](https://github.com/JuliaLang/julia/issues/34661) **`MethodError: no method matching similar(::Type{Array{Float64,N} where N}, ::Tuple{UnitRange{Int32}})`** (P4, broadcast, high confidence) | |
| - MethodError from similar in broadcast over a Dates range on 32-bit (Int32 UnitRange axis) in Julia 1.3.1. Author reported it already gone in 1.4.0-rc1, and it runs cleanly on nightly. | |
| - *Evidence:* omus 2020: 'The error does not occur on Julia 1.4.0-rc1.' Ran repro on 1.14-DEV: works, returns length 366. | |
| - [ ] [#34682](https://github.com/JuliaLang/julia/issues/34682) **`typeinf_code` documentation is wrong?** (P4, docs, high confidence) | |
| - Devdocs inference page had an outdated typeinf_code call signature (extra ::Bool, old Params). The current doc/src/devdocs/inference.md already uses the updated interp-based API, so the documentation is fixed. | |
| - *Evidence:* doc/src/devdocs/inference.md now shows 'interp = Core.Compiler.NativeInterpreter()' and 'Core.Compiler.typeinf_code(interp, m, types, sparams, run_optimizer)', matching the current API. A fix PR was created back in 2020. | |
| - [ ] [#34811](https://github.com/JuliaLang/julia/issues/34811) **Profile incorrectly records functions at line number 0** (P4, profiler, medium confidence) | |
| - Profile attributed samples in `foo` to line 0 of the source file (originally on Windows, Julia 1.3). Reproducer no longer shows a line-0 frame on 1.14-DEV; `foo` is now reported at its real source line. | |
| - *Evidence:* Ran the reproducer on 1.14.0-DEV: output shows only `foo(n::Int64)` at /tmp/prof34811.jl:14 with no line-0 frame; the ':0; foo' entry from the report is gone. No comments/PR on the issue; likely fixed by later profiler/codegen line-info work. | |
| - [ ] [#34976](https://github.com/JuliaLang/julia/issues/34976) **SecretBuffer as stdin in pipeline** (P4, io, high confidence) | |
| - SecretBuffer as stdin in a pipeline used to throw `MethodError: no method matching rawhandle(::Base.SecretBuffer)`. On nightly this now works and data flows correctly, so the reported error is fixed; only a possible docs note remains. Recommend closing (optionally after a docs mention). | |
| - *Evidence:* Ran on 1.14-DEV: `run(pipeline(\`cat\`, stdin=sb))` prints the buffer contents with no error. Original error 'no method matching rawhandle(::Base.SecretBuffer)' no longer occurs. | |
| - [ ] [#36237](https://github.com/JuliaLang/julia/issues/36237) **Can `map!(identity, dest, src)` match performance of `copyto!(dest, src)` ?** (P4, arrays, high confidence) | |
| - 2020 request that map!(identity, dest, src) match copyto! speed (~5-6x slower then). On current Julia map! has been optimized and is now on par with copyto!, so the reported gap no longer reproduces. | |
| - *Evidence:* Ran repro: on 1.14-DEV map!=70.8ns vs copyto!=79.0ns (ratio 0.90); on 1.10.11 map!=96.9ns vs copyto!=96.2ns (ratio 1.01). Original report had map!~450ns vs copyto!~78ns. | |
| - [ ] [#36872](https://github.com/JuliaLang/julia/issues/36872) **Tab-completion for integer propertynames** (P4, repl, medium confidence) | |
| - REPL tab-completion used to error for objects with integer propertynames. Merged PR #36874 removed the Tuple special-casing so it no longer errors; only a marginal enhancement (actually completing to f.:1 syntax) remains, with an xref to #49198. | |
| - *Evidence:* ViralBShah 2022: 'At least not an error anymore.'; PR #36874 MERGED; ran on 1.14-DEV: completions("f.",2) returns empty list with no error. vtjnash xref #49198. | |
| - [ ] [#37350](https://github.com/JuliaLang/julia/issues/37350) **findfirst , findlast and findall differences in needles** (P4, strings, medium confidence) | |
| - findfirst/findlast/findall over AbstractString once supported different needle types. The concrete gaps are now fixed (findall and findlast accept AbstractChar on nightly); the only remaining inconsistency is that findlast/findprev do not accept a Regex, which stevengj explains is an intrinsic PCRE limitation (no reverse search) and declined a forward-search workaround. | |
| - *Evidence:* stevengj 2025-07: 'the lack of AbstractChar in findall has been fixed'; ran on nightly: findlast('l',"hello")==4 and findall('l',"hello")==[3,4] work, findlast(r"l",...) still MethodError. stevengj rejects forward-order reverse regex search. | |
| - [ ] [#37381](https://github.com/JuliaLang/julia/issues/37381) **Clarify error on all-underscore field name that isn't `_`.** (P4, compiler:lowering, medium confidence) | |
| - Issue asked to improve the 'all-underscore identifier used as rvalue' error for an all-underscore struct field name other than `_` (e.g. `__::T`). On current nightly this no longer errors at all — such field names are accepted — so the error-message the issue targets no longer occurs; the request is obsolete. | |
| - *Evidence:* Ran on nightly: `struct B; __::Int; end` defines with NO ERROR (2020 it raised 'all-underscore identifier used as rvalue'). The targeted error message no longer appears. | |
| - [ ] [#37473](https://github.com/JuliaLang/julia/issues/37473) **Unexpected performance difference between two similar loops** (P4, compiler:codegen, medium confidence) | |
| - Counting missings in a Vector{Union{Missing,Int}} was ~3x slower than counting non-missings due to an extra vectorized xor in the LLVM. On current nightly the dramatic gap is essentially gone; the extra work no longer produces a 3x difference. | |
| - *Evidence:* Original report: 252us vs 85us (~3x). Ran on 1.14-DEV.2332: count_missing 45.9us vs count_nonmissing 39.5us (~1.16x) — the 3x regression no longer reproduces. | |
| - [ ] [#37738](https://github.com/JuliaLang/julia/issues/37738) **A rounding bug in Dates module?** (P4, dates, high confidence) | |
| - The reported Dates 'rounding bug' is working-as-intended per the Rounding-Epoch docs. The only follow-up (defining `round(::Time, ::Period)`) was implemented and merged in PR #52629. | |
| - *Evidence:* MarcMush 2020: 'this is working as intended'. TheLostLambda 2023: 'Implemented in this PR! #52629'. Verified PR #52629 MERGED 2024-11-04; ran on nightly: round(Time(1,2,3), Minute) => 01:02:00, round(..., Hour) => 01:00:00. | |
| - [ ] [#38681](https://github.com/JuliaLang/julia/issues/38681) **Syntax error with type parameter and array literal** (P4, parser, medium confidence) | |
| - Whitespace-before-`[` after a type parameter produces a syntax error (garden-path with typed-array-literal parsing). On nightly the first `where {T}` example now parses; the second (genuinely missing `where`) still errors, but the JuliaSyntax parser gives a clear 'whitespace is not allowed here' pointer. Space-before-`[` sensitivity is intentional; effectively working-as-designed. | |
| - *Evidence:* Ran on 1.14-DEV: `function to_array(val::T)::Array{T} where {T} [val] end` now parses (no syntax error); `function to_arr(val::T)::Array{T} [val] end` errors with JuliaSyntax 'whitespace is not allowed here' caret at the space. | |
| - [ ] [#38703](https://github.com/JuliaLang/julia/issues/38703) **close(::GenericIOBuffer) has a bug and is too aggressive in some cases** (P4, io, medium confidence) | |
| - close(::GenericIOBuffer) had dead code (`if io.writable` after setting writable=false) and was reported as too aggressive about resetting size/ptr. The dead-code bug is fixed on nightly (check now precedes the writable=false assignment), and the 'too aggressive close' concern was redirected to Base.BufferStream/SimpleBufferStream by vtjnash/StefanKarpinski. | |
| - *Evidence:* Verified base/iobuffer.jl close() now reads `if io.writable && !io.reinit; _resize!(io, 0, true); end` BEFORE clearing writable, so the original dead-code bug is gone. vtjnash: 'Perhaps you're looking for a Base.BufferStream?' | |
| - [ ] [#38766](https://github.com/JuliaLang/julia/issues/38766) **No parse error for extra tokens after generator inside function call** (P4, parser, high confidence) | |
| - `:(f(x for x in r s))` silently parsed without error (extra tokens after generator inside a call), rather than being a parse error. The new JuliaSyntax parser now rejects this, so the issue is fixed on nightly. | |
| - *Evidence:* simeonschaub 2020-12-08: 'That does seem unintended.' Ran on 1.14-DEV: `:(f(x for x in r s))` now yields `ParseError ... Expected ')' or ','`. | |
| - [ ] [#39450](https://github.com/JuliaLang/julia/issues/39450) **implementation details of kwargs can leak in to the behavior of type-assert** (P4, compiler:lowering, medium confidence) | |
| - kwargs type-assertion (kw::Int...) used to leak into type-assert/dispatch behavior; JeffBezanson/vtjnash agreed it should just be an error for now, and it now is one. On nightly defining `f(;kw::Int...)` throws a syntax error, so the reported leak is fixed. Only leftover is a somewhat non-instructive error message. | |
| - *Evidence:* JeffBezanson 2021: 'this should just be an error for now'. adienes 2025-07: 'since 1.7 this does error, but the error message thrown is pretty non-instructive'. Ran on 1.14-DEV: `f(;kw::Int...)=...` => 'syntax: "kw::Int" is not a valid function argument name'. | |
| - [ ] [#39738](https://github.com/JuliaLang/julia/issues/39738) **Bug in subtyping of Type** (P4, types, high confidence) | |
| - Reported inconsistency where Type === (Type{T} where T) yet the two gave different results against supertype(Union). No longer reproduces on nightly: the comparison is now consistent, so the issue appears resolved. | |
| - *Evidence:* ran repro: 1.10 gives (true, true, false) [reported bug]; 1.14-DEV gives (true, true, true) [consistent]. JeffBezanson had said supertype is 'informational only' and 'I would not worry about this'. | |
| - [ ] [#40113](https://github.com/JuliaLang/julia/issues/40113) **Invalid syntax in ambiguity fix suggestion, duplicate parameter names** (P4, error-messages, medium confidence) | |
| - Method-ambiguity 'Possible fix' suggestion printed invalid syntax `::Union{V{T}, V{T}}` and duplicate `where {T<:Number, ..., T<:Number}` params. On nightly the suggestion now prints `::V{T}` directly with no duplicated type parameters, so the reported defect no longer reproduces. | |
| - *Evidence:* ran on 1.14-DEV: suggestion now reads `dot(::V{T}, ::Union{...} where {Tv, Ti}) where T` — no `Union{V{T},V{T}}`, no duplicate T. vtjnash's note about non-reversible bound printing is a deeper edge case, not the reported case. | |
| - [ ] [#40489](https://github.com/JuliaLang/julia/issues/40489) **`getfield(::Vector, index)` has awkward `BoundsError`** (P4, error-messages, medium confidence) | |
| - The confusing BoundsError from getfield([1,2], 1) is gone: on nightly getfield([1,2],1) returns a MemoryRef rather than throwing. Only an out-of-range getfield still throws a plain BoundsError; the original complaint no longer reproduces. vtjnash already asked 'So, fixed?' with no follow-up. | |
| - *Evidence:* vtjnash 2024-02: 'This no longer throws a BoundsError. So, fixed?'; ran on 1.14-DEV: getfield([1,2],1) => MemoryRef{Int64}(...), getfield([1,2],3) => BoundsError. | |
| - [ ] [#40733](https://github.com/JuliaLang/julia/issues/40733) **specifying testset type by qualified name is an error** (P4, test, high confidence) | |
| - Reported that `@testset Test.DefaultTestSet "foo" begin ... end` errored with 'Unexpected argument' because parse_testset_args only accepted a bare Symbol, not a qualified name. This now works on nightly — the qualified-name testset type is accepted. Appears fixed; recommend closing. | |
| - *Evidence:* Ran repro on 1.14-DEV nightly: `@testset Test.DefaultTestSet "foo" begin @test true end` runs and prints a normal 'Test Summary' with no error. | |
| - [ ] [#41005](https://github.com/JuliaLang/julia/issues/41005) **Test summary table not aligned correctly when a test set has no failures but `verbose=true`** (P4, test, high confidence) | |
| - Report that verbose=true testsets with no failures compute wrong first-column padding in the summary table. The exact suggested fix (adding a !ts.verbose guard) is already present in current master's Test.get_alignment, so this is fixed. | |
| - *Evidence:* Current stdlib/Test/src/Test.jl:1864-1865 reads '# If not verbose and all passing, no need to look at children' then '!ts.verbose && !anynonpass(ts) && return ts_width' — exactly the fix the author proposed. | |
| - [ ] [#41690](https://github.com/JuliaLang/julia/issues/41690) **`ERROR: syntax: ssavalue with no def` from `@opaque`** (P4, compiler:lowering, medium confidence) | |
| - @opaque on a where-parametrized lambda used to emit the internal lowering error 'syntax: ssavalue with no def'. On nightly it no longer produces that crash; it now raises a clean, meaningful error. | |
| - *Evidence:* Ran on nightly: `Base.Experimental.@opaque ((::T) where {T}) -> T(0)` now errors 'OpaqueClosure argument tuple must be a tuple type' (a proper error), not 'ssavalue with no def'. Basic @opaque works. | |
| - [ ] [#41933](https://github.com/JuliaLang/julia/issues/41933) **time_print doesn't accept an IO** (P4, io, high confidence) | |
| - Request to let time_print accept an IO argument for reuse in custom @time macros. JeffBezanson approved and PR #42002 was opened; that PR is closed-unmerged, but the feature is now implemented in base/timing.jl (time_print(io::IO, ...)), so the issue is resolved and can be closed. | |
| - *Evidence:* JeffBezanson 2021: 'Pretty clearly a good idea. PR it?' Current base/timing.jl L254: 'function time_print(io::IO, elapsedtime, ...)' — IO argument now exists. PR #42002 state CLOSED, mergedAt null (superseded by later implementation). | |
| - [ ] [#43253](https://github.com/JuliaLang/julia/issues/43253) **Generic fallbacks for type reflection** (P4, types, high confidence) | |
| - Request for generic fallbacks like isstructtype(x)=false so reflection predicates don't MethodError on non-type values. Already resolved: isstructtype (and friends) now accept arbitrary objects and return false. Safe to close. | |
| - *Evidence:* aviatesk/JeffBezanson noted signature widened; ran on nightly: isstructtype(IdDict{Any,Any}()) => false (no MethodError), isstructtype(nothing)/("x") => false. The 1.7.0 MethodError no longer occurs. | |
| - [ ] [#44109](https://github.com/JuliaLang/julia/issues/44109) **Type instability in broadcast on vector of union?** (P4, broadcast, medium confidence) | |
| - Author asks whether broadcasting over Vector{Union{Missing,Float64}} should infer a single concrete container type instead of a small Union of possible container types. KristofferC replied that narrowing to Vector{Union{Missing,Float64}} would be incorrect (a .+ b can produce Vector{Float64}). The small-Union result is intentional; no bug and no actionable design change. | |
| - *Evidence:* KristofferC 2022-02: 'But that wouldn't be correct?' with example showing a .+ b yields Vector{Float64}. Ran repro on 1.14-DEV: f infers Union{Vector{Missing},Vector{Union{Missing,Float64}},Vector{Float64}} — the intended small-union behavior. | |
| - [ ] [#45520](https://github.com/JuliaLang/julia/issues/45520) **Confusing syntax error with superfluous `,` in an array literal** (P4, error-messages, medium confidence) | |
| - Confusing parser error for `[0, -im; im 0]` (mixed `,` and `;` in an array literal) under the old parser said 'missing comma or ] in argument list'. The JuliaSyntax parser on nightly now gives a precise error pointing at the exact column, substantially resolving the complaint. | |
| - *Evidence:* ran repro on 1.14-DEV: ParseError 'Expected `]` or `,`' with a caret at column 12 pointing precisely at the offending token — much clearer than the old message. | |
| - [ ] [#46229](https://github.com/JuliaLang/julia/issues/46229) **Output problem of BigFloat** (P4, bignums, medium confidence) | |
| - User on CentOS binary reported `BigFloat(2.1)` and `string(big"2.1")` printing as "2.0" while arithmetic showed the correct value, at precision 256. No maintainer could reproduce; likely an environment-specific broken MPFR/locale on that machine. Author stopped responding. | |
| - *Evidence:* inkydragon and others could not reproduce (got full digits). Ran on nightly: BigFloat(2.1) prints 2.100000000000000088817841970012523233890533447265625 correctly. Environment-specific, unreproducible, stale since 2022. | |
| - [ ] [#21534](https://github.com/JuliaLang/julia/issues/21534) **`Base.Broadcast.promote_containertype` improvements** (P5, broadcast, high confidence) | |
| - Request to reduce boilerplate for adding broadcast container types via promote_containertype/promote_rule-style machinery. Obsolete: the entire promote_containertype system was replaced by the BroadcastStyle design in Julia 0.7/1.0. | |
| - *Evidence:* Ran on 1.14-DEV: isdefined(Base.Broadcast, :promote_containertype) == false. Broadcast was fully redesigned (BroadcastStyle) after this 2017 issue. | |
| - [ ] [#21828](https://github.com/JuliaLang/julia/issues/21828) **record-function for an AbstractTestSet does not capture all test-macros** (P5, test, medium confidence) | |
| - Custom AbstractTestSet record() didn't capture @test_approx_eq, @test_approx_eq_eps, and @inferred. Largely obsolete: @test_approx_eq/@test_approx_eq_eps were deprecated and removed in 0.7/1.0; @inferred not recording is by design. Remaining points (Broken/Skip/Error type semantics) are minor design opinions TotalVerb explained. | |
| - *Evidence:* Ran on 1.14-DEV: @test_approx_eq is undefined (UndefVarError) — those macros were removed. TotalVerb explained skip==Broken rationale. No core action since 2017. | |
| - [ ] [#29450](https://github.com/JuliaLang/julia/issues/29450) **@test_logs when using @threads** (P5, logging, high confidence) | |
| - Logs emitted from `@threads` worker threads were not captured by `@test_logs` (workers inherited the startup global logger). Appears fixed: on nightly with -t4 the threaded logs are captured. | |
| - *Evidence:* ran repro on 1.14-DEV with `julia -t 4`: @test_logs matched all 4 :info messages emitted inside a @threads loop ('passed'); referenced fix PRs #22631/#29706 were closed years ago but task-local logstate now propagates to spawned tasks. | |
| - [ ] [#34710](https://github.com/JuliaLang/julia/issues/34710) **JITEVENTS: native Julia references not visible to external profilers** (P5, docs, high confidence) | |
| - User couldn't see Julia frames in Linux perf because they didn't run the `perf inject --jit` step. The only actionable follow-up was documenting that step, and the manual now covers it. | |
| - *Evidence:* Author 2020-02-14: 'I was not aware of the need for the perf inject step. Thanks!' Verified doc/src/manual/profile.md:687 now contains 'perf inject --jit --input ...'. | |
| ## Other close candidates — fixed per thread evidence, obsolete, duplicate, or working-as-intended (154) | |
| Not runtime-verified (no runnable repro, or needs packages/other OS); justification quoted per issue. | |
| - [ ] [#15481](https://github.com/JuliaLang/julia/issues/15481) **Detached process dies when REPL is closed on Windows** (P3, windows, medium confidence) | |
| - Reported (2016, Julia 0.4) that `detach`-ed subprocesses on Windows die when the parent REPL/terminal closes. A 2025 comment reports the modern equivalent now keeps the detached process running, so this appears fixed and is a close candidate. | |
| - *Evidence:* BioTurboNick 2025-12-26: 'I think this can be closed? ... I can see the launched process continuing to run. Also remains true if I ... kill the parent process. If I don't use detach, the subprocess ends at exit.' Windows-only; could not run here to independently confirm. | |
| - [ ] [#17933](https://github.com/JuliaLang/julia/issues/17933) **Remotecall and @spawnat for threads?** (P3, threads, high confidence) | |
| - 2016 request for remotecall/@spawnat equivalents that run a function on a specific thread. Superseded by task-based threading: Threads.@spawn (Julia 1.3+) provides thread-based spawning, and the PARTR work the maintainers pointed to has long since landed. | |
| - *Evidence:* kpamnany 2016: 'we plan to introduce an @spawn macro in the future... much work needs to happen'; oxinabox 2018: available 'after the first PARTR PR is merged'. Threads.@spawn shipped in 1.3. | |
| - [ ] [#26976](https://github.com/JuliaLang/julia/issues/26976) **`@simd` is unsound** (P3, compiler:simd, medium confidence) | |
| - Keno reported @simd was unsound because the metadata was attached after LLVM ran, so LLVM's loop could differ from the annotated one; he suggested explicitly demarcating the loop body with markers. That is exactly what the later julia.loopinfo/julia.simdloop rework implements, so the design flaw appears addressed; recommend confirming with Keno/vchuravy before closing. | |
| - *Evidence:* Keno's suggested fix: 'explicitly demarcate the loop body (e.g. by a pair of markers)'. base/simdloop.jl now emits Expr(:loopinfo, Symbol("julia.simdloop"), ivdep) to mark the inner loop explicitly. | |
| - [ ] [#27922](https://github.com/JuliaLang/julia/issues/27922) **Build fails with custom directories** (P3, build, low confidence) | |
| - Building with custom prefix/libdir/build_* directories failed (circular make deps, libssh2/LLVM build/link errors), primarily an upstream LLVM cmake libdir limitation. The 2018-era from-source deps build described (libssh2, LLVM compiled in-tree) has since been replaced by prebuilt JLLs, making the specific failures obsolete; last confirmation was 2022 with 'different errors'. | |
| - *Evidence:* Labeled 'upstream'; nalimilan 2018-09: 'LLVM completely ignores environment variables ... can only be fixed upstream'; 2022-02: 'still fails ... though errors are different now'. Build system (deps via BinaryBuilder JLLs) has since changed substantially. Cannot rebuild to verify. | |
| - [ ] [#28669](https://github.com/JuliaLang/julia/issues/28669) **cfunction issue with FunctionWrappers** (P3, ffi, medium confidence) | |
| - cfunction/@cfunction TypeError when used via FunctionWrappers.jl (reported on 1.0-1.4). Later comments report the original TypeError started working again after PR #39821; a subsequent llvm-late-gc-lowering assertion is tracked separately in #40187. The original issue appears resolved/superseded. | |
| - *Evidence:* moustachio-belvedere 2021-03: nightly 'started working again ... Presumably from the recent merged PR #39821'. tkoolen 2021-03: remaining assertion 'is #40187'. | |
| - [ ] [#28799](https://github.com/JuliaLang/julia/issues/28799) **Function keys i.e. F5 and F6 input random characters on windows console** (P3, windows, medium confidence) | |
| - On the Windows console, F1-F5 emit stray characters A-E instead of their escape sequences because the REPL never sets ENABLE_VIRTUAL_TERMINAL_INPUT. digital-carver reports this appears fixed in Julia 1.13 by PR #59825 (which enabled that flag for bracketed paste); only awaiting confirmation from another Windows user before closing. | |
| - *Evidence:* digital-carver 2026-02-05: 'This is possibly/likely solved in Julia 1.13 with #59825 ... Now, with Julia 1.13 beta, the F1 mapping from TerminalPager.jl works on Windows too'; wants 'confirmation from another Windows user before we close this.' | |
| - [ ] [#29851](https://github.com/JuliaLang/julia/issues/29851) **LibGit2: refuses to use private key, document ENV** (P3, libgit2, low confidence) | |
| - LibGit2/Pkg repeatedly re-prompts for an SSH private key and never accepts it when cloning a private repo without ssh-agent. Author concludes this is an upstream libgit2/libssh2 bug (also reproduced in pygit2), not a Julia bug. Report is from 2018 and LibGit2 credential handling has been substantially reworked since; likely obsolete. Only the residual doc request (list the ENV vars used to locate keys) may still apply. | |
| - *Evidence:* ExpandingMan 2018-10-31: 'This seems to be a bug with libgit2 itself, as I'm experiencing similar behavior with pygit2' (links libgit2/pygit2#836). No Julia-side root cause; ssh-agent works. | |
| - [ ] [#31842](https://github.com/JuliaLang/julia/issues/31842) **Very slow second write to a socket** (P3, sockets, high confidence) | |
| - Slow second small socket write due to Nagle's algorithm; JeffBezanson proposed moving disable_nagle from Distributed into Sockets and documenting it. That resolution is now implemented as Sockets.nagle. | |
| - *Evidence:* JeffBezanson: 'disable_nagle ... should be moved to Sockets and documented.' A public `nagle(sock, enable)` now exists at stdlib/Sockets/src/Sockets.jl:595 and is documented in stdlib/Sockets/docs/src/index.md:35. | |
| - [ ] [#32939](https://github.com/JuliaLang/julia/issues/32939) **Fatal error on multi-threaded code processing image files** (P3, threads, high confidence) | |
| - Julia 1.3-era 'concurrency violation'/segfault when using Threads.@threads with FileIO/Images load+save. The most recent comment (BioTurboNick, 2025-12) reports the original example now works reliably on 1.12 and 1.13; likely a thread-safety bug in the old runtime that has since been resolved. | |
| - *Evidence:* BioTurboNick 2025-12-26: 'the original example works reliably on my system on Julia 1.12 and 1.13 now.' Original reports on 1.3.0. | |
| - [ ] [#33899](https://github.com/JuliaLang/julia/issues/33899) **Distributed IOError: write: bad address in system call argument (EFAULT)** (P3, distributed, low confidence) | |
| - Intermittent 'IOError: write: bad address (EFAULT)' when pmap sends a closure over large data via CachingPool. A merged closing PR (#33942, fixing invalid unsafe code) landed shortly after; original report is from Julia 1.0.5/1.3 and needs external packages (TimeZones, Intervals) to reproduce. | |
| - *Evidence:* PR #33942 [MERGED] 'Fix a small number of invalid unsafe code' referenced as closing; issue untouched since 2019/2022 and requires packages, so no recent confirmation. | |
| - [ ] [#36372](https://github.com/JuliaLang/julia/issues/36372) **Prevent people from loading incompatible packages via changing enviroments between loads** (P3, pkg, medium confidence) | |
| - Switching Pkg environments between loads can leave incompatible package versions loaded (Revise/CodeTracking example). Author themselves asks whether this is just a duplicate of #35663 and can be closed; no maintainer objection, and alternative approaches (#44329) were noted. | |
| - *Evidence:* oxinabox 2022-06-10: 'is this just plain a duplicate of #35663? So we can close this one?' KristofferC pointed at PR #44329 as an alternative. | |
| - [ ] [#37029](https://github.com/JuliaLang/julia/issues/37029) **FileWatching has issues with WSL2** (P3, filesystem, high confidence) | |
| - FileWatching (watch_file) fails to detect changes on WSL2 when files live on the Windows filesystem (/mnt/c). Confirmed by StefanKarpinski as an upstream WSL bug (microsoft/WSL#4739); labeled 'upstream'. | |
| - *Evidence:* StefanKarpinski 2020-12: 'It does look like an upstream bug. Thanks for the cross-link'; label: upstream. Not fixable in Julia. | |
| - [ ] [#40297](https://github.com/JuliaLang/julia/issues/40297) **known_hosts SSH verification failing for gitlab.com** (P3, libgit2, medium confidence) | |
| - SSH host verification (turned on by default in 1.6) failed for gitlab.com because libssh2+mbedTLS only understood ssh-rsa known_hosts entries, not ecdsa/ed25519. libssh2 gained ECDSA/mbedTLS support in 1.10 and Julia now ships libssh2 1.11.1, so the specific verification failure is very likely resolved; needs confirmation before closing. | |
| - *Evidence:* StefanKarpinski's root-cause analysis; iamed2 2021-09: 'libssh2 1.10 has been tagged with ECDSA support for mbedTLS.' deps/libssh2.version now LIBSSH2_VER := 1.11.1. ViralBShah 2023-02: 'Is this still an issue?' (unanswered). Workaround JULIA_PKG_USE_CLI_GIT exists. | |
| - [ ] [#40694](https://github.com/JuliaLang/julia/issues/40694) **Errors with non-English homedir** (P3, windows, medium confidence) | |
| - Windows user with a non-ASCII (Korean) home directory cannot precompile packages because the cache path gets mangled (\정의영\ becomes ?�의??). fredrikekre pointed to duplicate #38411; author resolved by renaming the Windows user to English. Old (2021, 1.5/1.6-era) Windows-only console/path encoding issue. | |
| - *Evidence:* fredrikekre 2021-05: 'Looks like #38411.'; vtjnash diagnosed path mangling; author 2021-05: 'It works after changing the system user name to English.' | |
| - [ ] [#41019](https://github.com/JuliaLang/julia/issues/41019) **Error during precompile stage of building v1.6.1 - GitError(Code:ERROR, Class:SSL, failed to load CA certificates...** (P3, build, medium confidence) | |
| - Source build of v1.6.1 fails at the precompile stage on Fedora with a libgit2 'failed to load CA certificates' X509 error. IanButterworth confirmed this is a duplicate of #39289 surfacing during build; a JULIA_SSL_CA_ROOTS_PATH workaround exists. | |
| - *Evidence:* IanButterworth 2021-05-31: 'This is #39289 but popping up during build'; author 2021-06-01 reports a working JULIA_SSL_CA_ROOTS_PATH workaround. | |
| - [ ] [#41684](https://github.com/JuliaLang/julia/issues/41684) **Julia takes a suspiciously long time to run this code** (P3, compiler:codegen, high confidence) | |
| - A WeakRefStrings/InlineString @testset took minutes to compile (time dominated by LLVM_MODULE_FINISH, register allocation and Late-Lower-GCFrame on one huge module). Labeled 'fixed on master'; symptom reported resolved in 1.11. | |
| - *Evidence:* Label 'fixed on master'; adienes 2025-04-30: 'the symptom ... seems to have resolved sometime in 1.11'. | |
| - [ ] [#42072](https://github.com/JuliaLang/julia/issues/42072) **SIGINT crash and inobservance** (P3, repl, medium confidence) | |
| - SIGINT handling anomalies (external SIGINT crashing an idle REPL; needing multiple SIGINTs to interrupt a loop) observed while GR appeared to disable Ctrl+C. Maintainer attributes the observed non-interruptibility to GR blocking all signals, which Julia can't fix. | |
| - *Evidence:* vtjnash 2021-08: 'The underlying GR library blocks all signals–not much we can do about that'. Reporter is a deleted account; no follow-up; Julia-1.6-era report. | |
| - [ ] [#42566](https://github.com/JuliaLang/julia/issues/42566) **glibc is optimized for memory allocations microbenchmarks** (P3, gc, medium confidence) | |
| - Reported 'memory leak' allocating vectors-of-vectors on Linux is actually glibc's malloc not returning freed memory to the OS (not a Julia leak — memory is reused, not linearly growing). vtjnash marked it 'Duplicate of #128' and closed it as upstream glibc behavior; malloc_trim heuristics were explored in PRs (#47062). Canonical tracking is #128. | |
| - *Evidence:* vtjnash: 'Duplicate of #128'; 'it is not a Julia bug, but seems to be an intentional feature of the linux/gnu OS'. Upstream glibc bug 27103 closed as 'not a bug'. | |
| - [ ] [#43442](https://github.com/JuliaLang/julia/issues/43442) **Anti-aliasing false positive with same array** (P3, arrays, medium confidence) | |
| - Reported 'anti-aliasing false positive' where `A[A .> v] .= NaN` allocates ~RHS-sized memory on the first call. N5N3 showed this is not an aliasing bug: the allocation is the `collect` of the LogicalIndex during `ensure_indexable`/view materialization; KristofferC noted it duplicates #30041. | |
| - *Evidence:* N5N3 2021-12: 'this is not a false positive of Anti-aliasing ... the extra allocation comes from [collect during ensure_indexable]'. KristofferC: 'Might be similar to #30041.' Duplicate/subsumed by #30041. | |
| - [ ] [#43673](https://github.com/JuliaLang/julia/issues/43673) **File not closed properly after usage on Windows** (P3, windows, medium confidence) | |
| - Report that files aren't released promptly after open/read on Windows (shown in Computer Management, occasional 'resource busy' on rm). vtjnash could not reproduce and attributed lingering handles to NT-kernel behavior / virus checkers (author confirmed one was running); a 2026 comment reports it no longer occurs on 1.12/Windows 11. Likely close as not-a-bug / not reproducible. | |
| - *Evidence:* Label: needs more info; vtjnash: 'posix-compliant kernels don't have this problem; it is unique to the NT kernel... often a problem with running virus checkers, so do you happen to have one running?' abx78: 'In my case, I did.'; BioTurboNick 2026-01-25: 'FWIW I'm not seeing this on Julia 1.12, Windows 11 25H2' | |
| - [ ] [#44242](https://github.com/JuliaLang/julia/issues/44242) **Julia crashes with "free(): invalid pointer" or "double free or corruption (out)" on ubuntu 20.04.1 TPU vm** (P3, build, medium confidence) | |
| - Julia aborts with 'free(): invalid pointer' inside git_libgit2_init on Google TPU/GCP VMs. Root cause identified by giordano: Google environments preload tcmalloc via LD_PRELOAD (and set LD_LIBRARY_PATH), which breaks many programs, not just Julia. This is an external-environment issue, not a Julia bug; workaround is to unset LD_PRELOAD/LD_LIBRARY_PATH. | |
| - *Evidence:* giordano 2024-08: 'it's known that various Google environments... may set LD_PRELOAD to preload tcmalloc, which breaks lots of software, not just julia... makes sure LD_PRELOAD and LD_LIBRARY_PATH are not forcing to use external libraries which can cause problems.' | |
| - [ ] [#45316](https://github.com/JuliaLang/julia/issues/45316) **TypeErrror when Debugging and Calling Downloads.download** (P3, debugger, medium confidence) | |
| - Stepping through `Downloads.download` in a debugger throws 'TypeError: in typeassert, expected Core.SimpleVector, got Int64' at a `ccall`/`curl_easy_setopt`, because the interpreter mishandles the C call. Core contributor directed this to the JuliaInterpreter.jl repo rather than Base. | |
| - *Evidence:* KristofferC 2022-06-19: 'This should be opened at the JuliaInterpreter.jl repo instead.' | |
| - [ ] [#1315](https://github.com/JuliaLang/julia/issues/1315) **Splicing in arguments into a ccall** (P4, ffi, medium confidence) | |
| - Old request to splat/splice a variable argument list into a ccall. JeffBezanson noted it can't be done portably in general, and it's now achievable in user space: the Ccalls.jl package (2023) supports `Ccall(:pow, Cdouble, (Cdouble,Cdouble), args...)`. No open design work; effectively resolved by packages / workarounds. | |
| - *Evidence:* JeffBezanson 2012: 'I believe this can't be done portably except for functions taking a va_list'; Socob 2023-03: 'using current Julia, it is actually possible to do this!' (Ccalls.jl). | |
| - [ ] [#8206](https://github.com/JuliaLang/julia/issues/8206) **searchsorted improvements (ordered vector type)** (P4, sorting, medium confidence) | |
| - Proposal for an `OrderedVect{T,Ord}` type that stores the sort order in the type so searchsorted can't be called with a mismatched order and can inline lt/by. Core contributor suggested this belongs in a package, not Base. | |
| - *Evidence:* ViralBShah 2021: 'Should we move this to DataStructures.jl or SortingAlgorithms.jl? I doubt this is going to happen in base.' No further support for a Base implementation. | |
| - [ ] [#9095](https://github.com/JuliaLang/julia/issues/9095) **using "run()" - child processes persist after parent exits.** (P4, tasks, low confidence) | |
| - run()-spawned child processes outlive the parent julia process (child not killed on parent exit). vtjnash explains this matches OS semantics (SIGHUP only delivered to sleeping children) and endorses the finalizer(proc, kill) workaround. Effectively working-as-intended; stale since 2016 with only a never-completed doc suggestion. | |
| - *Evidence:* vtjnash 2016: 'the system only delivers SIGHUP if the child process is sleeping... amit's finalizer solution also seems reasonable to me'. Labeled docs; amitmurthy offered to document but never did. | |
| - [ ] [#9180](https://github.com/JuliaLang/julia/issues/9180) **ternary operator with "return" gives a parse error** (P4, compiler:lowering, medium confidence) | |
| - `x > 10 ? return 0 : nothing` gives a parse error because `return`/`:` bind ambiguously. StefanKarpinski called improving the message 'busy work' but merge-able. On nightly the JuliaSyntax parser now emits a precise, located error with a caret pointing at the offending `:`, so the requested improvement is largely delivered. | |
| - *Evidence:* StefanKarpinski 2014: 'The parser already prints an error... If someone wants to submit a pull request to improve this, we can merge it, but I feel like this is just a busy work issue.' Ran repro on 1.14-DEV.2332: now errors with '# Error @ none:2:29 ... `:` expected in `?` expression' and a caret under `return` — much clearer than the old 'syntax: colon expected'. adienes 2025 xref #50415. | |
| - [ ] [#14787](https://github.com/JuliaLang/julia/issues/14787) **Pressing tab in REPL prints warnings when modules export same named function** (P4, repl, medium confidence) | |
| - REPL TAB completion printed 'both X and Y export ...' ambiguity warnings when two used modules export the same name. Reported no longer reproducible on master; only a warning when completing a call to the ambiguous name itself remains, which is deemed acceptable. | |
| - *Evidence:* Liozou 2021: 'Is this still relevant? I can't reproduce locally on master ... The only remaining TAB-completion warning is when trying explicitly plot(# TAB ... but that's fair since the call to plot(...) will not work anyway.' | |
| - [ ] [#14972](https://github.com/JuliaLang/julia/issues/14972) **getaddrinfo throws UVError "unknown node or service"** (P4, sockets, medium confidence) | |
| - getaddrinfo threw a raw UVError on DNS failure; the concrete ask (a dedicated, clearer error type) was implemented via the DNSError work (PR #15879) so getaddrinfo now throws Sockets.DNSError. Remaining thread is an open-ended 2016 philosophy debate about exceptions-vs-Result that has gone nowhere. | |
| - *Evidence:* samoconnor added DNSError; vtjnash 2016-04: 'i would go with it ... providing clearer error messages ... worthwhile'; PR #15879 merged. Modern Julia throws Sockets.DNSError, not raw UVError. No actionable decision since 2019. | |
| - [ ] [#15002](https://github.com/JuliaLang/julia/issues/15002) **promotion to SharedArray** (P4, arrays, medium confidence) | |
| - Reported on 0.4.3 that `a += 1` on a SharedArray produces a plain Array. This is the intended semantics of `+`/broadcast rebinding (ref PR #12964), not a bug; SharedArray moved to a stdlib and the report is a decade stale with no concrete change requested. | |
| - *Evidence:* KristofferC ref PR #12964 (intentional change); DanielArndt: 'it appears this was an intentional change'; tkelman: 'Not an uncontroversial one though.' Author on 0.4.3. | |
| - [ ] [#15699](https://github.com/JuliaLang/julia/issues/15699) **Concurrent printing in REPL** (P4, repl, medium confidence) | |
| - Method-overwrite WARNING appeared garbled/interleaved with other output in a Cygwin/mintty terminal on Windows. musm could not reproduce; tkelman noted it is mintty-specific. Warning formatting has since changed entirely; effectively unreproducible and stale. | |
| - *Evidence:* musm 2017: 'Cannot reproduce, I think this should be closed'; tkelman: 'this is specific to mintty.' Terminal-specific, no repro path, 2016-2017 activity only. | |
| - [ ] [#15881](https://github.com/JuliaLang/julia/issues/15881) **serialize doesn't preserve identity of Expr.args** (P4, serialization, medium confidence) | |
| - serialize/deserialize does not preserve aliasing between an Expr's `args` array and a separate reference to that same array, because the serializer does not track Expr.args as a shareable object for efficiency. Jeff/yuyichao explain this is a known deliberate limitation; author found a workaround (reference the Expr, not its args). | |
| - *Evidence:* JeffBezanson 2016: 'For efficiency, we don't track the args array of an Expr separately.'; author: 'I may serialize ex.args[x] instead of ex.args[x].args ... then it's possible to rewrite my code.' Working-as-intended per core contributors. | |
| - [ ] [#16393](https://github.com/JuliaLang/julia/issues/16393) **document range types syntax and semantics** (P4, docs, low confidence) | |
| - 2016 request for a thorough documentation section on Range types and `:` syntax/semantics. The proposal to change step-ordering to match Python was rejected; remaining ask is broad doc work that has been largely superseded by the current manual's range documentation. Very stale. | |
| - *Evidence:* pao rejected the Python-order change; nalimilan: 'Would you make a pull request? Other than that, it's unlikely to happen soon.' RossBoylan 2021 asks 'Why was this closed?' Range docs have since expanded substantially. | |
| - [ ] [#16642](https://github.com/JuliaLang/julia/issues/16642) **Strange behavior of prepend! with subarrays** (P4, arrays, medium confidence) | |
| - prepend!(x, view(x, :)) (and other self-aliased sources like reshaped views) produces garbage because prepend! assumes the source is unchanged while growing the array at the front. Discussion concluded generic aliasing can't be fully guarded; the referenced follow-up #50824 (MERGED) only added aliasing warnings to docstrings, treating this as documented user error. | |
| - *Evidence:* martinholters 2016: 'many more possibilities for hidden aliasing ... without a good strategy, we will need lots of band aid'; ref PR #50824 (MERGED 2023) 'Add some aliasing warnings to docstrings for mutating functions'. Ran repro on 1.14-DEV: prepend!(x,view(x,:)) still yields [0,0,0,1,2,3]. | |
| - [ ] [#17533](https://github.com/JuliaLang/julia/issues/17533) **`broadcast` for `AbstractArray` types** (P4, broadcast, medium confidence) | |
| - Request that broadcast (.*, etc.) preserve custom AbstractArray output types instead of returning plain Array. Largely superseded by the broadcast revamp: BroadcastStyle now provides a documented interface to customize output container type. Original repro uses removed 0.5 APIs (linearindexing, immutable). | |
| - *Evidence:* mbauman 2018: 'Things are much improved since its inception given that we now have a documented interface for extending broadcast'; p-zubieta 2017: 'write Base.Broadcast.promote_containertype methods for your own type.' | |
| - [ ] [#17756](https://github.com/JuliaLang/julia/issues/17756) **List all help topics (machine readable stable API)** (P4, docs, medium confidence) | |
| - Usage question from 0.4/0.5 era on how to list all help topics after the old Help module was removed, plus a wish for a stable machine-readable docs API. Answered in-thread (apropos in ?-mode, Base.Docs.meta) and a 2025 comment provides a working modern function and suggests closing. | |
| - *Evidence:* MichaelHatherly 2016 gave working listing code via Base.Docs.meta; felixcremer 2025-11: 'In Julia 1 you can use the following function ... So I think, that this issue could be closed.' | |
| - [ ] [#17893](https://github.com/JuliaLang/julia/issues/17893) **Underflow should occur when evaluating exp for very small numbers** (P4, math, medium confidence) | |
| - Request that exp of very small BigFloat arguments raise an underflow signal rather than silently returning 0, by exposing MPFR floating-point exception flags. Explicitly identified as a subset of the longstanding FP-exceptions issue #2976. | |
| - *Evidence:* oxinabox 2016-08-09: 'This can probably be closed as being a subset of #2976'; simonbyrne: we don't want to throw by default, could expose an opt-in switch as gmpy2 does. | |
| - [ ] [#18706](https://github.com/JuliaLang/julia/issues/18706) **128bit atomic support on non-Intel machines** (P4, codegen, low confidence) | |
| - Tracking issue for 128-bit atomic support on non-Intel / non-cx16 machines (ARM, AArch64, Power8) where LLVM emitted __sync libcalls. Resolution depended on LLVM upgrades and removing the hard-coded cx16 requirement; vchuravy notes the PPC fix landed in LLVM 13. Julia is now far past LLVM 13, so likely resolved; needs hardware confirmation. | |
| - *Evidence:* vchuravy 2021: 'For PPC https://reviews.llvm.org/rGb9c3941cd61d landed in LLVM 13'; yuyichao's plan hinged on 'Upgrade to LLVM 3.9 / remove hard-coded cx16 requirement.' Labeled 'upstream'. | |
| - [ ] [#18731](https://github.com/JuliaLang/julia/issues/18731) **generator expressions require parens in macro arg?** (P4, compiler:lowering, high confidence) | |
| - Report that `@test a for a in A if a > .5` isn't a complete generator without parens, unlike the quoted `:( a for ... )`. Explained as working-as-intended: a bare `a for ...` is not a generator; parens are required. Author agreed to close if WAI. | |
| - *Evidence:* tkelman: '`( a for a in A if a > .5 )` is a generator, `a for a in A if a > .5` isn't'; author: 'if it's not a bug ... then the above shouldn't work then I'll close this issue.' Ran on 1.14-DEV: `Meta.parse("a for a in A if a > .5")` still errors 'extra tokens after end of expression'. | |
| - [ ] [#18964](https://github.com/JuliaLang/julia/issues/18964) **Splatting inside generator expressions gives invalid result** (P4, compiler:lowering, medium confidence) | |
| - Splatting in a generator header, `(x for x in 1:2...)`, lowers to an invalid zip-based Generator that errors when collected. Author and nalimilan (core) agreed the parenthesized form is the intended spelling and there is no use case; effectively wontfix, at most it warrants a nicer error. No maintainer interest in 6+ years. | |
| - *Evidence:* nalimilan: 'why should it work? The form with additional parentheses is much clearer'; author: 'I have no use for it ... I'll let you decide'. Ran `collect(x for x in 1:2...)` on 1.14-DEV: still errors with MethodError(identity,(1,2)). | |
| - [ ] [#19258](https://github.com/JuliaLang/julia/issues/19258) **Race condition when quitting and kill(::Process) is in a finalizer** (P4, tasks, high confidence) | |
| - Race/AssertionError when a finalizer calls `kill(::Process)` during `quit()`, leaving an orphan process. Maintainers deemed finalizer-at-exit unreliable and advise proper synchronization (pipes) over kill; labeled 'won't change'. | |
| - *Evidence:* Label: won't change. yuyichao: 'The order of finalizer run is undefined'; vtjnash: 'running finalizers at exit is unreliable' and 'avoid using kill and use a proper synchronization mechanism such as pipes'. | |
| - [ ] [#21017](https://github.com/JuliaLang/julia/issues/21017) **Feature request: a work stealing threaded for loop** (P4, threads, medium confidence) | |
| - 2017 feature request for a work-stealing `@threads` loop. Largely overtaken: `Threads.@spawn` and the `:dynamic` scheduler (now default) provide load balancing, and tkf (contributor) suggested closing since work-stealing per se isn't the goal. | |
| - *Evidence:* tkf 2022: 'It's not work-stealing. But it's a step towards a better load-balancing... Perhaps we can close this... I don't think most users care about the exact scheduling algorithm.' Also duplicates/superseded by #32207. | |
| - [ ] [#21454](https://github.com/JuliaLang/julia/issues/21454) **exp, @fastmath, SVML vectorization.** (P4, compiler:codegen, medium confidence) | |
| - Wishlist to enable SVML vectorization of transcendental functions (exp etc.) and clarify @fastmath semantics. Blocked long-term: Keno says proper SVML integration requires frontend vector-lane awareness Julia lacks, and SVML/MKL can't be shipped due to licensing. simonbyrne flagged it as a duplicate of #15265; discussion dead since 2018. | |
| - *Evidence:* simonbyrne 2017: 'I think this is a duplicate of #15265.' Keno 2018: 'properly integrating SVML requires julia at the frontend level to be aware of vector lanes, which we currently don't have.' | |
| - [ ] [#21957](https://github.com/JuliaLang/julia/issues/21957) **SharedArray performance overhead** (P4, distributed, low confidence) | |
| - SharedArray indexing overhead vs plain Array (2017, v0.5.1). Investigation traced it to bounds-checking accessing the mutable dims field; timholy suggested making SharedArray immutable, but amitmurthy found mutability made no difference. With @inbounds/proper IndexStyle the gap vanishes (biona001 2018 benchmarks match). Stale, effectively resolved as bounds-check cost; SharedArrays now lives in a stdlib. | |
| - *Evidence:* timholy: 'This seems more likely to be a bounds-checking thing, because of access to the (mutable) dims field.' amitmurthy with @inbounds: shared arrays 0.004548s vs regular; biona001 2018 benchmarks show shared and regular arrays perform equally. | |
| - [ ] [#22155](https://github.com/JuliaLang/julia/issues/22155) **Help message for function exported from multiple modules is less helpful than it could be** (P4, error-messages, medium confidence) | |
| - Request (2017) to improve help/error messaging when a name is exported by two modules (originally 'connect' from Foo and Base). Modern Julia already emits a detailed multi-hint UndefVarError at call time, and the reporter's follow-up suggests the help-mode hint may no longer be needed. Largely resolved. | |
| - *Evidence:* felixcremer 2026-01-29: 'Nowadays this will always give the information about when trying to run connect(1) ... Therefore it might be ok, to not show the hint in the help.' Current error now lists ambiguity + per-module hints. | |
| - [ ] [#22216](https://github.com/JuliaLang/julia/issues/22216) **Unitless typeof and eltype** (P4, types, medium confidence) | |
| - Feature request for a generic `unitless(T)`/`quantity` to strip units from a type. Core view (timholy) was this belongs to the package ecosystem, no Base API was agreed, and it is now provided by the Unitless.jl package (baretype). | |
| - *Evidence:* timholy 2017: 'this doesn't seem to be a Julia issue, it's more something for the package ecosystem to agree on.' rashidrafeek 2022: 'Now there is Unitless.jl which can do this'. No decision to add to Base. | |
| - [ ] [#22417](https://github.com/JuliaLang/julia/issues/22417) **Reuse gcframe for jlcall** (P4, compiler:codegen, low confidence) | |
| - Codegen micro-optimization request: jlcall and the gcframe use two separate allocas that could be shared (jlcall stopped using the gcframe after #21888). The LLVM IR shown is from 2017 and GC-frame/codegen have been rewritten since; relevance on current nightly is unverified and likely obsolete. | |
| - *Evidence:* Opened 2017 by yuyichao, zero comments, never acted on; references 2017-era code_llvm and PR #14779/#21888. GC frame codegen has since been reworked (cf. recent GC-frame commits), so the specific two-alloca pattern is likely stale. | |
| - [ ] [#23232](https://github.com/JuliaLang/julia/issues/23232) **libgit2 credentials objects are dangerous** (P4, libgit2, medium confidence) | |
| - LibGit2 credential objects zero the underlying memory of (semantically immutable) string literals on finalization, corrupting later calls. Consensus was to use a dedicated type; omus implemented SecureString in PR #24738 (merged), and LibGit2 credential handling has since been reworked/moved to a package. Likely resolved. | |
| - *Evidence:* omus 2017-11: 'I created a PR which implements SecureString (#24738)'; SecureString has long been part of Base and LibGit2 credentials no longer zero string literals. | |
| - [ ] [#23763](https://github.com/JuliaLang/julia/issues/23763) **Show similar functions in docstrings** (P4, docs, medium confidence) | |
| - Request for 'See also: ...' hints in docstrings, ideally auto-generated from a table of related functions. The manual 'See also' convention became standard practice throughout Base and a documentation hint was added in #23788; Seelengrab questions whether an auto-generation mechanism adds value over just writing See-also lines. Effectively superseded/obsolete. | |
| - *Evidence:* KristofferC: 'There is already that in a bunch of places. Feel free to make PR with more of them.' Seelengrab 2021: 'is the documentation hint added in #23788 sufficient?... I don't see the added benefit' of automatic generation. | |
| - [ ] [#24440](https://github.com/JuliaLang/julia/issues/24440) **Spawning turns IO race into process hang** (P4, io, medium confidence) | |
| - Passing a TTY to spawn made libuv call FIONBIO on the shared kernel object, disabling async IO on the TTY itself and hanging the whole process when a second reader drained the buffer. Keno confirmed in 2025 that the reproducer no longer hangs (likely libuv's pts reopening), though it might still be reproducible via a fifo. | |
| - *Evidence:* Keno 2025-12-06: 'Reproducer no longer hangs. I suspect libuv's pts reopening is saving us here. Could maybe be reproduced with a fifo though.' (repro needs a real TTY/pty, not run here). | |
| - [ ] [#25026](https://github.com/JuliaLang/julia/issues/25026) **Missing InexactError for DateTime +/- Microsecond** (P4, dates, medium confidence) | |
| - Request that `DateTime +/- Microsecond` throw InexactError instead of silently rounding (DateTime has millisecond resolution). Per adienes, the conclusions of merged PR #50816 mean this should be closed as won't-change. | |
| - *Evidence:* adienes 2023: 'given the conclusions of #50816, this should be closed as "won't change"'. Ran on 1.14-DEV: `DateTime(2010,1,1) - Microsecond(1) == DateTime(2010,1,1)` still true (silently rounds, no error) — behavior deliberately unchanged. | |
| - [ ] [#25371](https://github.com/JuliaLang/julia/issues/25371) **Profiler does not collect any samples after JavaCall.init()** (P4, profiler, medium confidence) | |
| - Profiler collects no samples after JavaCall.init() because the JVM installs its own signal handlers, clobbering Julia's profiling signals. Diagnosed as an external JVM/kernel limitation, not a Julia bug; only marginal suggestion was to detect and warn. | |
| - *Evidence:* vtjnash: 'pretty much just a limitation of the linux kernel'. ihnorton: JVM 'installs its own signal handlers which interfere'; x-ref JuliaInterop/JavaCall.jl#71. StefanKarpinski: 'any code you use might cause your program to do anything.' | |
| - [ ] [#25671](https://github.com/JuliaLang/julia/issues/25671) **Should `broadcast` on `Adjoint` should use the parent array's `BroadcastStyle`?** (P4, broadcast, medium confidence) | |
| - Question of whether `BroadcastStyle(::Adjoint)` should inherit its parent's style. mbauman responded that a generic fallback can't be correct in all cases (structured-matrix counterexample), so wrapper authors must define it themselves. No activity since 2018. | |
| - *Evidence:* mbauman 2018: 'we probably need to make you do this yourself. A fallback definition won't always be right ... StructuredMatrixStyle{LowerTriangular} ... would be one obvious case where the adjoint cannot share its parent's style.' Question effectively answered negatively. | |
| - [ ] [#25783](https://github.com/JuliaLang/julia/issues/25783) **Behavior of empty string getindex and Substring constructor** (P4, strings, medium confidence) | |
| - 2018 design question posed to StefanKarpinski about whether empty-range string getindex / SubString should validate indices (breaking) or stay array-consistent. On nightly the array-consistent, non-erroring behavior is in place and stable; the design question is effectively moot. | |
| - *Evidence:* Ran on nightly: `"hello"[10:5]` and `SubString("hello",10,5)` both return "" without error, matching array `x[10:5]` semantics; no comments, decision never formally recorded but behavior settled for years. | |
| - [ ] [#26910](https://github.com/JuliaLang/julia/issues/26910) **feedback on code loading docs** (P4, docs, medium confidence) | |
| - 2018 review feedback on the then-new code-loading manual. StefanKarpinski addressed most points (partly via #27113); the reporter confirmed the tweaks cleared things up. Remaining suggestions are minor and code-loading.md has been heavily rewritten since, so this is largely obsolete/stale. | |
| - *Evidence:* fredrikekre 'Fixed by #27113?'; StefanKarpinski 'Partly...'; ssfrr 2018-05-26 'those tweaks cleared up things for me. Thanks.' | |
| - [ ] [#26938](https://github.com/JuliaLang/julia/issues/26938) **compiler suggestion: optimize out constant arrays** (P4, compiler:optimizer, high confidence) | |
| - Request for the compiler to elide temporary array literals on the RHS of assignments (e.g. m[i,:]=[1.0,2.0,3.0]). JeffBezanson notes it would be a good but hard optimization; KristofferC marked it a duplicate of #5024. | |
| - *Evidence:* KristofferC 2018-05-01: 'Dup of https://github.com/JuliaLang/julia/issues/5024'. | |
| - [ ] [#27244](https://github.com/JuliaLang/julia/issues/27244) **using `eval` inside a @testset, to create a new function in another name space, that already exists in Base, results in an error** (P4, test, medium confidence) | |
| - 0.6 report: using eval inside a @testset to define a function whose name collides with a Base function errored ('must be explicitly imported to be extended') while the same at top level worked. The inconsistency no longer exists on nightly (both scopes behave identically), and the example uses the removed atan2. Recommend closing. | |
| - *Evidence:* ran adapted repro on 1.14-DEV: defining a Base-colliding function via Core.eval into a module behaves identically inside a @testset and at top level (no 'must be explicitly imported' error in either). Original was 0.6; 2-arg eval and name-resolution semantics have since changed. | |
| - [ ] [#27445](https://github.com/JuliaLang/julia/issues/27445) **be able to change optimization level per-function (or per-module)** (P4, compiler:codegen, medium confidence) | |
| - Request to set optimization level per-function/per-module to save compile time. The per-module part is implemented as `Base.Experimental.@optlevel`; StefanKarpinski suggested it's done. Likely closeable (only per-function granularity remains, and the requester never followed up). | |
| - *Evidence:* KristofferC 2020 checkmarked '(or per-module)'; StefanKarpinski 2020: 'Seems done now. Anything else to be done here, @JeffBezanson?' (unanswered). Confirmed on nightly: Base.Experimental.@optlevel is defined. | |
| - [ ] [#27526](https://github.com/JuliaLang/julia/issues/27526) **new IR printing sometimes broken for non-stdout IO** (P4, printing, low confidence) | |
| - `show_ir`/`code_warntype verbose_linetable=true` threw `can't repeat a string -16 times` (negative width) when writing to a pipe/non-stdout IO. Referenced MERGED PR #28390 rewrote the IR-show line-number/inlining printing. | |
| - *Evidence:* PRs: #28390 [MERGED] 'RFC: prettier IR-show for line number and inlining information' referenced; the code path (show_ir#21 in compiler/ssair/show.jl) was rewritten. Original repro needs CUDAnative and narrow-width piping, not reproducible here. | |
| - [ ] [#27596](https://github.com/JuliaLang/julia/issues/27596) **Use fewer significant figures when reporting compile times** (P4, printing, low confidence) | |
| - Cosmetic request to print stdlib/build compile times with ~3 significant figures instead of full microsecond precision. Targets a 0.7-era build/precompile timing output format that no longer exists in this form. | |
| - *Evidence:* No core endorsement; only a flippant reply. Self-assigned to @dpsanders in 2018 with no follow-up; the `Base ──── 74.387312 seconds` build-timing table format is obsolete. | |
| - [ ] [#27879](https://github.com/JuliaLang/julia/issues/27879) **documentation regarding function chaining and function composition** (P4, docs, medium confidence) | |
| - Request to better document/highlight |> chaining and function composition. A 'Function composition and piping' manual section was subsequently added and commenters agreed the docs are now sufficient; only a minor searchability tweak (keywords pipe/piping/chaining) remains. | |
| - *Evidence:* drbenvincent 2019-04-07: 'the docs at .../Function-composition-and-piping are quite nice'; andreasdominik 2019: 'I think the docu is sufficient now'. Section exists; issue effectively resolved. | |
| - [ ] [#28106](https://github.com/JuliaLang/julia/issues/28106) **Is it a bug that jl_set_const C api allows changing a non-const symbol into a const one?** (P4, ffi, medium confidence) | |
| - jl_set_const C API let embedders turn a non-const global into a const one, which JeffBezanson agreed in 2018 was a bug (add bp->value==NULL precondition). The binding system has since been rewritten (1.12 binding partitions) and jl_set_const now carries an explicit 'this function is dangerous and unsound. do not use.' comment (src/module.c:1749), so the original code and concern are obsolete/superseded. | |
| - *Evidence:* JeffBezanson 2018: 'bp->value == NULL should be added as a precondition'. Current src/module.c:1747-1756: jl_set_const rewritten around binding partitions with comment 'this function is dangerous and unsound. do not use.' | |
| - [ ] [#28756](https://github.com/JuliaLang/julia/issues/28756) **Precompilation default in 0.7.0 does not work for certain code layouts** (P4, precompile, low confidence) | |
| - Precompilation warning on 0.7.0/1.0.0 for an unusual multi-directory layout where the same path is pushed to LOAD_PATH multiple times across modules. Author found the trigger (duplicate LOAD_PATH entries) and a workaround; requests a warning or LOAD_PATH sanitization. Predates the modern package/precompile system and LOAD_PATH semantics; likely obsolete, needs re-verification on a supported version. | |
| - *Evidence:* Author 2018-11: 'having the same path multiple times in the LOAD_PATH like this breaks the pre-compiling ... I still believe this is a bug'. Only reproduced on 0.7.0/1.0.0. | |
| - [ ] [#28908](https://github.com/JuliaLang/julia/issues/28908) **`jl_critical_error` deadlocks on `malloc`/`realloc` error** (P4, misc, medium confidence) | |
| - jl_critical_error can deadlock when the crash originated inside libc malloc/realloc, because the backtrace/symbol lookup path itself calls malloc. Maintainers consider this fundamentally unsafe-but-necessary; issue is labeled 'won't change'. | |
| - *Evidence:* Label 'won't change'; yuyichao: 'jl_critical_error is known to be not safe... looking up debug symbols is also next to impossible to be made safe'; vtjnash 2021 note that libunwind may have improved but no action. | |
| - [ ] [#29012](https://github.com/JuliaLang/julia/issues/29012) **doc strings not parsed within an if-block** (P4, compiler:lowering, medium confidence) | |
| - A string literal placed as a docstring at the top of an if-block body is not attached as documentation to the following method (works at top level). Per JeffBezanson this is by design at parse time; docstrings written this way were never supported. | |
| - *Evidence:* JeffBezanson 2018-09-04: 'I believe this happens at parse time. We don't (and I think never have) supported doc strings written this way.' Ran on 1.14-DEV: docstring still NOT attached (Meta.@lower output contains no docstr call). | |
| - [ ] [#29285](https://github.com/JuliaLang/julia/issues/29285) **LICM for pure functions** (P4, compiler:optimizer, medium confidence) | |
| - Request for LICM/hoisting of pure functions (e.g. sin) out of broadcast/loops. Explicitly identified as a duplicate of #20875 by yuyichao and acknowledged by the author; mbauman notes broadcast is behaving as specified. | |
| - *Evidence:* yuyichao 2018-09-20: 'Dup of #20875'; SimonDanisch: 'Yeah I know'. mbauman: 'it is doing exactly what you requested'. | |
| - [ ] [#30001](https://github.com/JuliaLang/julia/issues/30001) **"Unable to find compatible target in system image" on ovirt hypervisor** (P4, sysimage, medium confidence) | |
| - 'Unable to find compatible target in system image' on an oVirt hypervisor pinned to the Intel Conroe (2006) CPU family; resolved by the user raising the cluster CPU family. Julia's baseline requires SSE4.2-era features, so pre-Nehalem CPUs are unsupported. vchuravy flagged it as a duplicate of #29256. | |
| - *Evidence:* vchuravy: 'Likely a duplicate of https://github.com/JuliaLang/julia/issues/29256'. Author: 'the official binaries from the tarball don't work on Intel Conroe as well'. User resolved by raising the emulated CPU family. | |
| - [ ] [#30388](https://github.com/JuliaLang/julia/issues/30388) **Undocumented searchsorted methods** (P4, docs, medium confidence) | |
| - Request to document the lo/hi/ordering methods of the searchsorted family. Consensus in-thread was to keep them internal (use views instead) rather than document them, and the author agreed. Effectively resolved as won't-document. | |
| - *Evidence:* StefanKarpinski: 'Or not exposed accidentally. We should make those internal—better to use views for that functionality.' Author: 'So it makes sense.' | |
| - [ ] [#30401](https://github.com/JuliaLang/julia/issues/30401) **@inbounds does not work with splatting** (P4, arrays, medium confidence) | |
| - @inbounds x[i...] with splatting does not elide the boundscheck when called directly at top-level/REPL scope, though it works when the call is inside a compiled function. This is the general top-level-scope non-optimization limitation rather than a splat-specific bug; the author self-diagnosed it as REPL-only. | |
| - *Evidence:* Ran on 1.14-DEV: the in-function wrapper `h() = f(IndexMe(),1,2)` runs fine while calling `f(IndexMe(),1,2)` at top level still throws 'nope' — matching the author's own 'this is only in the REPL?' conclusion. | |
| - [ ] [#30414](https://github.com/JuliaLang/julia/issues/30414) **Prompt paste broken for multiline input containing multiple expressions** (P4, repl, medium confidence) | |
| - REPL prompt-paste only takes the first line when multiple expressions are pasted with a julia> prompt. Keno explained the paste parser cannot distinguish a continuation line from printed output, and considers the current behavior reasonable; stale since 2018. | |
| - *Evidence:* Keno 2018-12: 'given that I think the current behavior is fairly reasonable.' No activity since. | |
| - [ ] [#30596](https://github.com/JuliaLang/julia/issues/30596) **zip-like version of skipmissing for multiple iterators?** (P4, iteration, medium confidence) | |
| - Feature request for a zip-like skipmissing over multiple iterators (proposed names zipmissing/multiskipmissing). Discussion did not settle on Base semantics/naming; the author ultimately implemented multiskipmissing in Missings.jl, so it moved out of Base scope. | |
| - *Evidence:* pdeffebach 2019-12: 'I've implemented a multiskipmissing iterator in Missings.jl (PR #111).' Earlier: 'It will not be called zipmissing ...' — naming/semantics unresolved for Base. | |
| - [ ] [#30605](https://github.com/JuliaLang/julia/issues/30605) **Error in testset Sockets** (P4, sockets, medium confidence) | |
| - A one-off 'timeout' error in the Sockets testset while running Base.runtests() on macOS with Julia 1.1.0-rc1 (2019). Looks like a flaky test timeout; no reproducer was ever provided when asked, and the version is long unsupported. | |
| - *Evidence:* c42f 2019-01: 'I'm not sure there's enough information here to fix this. Do you have a way to reproduce the problem?' Author never provided a repro; version 1.1.0-rc1, macOS. | |
| - [ ] [#31231](https://github.com/JuliaLang/julia/issues/31231) **Automatically add type parameters for unparameterized fields** (P4, macros, medium confidence) | |
| - Request for an @autotype macro that auto-adds a type parameter per untyped struct field. Maintainers consider it out of scope for Base (better as a package), Jeff explained the downsides of doing it by default, vtjnash showed ComputedFieldTypes.jl already does it, and the author invited closing. | |
| - *Evidence:* jpsamaroo: 'probably out of scope for Base or a Stdlib... fair game for a package'; colinxs: 'Feel free to close this issue unless you see any reason to keep it open!'; vtjnash: solved via ComputedFieldTypes @computed struct. | |
| - [ ] [#31606](https://github.com/JuliaLang/julia/issues/31606) **Add function to compute "fast array" with same "comparison" and "permutation" behavior as original** (P4, arrays, low confidence) | |
| - Companion to #31601: proposal for a `refarray`/`refvaluedict` interface giving fast reference arrays with equal-comparison/permutation semantics for StringArray/PooledArray/CategoricalArray. Discussion concluded to prototype in a package first; piever built ReferenceTraits.jl and the ecosystem later standardized this as DataAPI.jl's refarray/refpool/refvalue, so a Base change is superseded. | |
| - *Evidence:* nalimilan: 'We should probably start with a package, and maybe move it to Base later ... Base doesn't contain functions which aren't used by any type defined in Base'; piever: 'I made a small package here [ReferenceTraits.jl] so that we can start trying out PRs' — realized in the DataAPI.jl package ecosystem. | |
| - [ ] [#31621](https://github.com/JuliaLang/julia/issues/31621) **Loading libopenspecfun.so in --output-o mode fails with "libgfortran.so.4: cannot open shared object file"** (P4, sysimage, medium confidence) | |
| - Loading libopenspecfun.so in --output-o mode failed with a libgfortran.so.4 error because LinearAlgebra.__init__ wasn't run during the old PackageCompiler sysimage workflow. libopenspecfun was later replaced by a pure-Julia SpecialFunctions, and the manual --output-o/__init__ flow is obsolete. | |
| - *Evidence:* Author 2019: 'Calling LinearAlgebra.__init__ manually fixed the issue ... another reason to fix #22910'; ViralBShah: 'we really need to just get rid of libopenspecfun with a pure julia version' (since done). | |
| - [ ] [#31640](https://github.com/JuliaLang/julia/issues/31640) **Fetching docstrings with at-doc macro fails when building system image** (P4, docsystem, low confidence) | |
| - @doc (@doc X) during sysimage build hit UndefRefError because Base.REPL_MODULE_REF is uninitialized in non-interactive/compile sessions. The docsystem and sysimage/pkgimage machinery have been heavily rewritten since 2019; the analogous @doc-of-@doc pattern now runs fine non-interactively. | |
| - *Evidence:* Author root-caused REPL_MODULE_REF being uninitialized. Ran '@doc (@doc Foo) bar' non-interactively on 1.14-DEV: succeeds (no UndefRefError). Original --output-o path not directly re-tested. | |
| - [ ] [#32182](https://github.com/JuliaLang/julia/issues/32182) **parse error on for loop in macro in function call** (P4, parser, medium confidence) | |
| - Syntax error when a `for`-loop macro is passed as a call argument (e.g. `foo(@bar for i in x; end)`). Deliberate ambiguity resolution in favor of generator expressions per #18650; working as designed. Affects Interact-style `@manipulate for ... end` usage. | |
| - *Evidence:* JeffBezanson 2019: 'We decided to resolve this ambiguity in favor of generators, since for loops do not return values' (#18650). Ran on 1.14-DEV and 1.10: still a ParseError, unchanged — matches the deliberate design. | |
| - [ ] [#32585](https://github.com/JuliaLang/julia/issues/32585) **compiler/codegen test broken under julia-debug** (P4, compiler:codegen, low confidence) | |
| - 2019 report (Julia 1.3-DEV) that test/compiler/codegen.jl fails under a julia-debug build because llvm.dbg.value/dbg.declare intrinsics are matched by the ' call ' string checks. Zero comments; the codegen test file has been rewritten extensively over 6 years. Very stale; likely long since fixed or moot — recommend verifying on a current debug build and closing. | |
| - *Evidence:* 0 comments since 2019; failures are all debug-only intrinsics like 'call void @llvm.dbg.value(...)' tripping `!occursin(" call ", line)`. No way to reproduce without a debug build (not available here). | |
| - [ ] [#32606](https://github.com/JuliaLang/julia/issues/32606) **Julia DESTDIR not working, breaks Base.runtests()** (P4, build, medium confidence) | |
| - macOS/MacPorts packaging report (Julia 1.1.1) that DESTDIR concatenates with the build path and build paths get baked into binaries. Largely a build-usage question; vtjnash clarified PREFIX+DESTDIR usage, the remaining replcompletions test failure is an environment issue, and the BaseBenchmarks error is unrelated (unregistered package) per KristofferC. Stale, no actionable confirmed bug. | |
| - *Evidence:* vtjnash: 'You typically need to set PREFIX (the final location) ... in addition to DESTDIR (the staging location).' KristofferC on the BaseBenchmarks trace: 'It is not causing the problem though.' fredrikekre: 'BaseBenchmarks is not a registered package.' | |
| - [ ] [#32923](https://github.com/JuliaLang/julia/issues/32923) **show of invalid ReshapedArray ctor segfaults** (P4, arrays, high confidence) | |
| - show() of an invalid Base.ReshapedArray built directly via the unsafe internal constructor can segfault (out-of-bounds read). Core contributors agree this is 'don't do that' — the constructor is intentionally unsafe/internal, `reshape` is the safe API; a 2025 comment reaffirms it's not relevant. | |
| - *Evidence:* mbauman: 'I think this falls into the don't-do-that category ... I say we just document this.' KristofferC: 'I say we just close this.' oschulz: 'No argument from me.' mbauman 2025-12: 'Yeah, not relevant.' | |
| - [ ] [#32977](https://github.com/JuliaLang/julia/issues/32977) **Link warnings during doc build.** (P4, docs, medium confidence) | |
| - Doc build emitted 'invalid local link' warnings for math.html#Base.:^-Tuple{Number,Number} in base/arrays.md (2019). The offending link no longer exists in doc/src/base/arrays.md and the docsystem/@ref handling has changed substantially since; the specific warning is obsolete. | |
| - *Evidence:* grep of doc/src/base/arrays.md finds no 'math.html' or 'Base.:^' link. StefanKarpinski 2019: 'Happens locally too.' No activity since 2022. | |
| - [ ] [#33114](https://github.com/JuliaLang/julia/issues/33114) **@test_throws does not work with * in non-infix form (e.g. *(a,b))** (P4, macros, medium confidence) | |
| - @test_throws (and macros generally) can't take `*(a,b)` because the parser treats `*` as infix in `@test_throws Ex *(a,b)`. Core contributors declared this an inherent parser limitation with essentially no fix. | |
| - *Evidence:* JeffBezanson: '* is parsed as infix here; this is common to all macros as well as e.g. [2 *3]. Tough to do anything about this.' StefanKarpinski agreed. Working-as-intended/wontfix. | |
| - [ ] [#33154](https://github.com/JuliaLang/julia/issues/33154) **"cp" cannot read from GPFS file system** (P4, filesystem, low confidence) | |
| - cp() hung forever when sendfile returned 0 bytes on a GPFS mount (kernel-specific; a second reporter couldn't reproduce). The base/filesystem.jl sendfile loop has since been rewritten so it no longer decrements by the returned count (no longer infinite-loops), making the original hang non-reproducible; issue is stale and hardware/kernel-specific. | |
| - *Evidence:* Current base/filesystem.jl sendfile now does `nsent = min(typemax(Cssize_t), bytes)` and subtracts the requested chunk, so it cannot loop forever as reported. JonathanAnderson: 'I just tested this on centos ... and it worked just fine for me.' Keno: 'infinite looping julia seems like a bad outcome' but only re: shrinking-file edge case. | |
| - [ ] [#33606](https://github.com/JuliaLang/julia/issues/33606) **A weird bug when sending serialized messages over sockets** (P4, serialization, high confidence) | |
| - Reported 'weird bug' where deserialized socket messages don't fully print. Two responders (laborg, JeffBezanson) diagnosed it as a REPL/task printing artifact: the process exits before the async printing task finishes; adding sleep(0.1) makes it print fully. Not a serialization bug. | |
| - *Evidence:* JeffBezanson 2019-10-21: 'the process is exiting before it gets a chance to finish printing'; laborg: 'not a bug in serialize/deserialize, but rather that the concurrent tasks mess up the REPL printing'. | |
| - [ ] [#33752](https://github.com/JuliaLang/julia/issues/33752) **Regression with CLI argument parsing in interactive mode?** (P4, repl, medium confidence) | |
| - User expected 'julia -L MyFile.jl -- arg1 arg2' to drop into a REPL with ARGS set, but arg1 is treated as the program/script to run and only arg2 lands in ARGS. This is documented positional-argument behavior of '--' (first positional after -- is the program), not a regression. Usage question with no maintainer reply since 2019. | |
| - *Evidence:* Ran on 1.14-DEV: 'julia -L file.jl -- arg1 arg2' loads file, sets ARGS=["arg2"], and tries to include arg1 ('SystemError: opening file arg1') — same as the reported behavior; it is the intended treatment of the first positional as the program. To preload and keep a REPL with args, use -i and pass args without a program (e.g. via ARGS assignment), not a trailing script. | |
| - [ ] [#33762](https://github.com/JuliaLang/julia/issues/33762) **reduce overhead of task creation and switching** (P4, tasks, medium confidence) | |
| - Feature/perf request to reduce task creation and switching overhead, using a fine-grained recursive Fibonacci microbenchmark. kpamnany acknowledged it is a known TODO and lower priority than parallel loops; the author agreed it could be closed if a TODO already tracks it. Stale since 2020 with substantial task-overhead improvements landing since. | |
| - *Evidence:* kpamnany 2019-11-04: 'we haven't done a whole lot of optimization on the runtime overheads at this time; it's a known TODO... Regular parallel loops are a greater concern.' Author 2019-11-05: 'if there is already a TODO that tracks this I'm fine with having this issue closed.' | |
| - [ ] [#34263](https://github.com/JuliaLang/julia/issues/34263) **Bug in stdlib Test - special symbols not working - minimal failing example** (P4, test, medium confidence) | |
| - User confusion, not a Test bug: a macro used inside a @testset defines a function local to the testset scope, so eval (global) can't see it. JeffBezanson explained the scoping and how to reference it (var"..." or @eval). Working-as-intended. | |
| - *Evidence:* JeffBezanson 2020-01-06: 'the issue is that using the macro inside the testset defines a local function, while eval only accesses globals ... it should contain a global declaration and be used at the top-level'. | |
| - [ ] [#35045](https://github.com/JuliaLang/julia/issues/35045) **Force specialization on keyword arguments** (P4, compiler:inference, low confidence) | |
| - Question/request on how to force specialization on captured keyword arguments (`g(; kwargs...)`). KristofferC noted specialization already happens because kwargs are sorted and forwarded as positional args to the inner function; author never followed up. Largely an answered usage question; at most a minor docs note remains. | |
| - *Evidence:* KristofferC: 'Doesn't this already happen? After the keywords are sorted they just call an inner function with everything as normal positional arguments and normal specialization should occur?' No further discussion. | |
| - [ ] [#35114](https://github.com/JuliaLang/julia/issues/35114) **Doctests for modules are troublesome (premature end of input)** (P4, docs, medium confidence) | |
| - jldoctest of a module definition fails with 'premature end of input' due to Documenter's heuristic for splitting input from output on blank lines. A workaround (no blank lines inside the block) is given and it is xref'd to a Documenter.jl issue, so it is external tooling, not a Julia bug. | |
| - *Evidence:* fredrikekre: 'This is probably due to Documenters heuristics on how to split input from output' and gives a working rewrite; tkf: 'xref JuliaDocs/Documenter.jl#963'. | |
| - [ ] [#35178](https://github.com/JuliaLang/julia/issues/35178) **Help of getproperty displays help for methods that are not defined** (P4, docsystem, high confidence) | |
| - ?getproperty used to also display docstrings for stdlib methods (getproperty(::BunchKaufman,...), getproperty(::QRSparse,...)) that weren't loaded, an artifact of stdlibs living in the system image. Reported fixed by a later commenter and no longer reproduces. | |
| - *Evidence:* fredrikekre 2020: 'it is an artifact from the stdlibs being in the system image.' ederag 2023: 'This has been fixed (tested with julia-1.9.2)' with clean ?getproperty output shown. | |
| - [ ] [#35615](https://github.com/JuliaLang/julia/issues/35615) **Handling ambiguous uppercase/lowercase dotted 'İ / i' and undotted 'I / ı' in Turkish language** (P4, unicode, medium confidence) | |
| - Request for locale-aware uppercase/lowercase (Turkish dotted/undotted I). JeffBezanson: Base intentionally avoids locale-dependent behavior; this belongs in a package (bring back ICU.jl). Effectively won't-do-in-Base. | |
| - *Evidence:* JeffBezanson 2020-04-28: 'The design of the C locale system is really not good, and we want to avoid changing the behavior of functions based on locale whenever possible. But it would be great to have this function available in a package.' | |
| - [ ] [#35631](https://github.com/JuliaLang/julia/issues/35631) **Creation of sysimage is not stable for AMD** (P4, sysimage, low confidence) | |
| - User's custom sysimage intermittently fails with 'incompatible cpu target' on an AMD FX-6300. yuyichao explained JULIA_CPU_TARGET env var has no effect here (must pass -C to julia) and requested jl_dump_host_cpu / cpuinfo output to diagnose the native-detection instability. Author never followed up; support question from 2020 with manual sysimage-building workflow now superseded by PackageCompiler. | |
| - *Evidence:* yuyichao 2020-04-28: 'The ENV is for the julia makefile only... You need to pass this as -C to julia. This should fix the symptom.' No repro data provided, author gone. | |
| - [ ] [#35634](https://github.com/JuliaLang/julia/issues/35634) **REPL shift selection not working on windows10?** (P4, repl, low confidence) | |
| - Report that shift+arrow text selection doesn't work in the Windows REPL. The terminal-based REPL line editor has never implemented keyboard text selection on any platform, so this is a feature request / not-a-bug rather than a Windows regression; no comments, author gone (Julia 1.4.1). | |
| - *Evidence:* 0 comments, no core response; the Julia terminal REPL line editor does not implement shift-selection on any OS. Windows-specific, not runnable in this Linux env. | |
| - [ ] [#35907](https://github.com/JuliaLang/julia/issues/35907) **Slow disk IO on MacOS (potentially Windows too)** (P4, io, medium confidence) | |
| - Disk IO benchmarks slower on macOS (and Windows) than Linux. Extensive investigation (incl. a raw C open() test) concluded the slowness is an Apple filesystem / NVMe cache-flush (F_FULLSYNC) hardware/OS characteristic, not a Julia bug; only a lingering speculative angle (libc IO locking / lower-level syscalls). Not a regression (same since 1.0). Stale since 2022. | |
| - *Evidence:* IanButterworth 2020-11: 'All signs are pointing to MacOS just having a slower filesystem'; 2022-02 links Apple NVMe F_FULLSYNC explanation; KristofferC removed release-blocker: 'shouldn't block if it has been the same since 1.0'. | |
| - [ ] [#36236](https://github.com/JuliaLang/julia/issues/36236) **Can logging macros call code hidden behind a function?** (P4, logging, medium confidence) | |
| - Proposal to move logging-macro bodies behind a function (via a deferred closure) to cut emitted code size, ease the compiler, and enable AD tools like Zygote. c42f flagged it as a duplicate of #36174; a design direction (detect trivial vs nontrivial log data, emit a functor or closure, drop the try/catch, later merge shouldlog/handle_message) was discussed and endorsed by JeffBezanson, but no PR materialized. | |
| - *Evidence:* c42f: 'This is a duplicate of https://github.com/JuliaLang/julia/issues/36174, but happy to continue the discussion here.' JeffBezanson on the plan: 'That sounds good.' | |
| - [ ] [#36290](https://github.com/JuliaLang/julia/issues/36290) **Searching the docs for :: doesn't link the section on Types** (P4, doctools, medium confidence) | |
| - Searching the online docs for :: does not surface the Types manual section even though the REPL has help for ::. Diagnosed as a Documenter.jl search-functionality limitation, tracked upstream, so not actionable in the julia repo. | |
| - *Evidence:* zlatanvasovic: 'it's the issue with the search functionality that Documenter.jl provides. Not the issue with the docs themselves.' nsajko 2025: 'upstream issue: JuliaDocs/Documenter.jl#1457'. | |
| - [ ] [#36342](https://github.com/JuliaLang/julia/issues/36342) **when I use Julia to call tvm, the error : CommandLine Error: Option 'aarch64-enable-ccmp' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options** (P4, build, medium confidence) | |
| - LLVM aborts with 'Option aarch64-enable-ccmp registered more than once' when loading TVM (which links a different LLVM) into a Julia process. This is the known hard limitation of two LLVM copies sharing static CommandLine registration; no minimal repro was ever provided and the thread is stale since 2020. | |
| - *Evidence:* StefanKarpinski: 'Otherwise, I'm afraid there's not much actionable here' (no MWE). vchuravy explains the real issue (weak symbols / static vars shared between LLVM builds) but no path forward; author never supplied an MWE. Stale 5 years. | |
| - [ ] [#36721](https://github.com/JuliaLang/julia/issues/36721) **`@code_typed` output is different from the actual IR for recursive Fibonacci function** (P4, compiler:inference, medium confidence) | |
| - @code_typed fib(10) shows one level of inlined/unrolled recursion, which differs from the stored inferred CodeInfo and from @code_llvm. Keno explained there is no well-defined single 'actual IR' and this is the expected result of the default optimize=true (post-inlining) pipeline; at most a docs note is warranted. | |
| - *Evidence:* Keno: 'I'm not sure "the" actual IR of a function is really a well defined concept.' ran on 1.14.0-DEV.2332: @code_typed fib still shows the unrolled/inlined IR — behavior is stable/intended. | |
| - [ ] [#37190](https://github.com/JuliaLang/julia/issues/37190) **Certificate bundle being ignored?** (P4, pkg, low confidence) | |
| - On Julia 1.4/1.5 behind a TLS-intercepting firewall, replacing cert.pem no longer worked and the git clone error was opaque ('GitError Code:ERROR Class:None No errors') vs 1.2's clear ECERTIFICATE. Author self-diagnosed the root cause as env-var handling (#33111) and left it to maintainers to fix the error message or close. Very old (2020), Pkg networking stack has changed substantially since. | |
| - *Evidence:* Author 2020-08-26: 'The problem observed here is due to #33111 ... error message is not clear ... I leave it up to project maintainers to decide whether error needs to be fixed or to close this issue.' No activity since 2020. | |
| - [ ] [#37774](https://github.com/JuliaLang/julia/issues/37774) **Unexpected acceptance and lowering of "dependent type" (spurious TypeVar?)** (P4, types, medium confidence) | |
| - Surprise that `typeof(Lebesgue(eltype(Vector{X}))) where {X<:Real}` is accepted and yields `Lebesgue{Any}`. yuyichao and JeffBezanson explain this is expected: `typeof(...)` is evaluated on the spot with X as a free TypeVar, and the `Any` is an artifact of the fallback `eltype`. Only a low-priority nicety (better error than UndefVarError) remains, blocked with no decision. | |
| - *Evidence:* yuyichao 2020: 'it should get this far and I don't think there's anything to be changed about it.' JeffBezanson 2020: 'It would be nice if we could give some sort of better error, but ... I can't see how to do that without breaking existing useful cases.' | |
| - [ ] [#37924](https://github.com/JuliaLang/julia/issues/37924) **Build system does not seems to rebuild enough?** (P4, build, medium confidence) | |
| - 2020 report that src/Makefile's hand-maintained header dependency list was out of date, so touching a header (e.g. threading.h) under-rebuilt and produced a corrupt sysimg (segfault). Current src/Makefile now makes every object depend on the whole $(HEADERS) set, so the reported under-rebuild is largely addressed; stale (0 reactions, last activity 2022). | |
| - *Evidence:* fingolfin diagnosed 'src/Makefile essentially contains a hardcoded list of source-header dependencies... out-of-date'. Current src/Makefile line 359: `$(BUILDDIR)/%.o: $(SRCDIR)/%.c $(HEADERS)` gives every .o a blanket dependency on all HEADERS (plus explicit threading.h rule at line 517), so header edits now trigger broad rebuilds. | |
| - [ ] [#37979](https://github.com/JuliaLang/julia/issues/37979) **Feature request: a binary/byte string type `BString` in stdlib** (P4, strings, medium confidence) | |
| - Feature request for a Latin-1/byte string type BString in stdlib sharing String's memory layout. Core contributors (KristofferC, StefanKarpinski) recommend implementing it as an external package (Strs.jl already provides BinaryString), seeing no technical or social reason for Base. | |
| - *Evidence:* StefanKarpinski: 'I don't think there's any need for this to live in Base ... works perfectly well as a package'; KristofferC points to Strs.jl BinaryString. | |
| - [ ] [#39325](https://github.com/JuliaLang/julia/issues/39325) **eachcol does not propagate inbounds** (P4, arrays, medium confidence) | |
| - Request that `eachcol` propagate @inbounds. Obsolete: eachcol was reimplemented as a `Slices`/`ColumnSlices` AbstractArray whose `getindex` now does `@boundscheck checkbounds(...)` then `@inbounds view(...)`, so bounds checking is elidable by the caller as requested. | |
| - *Evidence:* base/slicearray.jl:240-242: `@boundscheck checkbounds(s, I...); @inbounds view(s.parent, _slice_index(s, I...)...)`. Original generator-based definition the issue targeted no longer exists (Slices rework, Julia 1.9). NHDaly noted fix was blocked on #39340, which was resolved as expected behavior. | |
| - [ ] [#39638](https://github.com/JuliaLang/julia/issues/39638) **Rational multiplication 0 * Inf results in DivideError** (P4, rationals, high confidence) | |
| - `Rational(0//1) * Rational(1//0)` (0 * Inf) throws DivideError from divgcd. simeonschaub and timholy confirmed this is intentional (analogous to 0.0*Inf being NaN; a silent Rational NaN is undesirable); the author accepted. Only possible follow-up is a clearer error message, with no concrete plan. | |
| - *Evidence:* simeonschaub 2021: 'This is definitely intentional, although it might deserve a better error message.' timholy: '0 * Inf = 0 definitely seems like bad math ... either the error or a NaN-equivalent is perfect.' Author agreed. Ran on 1.14-DEV: still DivideError. | |
| - [ ] [#40041](https://github.com/JuliaLang/julia/issues/40041) **stdlib jlls does not expose the same executables/libraries** (P4, pkg, medium confidence) | |
| - In 1.6 the stdlib LibCURL_jll no longer exposes the curl executable. staticfloat clarified this is intentional (JLL stdlibs lock the shipped version), so the core complaint is working-as-intended; the only residual suggestion is a separate CURL_jll, which lives in the package ecosystem, not the julia repo. | |
| - *Evidence:* staticfloat: 'We purposefully do not want to ship the curl executable as part of LibCURL_jll' and 'the stdlib preventing any other version of LibCURL_jll from being used is the primary feature we want.' Suggested fix (a separate CURL_jll) is a package-repo action. | |
| - [ ] [#40192](https://github.com/JuliaLang/julia/issues/40192) **`import InteractiveUtils` in `startup.jl` breaks default behavior** (P4, repl, low confidence) | |
| - If a user has `import InteractiveUtils` in startup.jl, the old `isdefined(Main,:InteractiveUtils)` guard skipped the `using` that brings unqualified `@code_warntype`/`@edit`/`@which` into scope. The load path in base/client.jl has since been rewritten (load_InteractiveUtils now always runs `using Base.MainInclude.InteractiveUtils` at REPL start regardless of the guard), so the original bug is likely obsolete. | |
| - *Evidence:* base/client.jl:424-437: guard is now `isdefined(MainInclude,:InteractiveUtils)` only around loading; line 437 unconditionally `Core.eval(mod, :(using Base.MainInclude.InteractiveUtils; ...))`. Stale since 2021, 0 reactions. | |
| - [ ] [#40390](https://github.com/JuliaLang/julia/issues/40390) **libunwind linked statically if Julia is built with `USE_BINARYBUILDER=0`** (P4, build, high confidence) | |
| - With `USE_BINARYBUILDER=0`, libunwind was linked statically (only .a files, no .so), breaking LibUnwind_jll tests. Author reports it was already fixed on master by commit d1fa5a57 and only affected the release-1.6 branch (a possible backport). | |
| - *Evidence:* Author: 'It was fixed on master by d1fa5a57acff6ebe51424dca71f6e962d86d28b1... after the release branch forked'; only reproduced on release-1.6. | |
| - [ ] [#40535](https://github.com/JuliaLang/julia/issues/40535) **inspectdr trashes threading performance** (P4, threads, medium confidence) | |
| - Calling InspectDR()/loading a GTK backend massively slows down subsequent Threads.@threads code. This is the known GTK/threading interaction (Gtk.jl#503), driven by external packages rather than a reproducible Base bug; already filed on InspectDR.jl. Not actionable in Base without a package-free reproducer. | |
| - *Evidence:* KristofferC: 'Looks similar to JuliaGraphics/Gtk.jl#503'; jpsamaroo: 'Do you have a reason to suspect this is the fault of Julia...you already have one filed on InspectDR.jl.' | |
| - [ ] [#40677](https://github.com/JuliaLang/julia/issues/40677) **Segmentation fault with threaded FFTW when `JULIA_COPY_STACKS="yes"`** (P4, tasks, medium confidence) | |
| - Segfault when using threaded FFTW with `JULIA_COPY_STACKS=yes`. Discussion concluded this is an upstream FFTW limitation: FFTW passes pointers to stack memory to other threads, which is fundamentally incompatible with COPY_STACKS. Labeled `upstream`; not a Julia-side bug. | |
| - *Evidence:* vtjnash: COPY_STACKS requires 'Never passing pointers to stack memory to other threads'; stevengj: 'in that case, this line in FFTW is a problem' (links FFTW threads.c). Label: upstream. | |
| - [ ] [#41064](https://github.com/JuliaLang/julia/issues/41064) **Addition of `Float16` is wrong on armv7l** (P4, compiler:codegen, low confidence) | |
| - Float16 addition gives wrong results on armv7l when run through the interpreter (--compile=no) while compiled code is correct, pointing to a 32-bit ARM interpreter/soft-float bug. Cannot be verified: armv7l/armv6l builds have been broken since ~1.8 and the platform is unsupported; Float16 handling was rewritten since 2021. | |
| - *Evidence:* staticfloat: --compile=no gives Float16(3.05e-5) vs --compile=yes gives Float16(1.0). oscardssmith 2023: 'A lot of our Float16 handling has been rewritten since 2021'; giordano: building Julia on armv7l/armv6l 'has been broken since v1.8 or so'. | |
| - [ ] [#41680](https://github.com/JuliaLang/julia/issues/41680) **cov(Vector,Vector,dims=1) fails** (P4, linalg, medium confidence) | |
| - cov/cor lack a `dims` keyword method for (Vector,Vector) so cov(rand(5),rand(5),dims=1) errors while the matrix forms work; a consistency/convenience feature. Statistics is now an externally-maintained stdlib, so this should be transferred to JuliaStats/Statistics.jl. | |
| - *Evidence:* Ran on nightly: still 'MethodError: no method matching cov(::Vector,::Vector; dims=...)' — but the method now lives in ~/.julia/packages/Statistics/.../Statistics.jl, i.e. the external Statistics.jl repo. | |
| - [ ] [#41793](https://github.com/JuliaLang/julia/issues/41793) **code_warntype shows unused slots** (P4, display, medium confidence) | |
| - code_warntype shows unused `z@_8/_9/_10::Union{}` slots and their NewvarNodes for a boxed variable. vtjnash clarified this is pre-optimized code shown intentionally and the slots exist to throw UndefVarError — working as intended, not a bug. | |
| - *Evidence:* vtjnash: 'We currently show pre-optimized code (so that it more closely corresponds to the original...)' and 'It is used to throw an UndefVarError(:z)'. Ran on nightly: slots still displayed. | |
| - [ ] [#42047](https://github.com/JuliaLang/julia/issues/42047) **Add table of contents to the right side of pages in the docs** (P4, docsystem, medium confidence) | |
| - Feature request to add a right-side per-page table of contents to the Julia docs. This is entirely an upstream Documenter.jl feature (JuliaDocs/Documenter.jl#1688), which is where the work must happen; the maintainer redirects there. | |
| - *Evidence:* logankilpatrick 2021-10: 'you would want to take a look at JuliaDocs/Documenter.jl#1688 and potentially get involved there.' Nothing actionable in this repo. | |
| - [ ] [#42443](https://github.com/JuliaLang/julia/issues/42443) **`make test` oversubscribes threads** (P4, test, medium confidence) | |
| - `make test` oversubscribed CPU because BLAS threads were not capped when running parallel test workers. staticfloat's proposed plan (set OPENBLAS_NUM_THREADS=1 when launching multiple workers) is now implemented: test/runtests.jl calls `LinearAlgebra.BLAS.set_num_threads(1)` when it adds multiple worker processes. | |
| - *Evidence:* test/runtests.jl:123 `LinearAlgebra.BLAS.set_num_threads(1)` inside the `n > 1 && addprocs_with_testenv(n)` block, matching staticfloat 2021-10-04 plan step 2. | |
| - [ ] [#42813](https://github.com/JuliaLang/julia/issues/42813) **`repl.interface` and `repl.backendref` not defined at REPL init time** (P4, repl, medium confidence) | |
| - `repl.interface` and `repl.backendref` are not yet defined when `atreplinit` callbacks run (they are set up later). KristofferC noted the standard practice is to define them yourself if not present (as OhMyREPL does). Effectively a usage question answered with a workaround; behavior is by design. | |
| - *Evidence:* KristofferC 2021-10: 'you typically define it yourself if they are yet not defined' with link to OhMyREPL. No maintainer treated it as a bug; only 1 comment, 0 reactions, untouched since 2021. | |
| - [ ] [#43416](https://github.com/JuliaLang/julia/issues/43416) **Stopping precompiling doesn't work (properly)** (P4, pkg, low confidence) | |
| - Vague 2021 report that Ctrl-C during precompilation leaves the terminal cursor hidden and possibly segfaults. KristofferC explained the cursor is toggled by a Pkg.jl finally block (not a Julia bug) and the interrupt-handling has since been overhauled; stale and Pkg-specific, likely obsolete. | |
| - *Evidence:* KristofferC 2021-12: 'The cursor is disabled before precompiling ... and then re-enabled ... If that finally doesn't run, it would be disabled.' Author unsure ('I may have even gotten a segfault before, if I recall'). No activity since 2022-01-03; concerns Pkg.jl. | |
| - [ ] [#44295](https://github.com/JuliaLang/julia/issues/44295) **lowering `let` at the top level is slow** (P4, compiler:lowering, medium confidence) | |
| - Evaluating a large `let` block at top level (as JuliaInterpreter/debugger did) is ~20-30x slower than a `block`, due to extra top-level scope checks. JeffBezanson explained the cause; KristofferC (reporter) noted JuliaInterpreter no longer uses this pattern and offered to close if nothing worth doing. | |
| - *Evidence:* KristofferC 2022-02: 'JuliaInterpreter has gotten smarter now so this doesn't influence it anymore. Feel free to close if you think there is nothing to do here.' JeffBezanson: 'this is specific to let blocks at the top level... At the top level there are extra checks (probably due to the REPL-vs-file scope warning thing).' Ran repro on 1.14-DEV: let=3.6s vs block=0.1s — still slow, but the motivating use case is gone. | |
| - [ ] [#44314](https://github.com/JuliaLang/julia/issues/44314) **Issues related to the purity modeling PR** (P4, build, low confidence) | |
| - Reminder/tracking issue from 2022 about an LLVM musttail tail-call-elimination error on M1 building CodeInstance ccall (nested anonymous union in julia.h), which had a hacky fix at the time. Author framed it as 'more of a reminding issue'; likely obsolete now. | |
| - *Evidence:* Body: 'This is more of a reminding issue'; '#44807' did not help. adienes (2025-07): 'I would assume this is stale by now?' with no response. M1/Apple Silicon builds work fine today. | |
| - [ ] [#44337](https://github.com/JuliaLang/julia/issues/44337) **Prebuild Julia musl binary fails on void - libjulia.so.1 not found** (P4, build, low confidence) | |
| - Official musl Julia binary fails to run on Void Linux because Void's libc uses a different interpreter/soname (libc.musl-x86_64.so.1 vs libc.so). Explained by maintainers as a distro libc-naming difference, not a Julia bug; workaround (patchelf) provided. Stale since 2022. | |
| - *Evidence:* jpsamaroo/giordano: 'The libc naming is different on your system, so the released binaries can't find their interpreter.' staticfloat: 'This error message isn't printed by us, it's printed by the dynamic linker.' Niche, no fix path, idle since 2022. | |
| - [ ] [#44980](https://github.com/JuliaLang/julia/issues/44980) **Relax type constraints on xoshiro_bulk rand!() dispatch** (P4, random, medium confidence) | |
| - Request to relax xoshiro bulk rand! dispatch from Array to a broader type so custom dense arrays benefit. Current source already dispatches on MutableDenseArray{T}, so the relaxation has effectively been implemented. | |
| - *Evidence:* stdlib/Random/src/XoshiroSimd.jl:298-310 now uses `dst::MutableDenseArray{T}` (was `Array` in 2022), broadening beyond plain Array as requested. | |
| - [ ] [#45083](https://github.com/JuliaLang/julia/issues/45083) **Confusing error when non-`isbitstype` value is used in a type parameter** (P4, error-messages, low confidence) | |
| - Request to improve the 'expected Type, got a value of type X' error when a non-isbits value is used as a type parameter (e.g. Val(SomeParams(1,1))), suggesting a clearer message referencing isbitstype. Author themselves flagged it as a likely duplicate of #39786; no maintainer engagement. | |
| - *Evidence:* Seelengrab 2022-04-26: 'Is this a duplicate of https://github.com/JuliaLang/julia/issues/39786?' (unanswered). Ran on 1.14-DEV: still `TypeError: in Type, in parameter, expected Type, got a value of type SomeParams`. | |
| - [ ] [#45845](https://github.com/JuliaLang/julia/issues/45845) **Sockets EXCEPTION_ACCESS_VIOLATION** (P4, windows, high confidence) | |
| - EXCEPTION_ACCESS_VIOLATION when interrupting a hung Sockets client/server with Ctrl-C on Windows (Julia 1.6.2). vtjnash says the segfault only occurs after 'Force throwing a SIGINT', which is expected behavior; the author themselves called it 'a non-issue'. | |
| - *Evidence:* vtjnash: 'I only get the segfault after it prints "Force throwing a SIGINT", which is the expected behavior'; author: 'I'm guessing this is a non-issue given it occurs when you interrupt with ctrl+c'. | |
| - [ ] [#46246](https://github.com/JuliaLang/julia/issues/46246) **Endless loop when installing a package after CRTL-C in 1.7.3** (P4, pkg, medium confidence) | |
| - On 1.7.3, pressing CTRL-C during precompile/package install produced endless 'curl_multi_socket_action: 8' error spam and CTRL-C no longer responded. This is the Downloads.jl issue (JuliaLang/Downloads.jl#189) which already had a fix PR (#190); the report is really about that stdlib bug on an old release. | |
| - *Evidence:* DilumAluthge: 'That is JuliaLang/Downloads.jl#189, presumably?'; author confirms 'Yes, presumably, I see you had a fix: Downloads.jl#190'. Belongs to Downloads.jl, fixed there, 1.7.3-only, stale since 2022. | |
| - [ ] [#13504](https://github.com/JuliaLang/julia/issues/13504) **Simplify function signature insertion in docsystem ?** (P5, docs, medium confidence) | |
| - Feature request to auto-insert function signatures into docstrings via a placeholder. This was implemented outside Base as DocStringExtensions.jl's `$(SIGNATURES)` / `$(TYPEDSIGNATURES)`, which the docsystem maintainer points to; superseded and can be closed. | |
| - *Evidence:* MichaelHatherly: 'DocStringExtensions.jl ... implements the $doc!sig idea (but with the name $SIGNATURES instead).' No Base change was ever pursued. | |
| - [ ] [#14903](https://github.com/JuliaLang/julia/issues/14903) **Issues with scope-documentation** (P5, docs, low confidence) | |
| - 2016 checklist of minor scope-documentation improvements left over from PR #12146 (let head vs body, macro hygiene example, placement of Constants section, parallel-scope docs). Author noted 'these are not pressing'; the scope docs have been substantially rewritten since, so most items are likely stale/addressed. | |
| - *Evidence:* Author mauro3: 'Edit: these are not pressing.'; single follow-up comment only; issue untouched since 2016 while manual scope docs were rewritten multiple times. | |
| - [ ] [#15636](https://github.com/JuliaLang/julia/issues/15636) **Undetected git version should be a run-time error** (P5, build, medium confidence) | |
| - Building Julia from a shallow git repo yields a misleading version string (0.5.0-dev without +NNN), which broke Compat.jl's version checks. Nine years stale, framed around Compat.jl (now largely obsolete); tkelman pointed to #17434 as partial mitigation. | |
| - *Evidence:* tkelman 2016: '#17434 may help alleviate some of your concerns here.' Last activity 2016; concern rooted in Compat.jl version-number feature detection which is no longer central. | |
| - [ ] [#17916](https://github.com/JuliaLang/julia/issues/17916) **Tests for git https clone/proxy** (P5, test, low confidence) | |
| - 2016 'help wanted' task to add CI tests for git https clone / proxy support in LibGit2. Likely obsolete: the Pkg/LibGit2 stack and CI infrastructure have been rewritten since, git now often goes through the CLI, and there has been no activity since 2016. | |
| - *Evidence:* tkelman 2016-08: HttpServer.jl-based tests would be annoying, prefer installing something on CI; no progress since. Assigned to Keno, stale 9 years. | |
| - [ ] [#20927](https://github.com/JuliaLang/julia/issues/20927) **Restore functionality of produce/consume** (P5, tasks, medium confidence) | |
| - 2017 request to restore the deprecated `produce`/`consume` Task-switching API. Julia permanently moved to Channels/Tasks; the concrete ask (task return value accessible) was addressed via `task.result`. Effectively obsolete/superseded. | |
| - *Evidence:* JeffBezanson 2017-03-08: 'This will bear discussion, but for now the return value of the task function should at least be accessible as task.result.' produce/consume long since fully removed. | |
| - [ ] [#21392](https://github.com/JuliaLang/julia/issues/21392) **Unexpected pass doesn't show stacktrace** (P5, test, high confidence) | |
| - Report that an 'Unexpected Pass' (a @test_broken that passes) showed no line-number info. KristofferC confirmed in 2019 that line info is now displayed ('Error During Test at REPL[13]:3'), resolving the issue; can be closed. | |
| - *Evidence:* KristofferC 2019: 'Updated the title... since we now show ... at REPL[13]:3 # <- line info'. | |
| - [ ] [#21769](https://github.com/JuliaLang/julia/issues/21769) **wrong method called in `@testset`** (P5, test, medium confidence) | |
| - Report that a method defined inside a top-level @testset isn't seen on the first run but is on the second — this is standard world-age behavior (a single top-level expression executes in a fixed world), not a bug. Originated from a test typo in #21666 which is long since resolved. | |
| - *Evidence:* Author: 'It looks like the whole @testset runs in the same world - but that is not generally the case, is it?' — this is expected world-age semantics; new method defs within one top-level begin/@testset block aren't visible until the world increments. No core follow-up; obsolete (about a 2017 cumsum/TypeArithmetic test that no longer exists). | |
| - [ ] [#21910](https://github.com/JuliaLang/julia/issues/21910) **Make `ucfirst` a method of `uppercase`** (P5, strings, medium confidence) | |
| - Request (2017) to fold ucfirst into uppercase via a keyword. stevengj argued titlecase already covers the need; author self-closed noting ucfirst moved to the Unicode stdlib (since renamed uppercasefirst). Obsolete/resolved; only kept open because stdlib lacked its own tracker in 2017. | |
| - *Evidence:* dpsanders 2017-12-27: 'Closing, since ucfirst has now been moved to the Unicode stdlib package.' stevengj: 'I don't see why we need ucfirst given titlecase.' Function has since been renamed uppercasefirst. | |
| - [ ] [#22288](https://github.com/JuliaLang/julia/issues/22288) **error when eval'ing definitions with interpolated variables if module has a docstring during bootstrap** (P5, docsystem, medium confidence) | |
| - During bootstrap, a documented module whose body uses `@eval` with an interpolated variable errors (UndefVarError) because the doc system only accepts limited syntax before it is loaded. yuyichao explained this is expected pre-Docs.jl behavior; only reproducible in sysimg source files, not user code. | |
| - *Evidence:* yuyichao 2017-06-08: 'It is expected (so not a critical bug, but can possibly be improved) that the doc system accept only limited syntax before it is defined'; 'It'll not error if you put it after include("docs/Docs.jl").' Bootstrap-only edge case. | |
| - [ ] [#23281](https://github.com/JuliaLang/julia/issues/23281) **Audit gc root allocations for exceptions in small functions?** (P5, compiler:codegen, low confidence) | |
| - Asks whether Base should manually outline error-throwing paths in small functions for speed, or whether the compiler will handle it automatically. yuyichao answered that the plan is to handle it another way; much manual outlining has since been done in Base and error paths are cheaper. Stale meta/perf question that was effectively answered. | |
| - *Evidence:* KristofferC: 'is the plan to deal with all of that in another way ...?'; yuyichao: 'Yes.' — indicating manual outlining is not the intended long-term approach. | |
| - [ ] [#24028](https://github.com/JuliaLang/julia/issues/24028) **logging() in .juliarc.jl does not work** (P5, deprecations, high confidence) | |
| - logging() had no effect when called from .juliarc.jl. Both the logging() function and .juliarc.jl are long gone (logging deprecated by #24490; startup.jl replaced .juliarc.jl); the underlying method-overwrite warning concern was tracked in #25109. Obsolete. | |
| - *Evidence:* c42f: 'logging() is now deprecated by #24490 so this issue is somewhat obsolete.' Remaining warning-suppression concern redirected to #25109. logging() and .juliarc.jl no longer exist. | |
| - [ ] [#24347](https://github.com/JuliaLang/julia/issues/24347) **Request: Store the Expr behind each Method object** (P5, metaprogramming, medium confidence) | |
| - Request to store the source Expr/AST behind each Method for tooling (tracing, query translation). JeffBezanson argued against storing AST (favoring IR / @code_lowered, citing inner-function scoping issues); the community solved it externally with CodeTracking.jl. Effectively superseded and stale since 2019. | |
| - *Evidence:* JeffBezanson: 'I still strongly recommend against doing program transformations on a representation with ~100 forms...' and points to @code_lowered/IR. oxinabox 2019: 'Use CodeTracking.jl's `definition` function.' | |
| - [ ] [#25121](https://github.com/JuliaLang/julia/issues/25121) **string representations of expressions without using interpolation and `Expr( )` calls** (P5, printing, high confidence) | |
| - Usage question asking for a `deparse` to turn Expr back into source strings. JeffBezanson answered: use CSTParser.jl for source exprs; lowered code can't be stringified; the only Base-side improvement (printing :toplevel Exprs with `;`/newlines instead of `Expr(:toplevel,...)`) is tracked by #10209. | |
| - *Evidence:* JeffBezanson 2017: 'For source expressions, take a look at CSTParser.jl... See also #10209, which would enable stringifying more Exprs.' Question effectively answered; no further activity since 2017. | |
| - [ ] [#26220](https://github.com/JuliaLang/julia/issues/26220) **Document that everything is evaluated in the same world age inside a `@testset`.** (P5, docs, medium confidence) | |
| - Report that redefining a method mid-@testset and calling it doesn't see the new definition; martinholters explained this is expected world-age behavior (use invokelatest/eval). Author accepted and retitled to a docs request, but this is a very old (0.6) usage question and Julia's world-age semantics have since changed substantially. | |
| - *Evidence:* martinholters: 'Inside a @testset, everything is evaluated in the same world age ... so this is expected'. Author: 'Thank you Martin! ... I'll change the title of the issue'. Working-as-intended; only a minor doc note was ever requested. | |
| - [ ] [#26468](https://github.com/JuliaLang/julia/issues/26468) **UDP send failed: address not available (EADDRNOTAVAIL)** (P5, sockets, medium confidence) | |
| - A single UDP socket test (socket.jl:284) failed with EADDRNOTAVAIL on a user's macOS machine running Julia 0.6.2 in 2018. Zero comments, no confirmation, almost certainly a local network-config issue on an ancient unsupported version. | |
| - *Evidence:* Reported only on 'Julia Version 0.6.2' macOS, 0 comments, no maintainer follow-up; test suite has been substantially rewritten since. | |
| - [ ] [#26750](https://github.com/JuliaLang/julia/issues/26750) **Weird parsing of quoted macro names?** (P5, macros, low confidence) | |
| - Confusion over parsing of `:@simd + 2` (parses as quote of greedy macrocall `@simd(+2)`) and the ternary `simd ? :@simd : :@identity`. This is standard greedy macro-call parsing; bramtayl explained the ternary case; no maintainer flagged a bug. | |
| - *Evidence:* bramtayl 2018: parses as `(simd ? :(@simd : :@identity))`. Ran nightly: `:(:@simd + 2)` -> `:(@simd(+2))` (greedy, expected); ternary now gives clear 'whitespace not allowed after `:` used for quoting'. | |
| - [ ] [#27595](https://github.com/JuliaLang/julia/issues/27595) **Global JULIA_PKGDIR but install packages locally** (P5, pkg, high confidence) | |
| - User question about sharing a read-only global JULIA_PKGDIR while precompiling into per-user dirs, on Julia 0.6. Usage/support question about the obsolete pre-Pkg3 package system. | |
| - *Evidence:* StefanKarpinski 2018-06-18: 'This seems like a question more appropriate for discourse.julialang.org since there's not an obvious feature request here.' Refers to Julia 0.6 / JULIA_PKGDIR, long obsolete. | |
| - [ ] [#28237](https://github.com/JuliaLang/julia/issues/28237) **`EOFError / ReadOnlyMemoryError` with local workers when importing package** (P5, distributed, high confidence) | |
| - Intermittent segfault / EOFError / ReadOnlyMemoryError on Julia 0.6.2 when importing a package (LightGraphs, DifferentialEquations) with many local workers (julia -p 20). Author confirmed it is fixed on 0.7.0-beta2; obsolete report against an unsupported version. | |
| - *Evidence:* jtackm 2018-07-28: 'It seems the problem is fixed on the latest 0.7.0 beta.' Reported only on 0.6.2. | |
| - [ ] [#29632](https://github.com/JuliaLang/julia/issues/29632) **Julia from Emacs ESS freezes Emacs, no console input line visible** (P5, repl, low confidence) | |
| - Julia 1.0.1 launched from Emacs ESS hangs Emacs and shows no prompt/splash (Windows 10, ESS 17.11). Primarily an ESS-integration problem ('ESS requires the splash screen'); very old, no Julia-side repro, no activity since 2018. Likely obsolete/external-tooling; close-candidate. | |
| - *Evidence:* Author 2018-10-26 update: over TRAMP on Linux 'see the splash without freezing, but still no prompt'; body notes 'ESS Github has indicated that ESS requires the splash screen'. No labels, single comment, Julia 1.0.1. | |
| - [ ] [#31248](https://github.com/JuliaLang/julia/issues/31248) **Backslash in Date Formats** (P5, dates, high confidence) | |
| - Report that backslash in a date format produces wrong output; mbauman explained it is just REPL string escaping in display vs print — printing/writing the string gives exactly the expected `2019\y019-03`. Working as intended, no bug. | |
| - *Evidence:* mbauman 2019-03: 'Just print it and you'll see you're getting what you wanted... Julia displays strings... so it uses " and escapes the \.' | |
| - [ ] [#32130](https://github.com/JuliaLang/julia/issues/32130) **Proposal: Allow system image compilation without some modules in stdlib** (P5, sysimage, medium confidence) | |
| - 2019 proposal to let the sysimg build blacklist stdlib modules to shrink the system image. Superseded by modern tooling: stdlibs are now independent packages, sysimage customization is handled by PackageCompiler, and image trimming/juliac address the small-footprint embedded use case. | |
| - *Evidence:* Proposal from 2019; only a clarifying question from KristofferC ('What happens if you turn off precompilation?'), no endorsement. Mechanism proposed (blacklist.stdlib) does not match current build; goal now served by PackageCompiler/trimming. | |
| - [ ] [#32191](https://github.com/JuliaLang/julia/issues/32191) **serialization/deserialization doesn't return the same lambda** (P5, serialization, medium confidence) | |
| - serialize/deserialize of an anonymous function yields a function that is `!=` to the original because the serializer saves and re-creates the whole lambda rather than referencing it by name. Explained as intended heuristic; only a vague suggestion of adding an opt-in Serializer option, never decided. | |
| - *Evidence:* JeffBezanson 2019: 'This is kind of a heuristic the serializer uses... the most generally useful thing we can do is save the whole function and re-create it on deserialization. I think there could be an option in the Serializer object to change this.' | |
| - [ ] [#35143](https://github.com/JuliaLang/julia/issues/35143) **Documentation for release candidate is missing** (P5, docs, medium confidence) | |
| - 2020 report that docs.julialang.org version dropdown did not list the 1.4.0 release candidate. Obsolete infrastructure complaint about a long-past RC; the docs multi-version system has since changed and 1.4 is ancient history. | |
| - *Evidence:* ViralBShah 2020: 'the docsystem builds the docs for the old releases, and from master, but does not show the docs for the release under preparation.' About 1.4.0-rc2, now years obsolete. | |
| - [ ] [#36898](https://github.com/JuliaLang/julia/issues/36898) **[Build time issues] chmod missing targets** (P5, build, low confidence) | |
| - Cosmetic build-script noise: the fixup-libgcc/linkage step tries to chmod a 'liblapack*' glob that doesn't exist and prints 'chmod: cannot access ... No such file or directory' before skipping. Reported on 1.5.0 in an unusual self-compiled-gcc environment; harmless (build completes), author unsure it's even a bug. | |
| - *Evidence:* Author: 'the above is probably not a real issue ... I think it will compile fine'; script already handles it (' doesn't exist, skipping'). No comments, stale since 2020, Julia no longer ships separate liblapack this way. | |
| - [ ] [#37436](https://github.com/JuliaLang/julia/issues/37436) **building from source requires version of git with -C flag** (P5, build, medium confidence) | |
| - Report that building from source fails with git 1.8.3.1 because the build uses `git -C` (added in git 1.8.5). Suggests documenting a minimum git version. git 1.8.3.1 is long EOL, the modern build already requires a recent git, and there was zero follow-up activity since 2020. | |
| - *Evidence:* Author: 'git version 1.8.3.1 ... not sure when the -C flag was added'; 0 comments, 0 reactions, untouched since 2020-09-06. `git -C` predates all currently supported toolchains. | |
| - [ ] [#37485](https://github.com/JuliaLang/julia/issues/37485) **Except high memory used when use use socket server loop** (P5, sockets, high confidence) | |
| - User reports high/growing memory in a hand-written TCP echo server on Julia 1.5. No profiling or evidence of a leak; the code accumulates per-connection state. A maintainer redirected it to Discourse as a usage question. | |
| - *Evidence:* DilumAluthge: 'Please use Discourse to ask questions about using Julia'. No repro of an actual leak; stale since 2020. | |
| - [ ] [#38141](https://github.com/JuliaLang/julia/issues/38141) **AbstractOrderedDict (and AbstractOrderedSet) in Base** (P5, collections, medium confidence) | |
| - Feature request to add AbstractOrderedDict/AbstractOrderedSet to Base, predicated on Dict becoming ordered. KristofferC pushed back ('I don't really see why'), the associated PR #38153 was closed unmerged, Dict never became ordered, and the author offered to close if not needed. Stale FR without core endorsement. | |
| - *Evidence:* KristofferC: 'I don't really see why that is the case. Why is it needed?'; PR #38153 CLOSED (not merged); author: 'if we don't then please just close.' | |
| - [ ] [#41397](https://github.com/JuliaLang/julia/issues/41397) **Could we add `'∠'` character as a power operator** (P5, parser, medium confidence) | |
| - Speculative request to add '∠' as a power/polar-complex operator. It is currently a valid identifier character so adding operator meaning is breaking; stevengj said it can't change in 1.x and `r*cis(phi)` already covers the use case. A secondary `rcis` proposal was also declined. Effectively rejected/stalled. | |
| - *Evidence:* Labels speculative, breaking, parser; JeffBezanson: 'This ... is an identifier character currently, so technically breaking'; stevengj 2021-06-30: 'I don't think we can change this in Julia 1.x' and rejected adding rcis. | |
| - [ ] [#42222](https://github.com/JuliaLang/julia/issues/42222) **Proposal: empty-var args should dispatch to most general method** (P5, dispatch, high confidence) | |
| - Speculative Julia 2.0 proposal to make empty varargs dispatch to the most general method. vtjnash marked it a duplicate of #795; stevengj also pointed to alternative #42455/#42455. | |
| - *Evidence:* vtjnash (2022-04): 'Duplicate of https://github.com/JuliaLang/julia/issues/795'. Labels: speculative, breaking. | |
| - [ ] [#44418](https://github.com/JuliaLang/julia/issues/44418) **Disallow the Unicode "Braille Patterns" block for code (e.g. variables, and function names), but not in strings** (P5, unicode, medium confidence) | |
| - Proposal to disallow Unicode Braille Patterns block in identifiers (allow in strings). Multiple core contributors (KristofferC, stevengj, vtjnash) and mgkuhn argued against forbidding at the language level — same argument applies to all confusable Unicode; consensus leans reject. | |
| - *Evidence:* KristofferC: 'This doesn't make sense to forbid on the language level... more suitable [as] a style guide entry.' stevengj notes huge numbers of confusables already exist. mgkuhn: 'This seems a non-issue.' KristofferC counterexample: `⠙ = '⠙'` is valid useful code. | |
| - [ ] [#44979](https://github.com/JuliaLang/julia/issues/44979) **`Base.runtests(String[])` runs all tests** (P5, test, high confidence) | |
| - Base.runtests(String[]) runs all tests instead of none, which is intended behavior inherited from choosetests.jl. Triage ended with StefanKarpinski deciding to leave it as-is; at most a docstring clarification remains. | |
| - *Evidence:* DilumAluthge: 'This is the intended behavior'; StefanKarpinski 2022-04-19: 'Eh, just leave it then. Seems like too much of a hassle to change it.' | |
| - [ ] [#46566](https://github.com/JuliaLang/julia/issues/46566) **[Can not compile Julia] - "more undefined references to `jl_ExecutionEngine'"** (P5, build, medium confidence) | |
| - User reported a source-build link failure ('undefined reference to jl_ExecutionEngine'/jl_TargetMachine) building julia-1.8.0 from a release tarball in 2022 on an old local GCC/glibc toolchain. Environment-specific linker/LLVM issue with no comments, no reproduction by maintainers, and no follow-up; stale. | |
| - *Evidence:* 0 comments; failure is a link-time 'undefined reference' during codegen lib build on a user's custom -O2 -fPIC build of an ancient release; no maintainer engagement and never reproduced. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ## Confirmed closeable by debugging agents — investigated in depth (50) | |
| These were triaged as needs-debugging; a debug agent reproduced/analyzed each on the HEAD build and concluded it should be closed. | |
| - [ ] [#11938](https://github.com/JuliaLang/julia/issues/11938) **Optimize creation and serialization of closures** — working-as-intended/duplicate | |
| - Three separable causes, none an open bug: (a) The 2021 'hang' is world-age semantics introduced in Julia 0.6 (PR #17057): Serialization defines the deserialized closure's type/method in Serialization.__deserialized_types | |
| - *Fixed/changed:* Not a regression. Perf ratio (~18x) unchanged 2015 (0.4-dev) -> 1.14-DEV. The 'hang' appeared with Julia 0.6 world-age semantics (#17057) and is an intended semantic change exposed by the pre-0.6 repro script. | |
| - [ ] [#20939](https://github.com/JuliaLang/julia/issues/20939) **Suboptimal code generation for static arrays due to failure to hoist array pointer** — no longer reproduces | |
| - The 2017 complaint was that loads from immutable custom-type memory carried no TBAA/aliasing metadata, unlike Base Array's special-cased jtbaa_arraysize/jtbaa_arrayptr tags, so LICM could not hoist loop-invariant static- | |
| - *Fixed/changed:* Not a regression. Broken in 0.6-dev (2017, LLVM 3.9 era); verified fixed by julia 1.6 (oldest channel available) through current master — the size-load hoists and vectorizes identically on 1.6, 1.14-DEV, and the HEAD build. | |
| - [ ] [#24717](https://github.com/JuliaLang/julia/issues/24717) **Pipe objects have lost their asyncness** — no longer reproduces | |
| - The 2017 bug was real: after commit 2fdc182b, spawn pipes were created without the async flag (no O_NONBLOCK / no FILE_FLAG_OVERLAPPED) and Julia-side I/O on them blocked the OS thread. It was fixed by two 2018 changes: | |
| - *Fixed/changed:* Broken between 2fdc182b (2016/0.6-era) and the 2018 fixes; fixed on master since f60dd6103c (2018-02, pre-1.0 libuv v2 upgrade) + b55b85cd99 (#30278, v1.1). Verified async on 1.6 through 1.14-DEV HEAD. | |
| - [ ] [#25880](https://github.com/JuliaLang/julia/issues/25880) **Double change event with FileWatching on OS X** — working-as-intended/duplicate | |
| - Not a Julia bug: OS file-watching backends (inotify on Linux, FSEvents/kqueue on macOS via libuv uv_fs_event) deliver one notification per underlying filesystem operation, and one logical 'save' consists of several opera | |
| - *Fixed/changed:* Not a regression; inherent behavior of every OS file-event API, present in all Julia versions and observable on Linux master today. | |
| - [ ] [#27270](https://github.com/JuliaLang/julia/issues/27270) **Changes in behavior of `@allocated` with `.=` in `@testset`** — working-as-intended/duplicate | |
| - Two stacked mechanisms. (1) `a .= b` lowers to `Base.materialize!(a, Base.broadcasted(identity, b))`; when those calls are dynamically dispatched, the intermediate `Broadcasted{DefaultArrayStyle{0}}(identity, (1.0,), not | |
| - *Fixed/changed:* Testset case: 0 bytes in 1.10 and 1.11 -> 16 bytes since 1.12 (caused by 034e6093c5, JuliaLang/julia#56509). Plain-global-scope `a .= b` reports 16 bytes on all of 1.10-1.14 (unchanged, expected for untyped globals). Original 0.7 report was 3408 bytes. | |
| - [ ] [#27599](https://github.com/JuliaLang/julia/issues/27599) **defining a few constructor methods gives 2x import slowdown** — no longer reproduces | |
| - Historical: in 0.6/0.7 (2018), inserting a constructor applicable to `Type{T} where T<:Union{Number,Dict,Tuple,...}` invalidated every generic `T(::Any)`-shaped call site (e.g. `Dict(x)`, `Tuple(itr)`, `Symbol(x)`) acros | |
| - *Fixed/changed:* Broken in 0.6/0.7 (2018 report: 10s -> 20s load). Fixed by the v1.5-v1.6 invalidation overhaul (Base invalidation-hardening per #35907, precise method-insertion invalidation) plus 1.9 pkgimages; verified negligible (<= 3 ms delta) on 1.10 and on current master 1.14-DEV. | |
| - [ ] [#27937](https://github.com/JuliaLang/julia/issues/27937) **Autocompleted paths which include whitespaces may lead to errors** — no longer reproduces | |
| - Historical bug: pre-1.4 REPL path completion applied shell-style escaping (backslash before spaces) to completions regardless of context, so completions inserted into a double-quoted string literal contained `\ `, an inv | |
| - *Fixed/changed:* Broken in 0.7-1.3 (invalid `\ ` escapes in string context); fixed since 1.4 by #33816. Verified correct on 1.10, 1.11, 1.12, 1.13, and 1.14-DEV nightly. | |
| - [ ] [#28086](https://github.com/JuliaLang/julia/issues/28086) **Test.has_unbound_vars should show some respect for history** — working-as-intended/duplicate | |
| - has_unbound_vars (stdlib/Test/src/Test.jl:2796-2805) delegates to Core.Compiler.constrains_param (Compiler/src/inferencestate.jl:730-777). For the NTuple form, the Vararg branch at inferencestate.jl:760-764 correctly ref | |
| - *Fixed/changed:* Not a regression. Main example behaves identically 0.7 through 1.14-DEV (correctly flagged). The residual foo4 case returns false (correct) on every tested release 1.6-1.14-DEV; the isType refinement landed in b5d17ea2b3 (#46791). | |
| - [ ] [#29601](https://github.com/JuliaLang/julia/issues/29601) **llvmcall is not compatible with compile-all** — no longer reproduces | |
| - The 2018 crash site matches exactly: in the Oct-2018 master (e20d1ee686), src/ccall.cpp:958 is `if (jl_is_type_type(att))` in emit_llvmcall, where `att` came from `jl_arrayref((jl_array_t*)ctx.source->ssavaluetypes, ((jl | |
| - *Fixed/changed:* Broken in 1.0-1.4 era (issue reported on 1.0/1.1/2018 master); fixed by 3b53f54a5e (JuliaLang/julia#25984), first released in v1.5.0 (2020). Not reproducible on any currently supported release. | |
| - [ ] [#29876](https://github.com/JuliaLang/julia/issues/29876) **Pending node location incorrect in IRShow if attached after** — no longer reproduces | |
| - Historical bug in the IR pretty-printer: the pending-node iterator in base/compiler/ssair/show.jl ignored the attach_after flag of NewNodeInfo entries and emitted every pending node before the statement it was attached t | |
| - *Fixed/changed:* Broken through 1.8; fixed in 1.9.0 by PR #47092 (verified: julia 1.8 shows attach-after node before the statement; julia 1.9 and current master show it after) | |
| - [ ] [#30087](https://github.com/JuliaLang/julia/issues/30087) **Fallback for `JL_HAVE_UCONTEXT` task-switching broken** — no longer reproduces | |
| - Historical bug: in the 2018 (v1.0/1.1-era) src/task.c, the JL_HAVE_UCONTEXT fallback declared jl_ucontext_t as the system ucontext_t but ctx_switch still called jl_setjmp(lastt->ctx.uc_mcontext, 0), passing the system mc | |
| - *Fixed/changed:* Broken in 2018 (v0.7/1.0 era) on PPC only; PPC64 fast path added by #30820 (Jan 2019, ~v1.2-dev); the broken ucontext fallback itself removed entirely by #54911 (Nov 2025, 1.13-dev/1.14-dev). No supported configuration on master can select a ucontext-based switch on POSIX. | |
| - [ ] [#30686](https://github.com/JuliaLang/julia/issues/30686) **type-instability with repeat and cat?** — working-as-intended/duplicate | |
| - Not a compiler bug — the return types genuinely depend on runtime values, which Julia's type system cannot express. (1) `d = fill(1, s+1)` is a Vector{Int} whose length is not part of its type; `repeat(a, d...)` therefor | |
| - *Fixed/changed:* Not a regression. Core cases unstable on all versions 1.6 through 1.14-DEV by necessity; the fixable sub-case (constant dims, fixed arity: cat(x,x,dims=3)) infers concretely since 1.10 (Any on 1.6/1.8/1.9). | |
| - [ ] [#30744](https://github.com/JuliaLang/julia/issues/30744) **Slow compilation and segfault with recursion on highly nested struct** — no longer reproduces | |
| - Historical pathology, not a live bug: deeply nested 'linked-list' transducer composition types (Composition{TeeZip{...{Scan{...}}}} nested ~10 levels) caused Julia 1.0/1.1-era inference to specialize enormous recursive c | |
| - *Fixed/changed:* Broken on 1.0.3/1.1 era (LLVM 6.0, per issue). Already fixed by 1.6.7 (oldest juliaup channel available in sandbox); fix landed somewhere in 1.2-1.5, most plausibly the 1.3 inference recursion-detection rework (#31191). Fine on 1.6 and 1.14-DEV/master d38fa1c7fb. | |
| - [ ] [#30819](https://github.com/JuliaLang/julia/issues/30819) **Profiler is incorrectly printing multiple stacks, b/c of a break in the backtrace** — no longer reproduces | |
| - In Julia 1.1-1.3, interpreter frames were flagged in bt_data with the raw sentinel JL_BT_INTERP_FRAME == (uintptr_t)0-1, and adjacent words of the interpreter-frame encoding (or a call_ip that decremented to 0) could app | |
| - *Fixed/changed:* Broken in 1.1-1.3 (as reported); fixed in v1.4.0 by #33277 (commit 643ec188c2, git tag --contains confirms v1.4.0-rc1 is the first release). Verified fixed on 1.6.7, 1.10.11, and current master d38fa1c7fb. | |
| - [ ] [#32153](https://github.com/JuliaLang/julia/issues/32153) **[PPC] Getindex on Atomic{Float64} or Atomic{Float32}** — no longer reproduces | |
| - Upstream LLVM PowerPC backend bug, not a Julia bug. For acquire (or stronger) atomic loads, PPCTargetLowering::emitTrailingFence emits the llvm.ppc.cfence intrinsic parameterized on the loaded value's type to build the ' | |
| - *Fixed/changed:* Broken on ppc64le for all Julia versions using LLVM <= 14 (Julia <= 1.9). Fixed by upstream LLVM 15 (June 2022 commits ad2f7fd2 / 6710b21d), i.e. Julia >= 1.10 (LLVM 15.0.7). Not a Julia regression. | |
| - [ ] [#32155](https://github.com/JuliaLang/julia/issues/32155) **[PPC] Segmentation fault instead of ReadOnlyMemoryException** — working-as-intended/duplicate | |
| - Two independent causes. (1) PRIMARY, a Linux kernel bug (matching the issue's 'kernel bug' label): Linux commit c3350602e876 ('powerpc/mm: Make bad_area* helper functions', v4.14) made powerpc report protection violation | |
| - *Fixed/changed:* Not a Julia regression. Kernel regression: introduced in Linux v4.14 (c3350602e876), fixed in Linux v4.20 (ecb101aed861), backported to stable v4.14+. | |
| - [ ] [#34171](https://github.com/JuliaLang/julia/issues/34171) **uv_spawn probably blocks too many signals** — no longer reproduces | |
| - libuv's uv_spawn used to sigfillset+block every signal across fork(), deferring even fatal synchronous signals; combined with macOS atfork handlers in libdispatch this could wedge or crash the child. Fixed upstream by th | |
| - *Fixed/changed:* Bug present through Julia 1.7 (libuv julia-uv2-1.42.0); fixed since Julia 1.8 (libuv julia-uv2-1.44.2 includes libuv/libuv#3251 and libuv/libuv#3257) | |
| - [ ] [#34184](https://github.com/JuliaLang/julia/issues/34184) **fatal: error thrown and no exception handler available.** — no longer reproduces | |
| - The crash was InterruptException being delivered (via the sigint safepoint, always targeted at thread 0 by jl_try_deliver_sigint in src/signals-unix.c:655) to whatever context happened to be executing on thread 0. When t | |
| - *Fixed/changed:* Not a regression. Crash reported on 1.3–1.8; already hard to reproduce on 1.8/1.10 (timing-dependent), and the underlying design gap is closed on master by the scheduler-task architecture (#57544 follow-ups) plus JuliaLang/julia#62069 (fc7ca1bcee, 2026-07-08). | |
| - [ ] [#34838](https://github.com/JuliaLang/julia/issues/34838) **Performance of CartensianIndices and Views** — no longer reproduces | |
| - The original symptom was an LLVM loop-vectorization/unrolling failure for @simd iteration over CartesianIndices of a 3D SubArray: the multi-dimensional stride arithmetic produced by SubArray getindex inside the Cartesian | |
| - *Fixed/changed:* Not a regression. 3D-view slowdown present 1.6-1.10, fixed in 1.11; 2D-view slowdown present through 1.12, fixed in 1.13; unrelated transient allocation regression in 1.12 only (fixed in 1.13); parity confirmed on 1.13.0-rc1 and master HEAD build 1.14.0-DEV.2626. | |
| - [ ] [#35269](https://github.com/JuliaLang/julia/issues/35269) **Segfault in with_tvar() in subtyping** — no longer reproduces | |
| - C-stack overflow in the subtype checker, depth linear in tuple length. During method matching for typed_vcat with 12608 splatted args, jl_type_intersection_env_s calls jl_subtype_env(Tuple{typeof(typed_vcat), Type{Union{ | |
| - *Fixed/changed:* Not a regression. Segfault present 1.4 (reported) through 1.9.4 (confirmed on 1.6, 1.8, 1.9.4). C-stack segfault fixed in 1.10 by #48578; full user script: graceful StackOverflowError on 1.9/1.10, completes successfully on 1.13 and 1.14-DEV master. | |
| - [ ] [#35698](https://github.com/JuliaLang/julia/issues/35698) **incorrect type intersection in tuples of types** — no longer reproduces | |
| - The crash was caused by an unsound Type{T}-vs-kind subtyping/intersection rule in src/subtype.c: Type{T} was matched against kinds (DataType/UnionAll/...) using only typeof(T), the tag of one representative, even though | |
| - *Fixed/changed:* Not a regression: broken from at least 1.3.1 through 1.14.0-DEV.2332 (nightly 2026-06-10); fixed on master between 4372738699 (2026-06-10) and d38fa1c7fb (2026-07-09) by PR #62263 (commit 6604df474a). | |
| - [ ] [#36023](https://github.com/JuliaLang/julia/issues/36023) **julia crashes when Pkg.up is run run pkg mode** — no longer reproduces | |
| - Missing recursion base case in `safe_realpath` in Pkg (stdlib) src/utils.jl. When a dev'ed package sits on a disconnected network drive, `find_project_file`/`EnvCache` (Pkg/src/Types.jl) call `safe_realpath("U:\\path\\to | |
| - *Fixed/changed:* Not a regression. Broken from at least 1.4 through 1.7; partially fixed in 1.8 (Pkg.jl#3087); drive-root/disconnected-network-drive case fully fixed by Pkg.jl#4313 (2025-07-07), present in current 1.10.x/1.12.x point releases via backports and on master. | |
| - [ ] [#36300](https://github.com/JuliaLang/julia/issues/36300) **`readbytes!()` returning more bytes than requested** — no longer reproduces | |
| - readbytes!(s, a, nb) for LibuvStream/BufferStream (base/stream.jl swap path, stream.jl:942-955 and :1602-1615 on master; same structure in 2020) temporarily replaces s.buffer with a PipeBuffer over the user array `a` wit | |
| - *Fixed/changed:* Broken from at least v1.4 (issue era, 2020) through v1.11.9; fixed in v1.12.0 by #57570 "Refactor IOBuffer code" (54197132f5). Confirmed empirically: bug on 1.10.11 and 1.11.9; fixed on 1.12.6, 1.13, and master d38fa1c7fb. | |
| - [ ] [#36307](https://github.com/JuliaLang/julia/issues/36307) **Argument order has a great impact on performance with maximum function** — working-as-intended/duplicate | |
| - Julia's intentional despecialization heuristic for non-called Function arguments, combined with an 8-argument limit that makes it argument-position-dependent. In src/gf.c, jl_compilation_sig (lines 1377-1386) and jl_isa_ | |
| - *Fixed/changed:* Not a regression: same behavior in 1.4/1.5 per the issue and on 2026-07-09 master; heuristic predates 1.0. | |
| - [ ] [#36868](https://github.com/JuliaLang/julia/issues/36868) **determine where to use release stores in task system** — no longer reproduces | |
| - Historical, now resolved. At issue-filing time (2020) jl_finish_task already used jl_atomic_store_release on the state field (present in v1.5.0, src/task.c:181-183 there), but the Julia-side readers used a plain load of | |
| - *Fixed/changed:* Not a regression. Reader-side acquire added in 1.6 (PR #38557, Dec 2020); migration synchronization in 1.7 (PR #40715); formal @atomic _state field in 1.12 (PR #55502). | |
| - [ ] [#37344](https://github.com/JuliaLang/julia/issues/37344) **SSAValue leaking into error message** — no longer reproduces | |
| - In flisp lowering (src/julia-syntax.scm), expand-assignment used a local function-lhs? predicate that did NOT recognize (:: (where (call f ...) T) (curly Q T)) as a function definition. The LHS fell into the generic x::T | |
| - *Fixed/changed:* Broken in all tested releases 1.6-1.13 (SSAValue leaks); fixed on master since d569d072ab (PR #62067, 2026-06-11), clean in 1.14-DEV. | |
| - [ ] [#37614](https://github.com/JuliaLang/julia/issues/37614) **poor performance of `Base.repeat` for inner repetition along first dimension** — no longer reproduces | |
| - Two successive fixes, neither issue-specific. (1) The huge allocation counts and 1D slowness on 1.5 were fixed by the repeat rewrite in JuliaLang/julia#35944 (base/abstractarraymath.jl, the Base._RepeatInnerOuter module | |
| - *Fixed/changed:* Not a regression. 1D + allocation blowup fixed in 1.6 (JuliaLang/julia#35944); 2D residual ~2.2-2.5x slowdown persisted through 1.10.11 and was fixed between 1.10 and 1.11 (1.11.9 ratio 0.92); parity holds on current master. | |
| - [ ] [#38006](https://github.com/JuliaLang/julia/issues/38006) **Tab completion on `a[1].` should use propertynames if defined (or return nothing)** — no longer reproduces | |
| - Historic behavior (<=1.9): REPLCompletions only had the static type of `array[1]` and unconditionally completed with fieldnames, ignoring propertynames overloads, and called propertynames without a try/catch so a throwin | |
| - *Fixed/changed:* Original bug present 1.5-1.9; `array[1].` fixed in 1.10 by #49206 (REPLInterpreter concrete evaluation); type-only false-positive fieldnames and uncaught-exception keymap crash fixed in 1.11 by #51502 (field_completion_eligible) and the try/catch around propertynames. Verified: 1.9 wrong, 1.10/1.11/master correct. | |
| - [ ] [#38095](https://github.com/JuliaLang/julia/issues/38095) **precompile seems too picky about unspecialized kwfunc signatures** — no longer reproduces | |
| - The historic failure is in jl_get_compile_hint_specialization (src/gf.c; jl_compile_hint -> jl_get_compile_hint_specialization). When jl_matching_methods returns >1 match, the function filters matches with jl_isa_compile | |
| - *Fixed/changed:* Broken in 1.6-1.8; worked in 1.9 (lowering declared kwcall kw-slot as Any); broken again in 1.10-1.11 (kw-slot declared NamedTuple); fixed since 1.12 (ml_matches dispatch_status pruning, ~JuliaLang/julia#58291/#58335 timeframe). | |
| - [ ] [#38195](https://github.com/JuliaLang/julia/issues/38195) **"Error showing value of type: `type TypeVar has no field var`" - error displaying MethodInstance encountered from `MathOptInterface`** — no longer reproduces | |
| - Two-part bug, both parts since fixed. (1) show side: in <=1.6-DEV-Nov-2020 base/show.jl, show(io, ::UnionAll) renamed conflicting typevars via `newtv = TypeVar(newname, x.var.lb, x.var.ub); x = UnionAll(newtv, x{newtv})` | |
| - *Fixed/changed:* Broken in 1.5.x and 1.6-DEV as of Nov 2020; fixed before v1.6.0 release by PR JuliaLang/julia#39366 (commit ee816ef4f2 'show: consolidate wheres with {} in printing', merged 2021-01-25), which rewrote show(io, ::UnionAll) to substitute via `x = x{var}` and collect a `wheres::Vector{TypeVar}` list (now base/show.jl:1076-1104), eliminating the `UnionAll(newtv, x{newtv})` re-wrap and the `x.var` access entirely. Verified fixed on 1.6.7 through master. | |
| - [ ] [#38632](https://github.com/JuliaLang/julia/issues/38632) **IR verification error during test-suite** — no longer reproduces | |
| - Localized by running the 1.6 optimizer pipeline manually with verify_ir between every pass: IR is valid after slot2reg, compact1, inlining, compact2, SROA, ADCE, and becomes invalid only after type_lift_pass! + the final | |
| - *Fixed/changed:* Not a regression: broken at least 1.3-1.6 (confirmed on 1.6.7 with -g2); fixed in 1.7.0 (likely bd5105e0ee / #39540); the offending type_lift_pass! was deleted entirely in 1.10 (#50257) | |
| - [ ] [#38813](https://github.com/JuliaLang/julia/issues/38813) **superslow `using` when active project is on high latency network** — no longer reproduces | |
| - Pre-1.7 code loading in base/loading.jl was stateless per query: every identify_package/locate_package/env lookup during a single `require` re-walked the load path, re-called env_project_file/isfile_casesensitive and re- | |
| - *Fixed/changed:* Broken in <=1.6 (89 Project.toml metadata ops for a 10-dep package, scaling with dependency count); fixed since 1.7.0 (constant 7; master constant 12 regardless of dep count). Fixed by #40890. | |
| - [ ] [#39006](https://github.com/JuliaLang/julia/issues/39006) **`jl_sigint_safepoint()` causes segfault if run too early** — no longer reproduces | |
| - Original 2020 crash: in _julia_init, init_stdio() ran long before jl_init_threading/jl_init_threadtls, so JL_STDERR was a real libuv stream while ptls->safepoint was still NULL (it is only pointed into the mmapped jl_saf | |
| - *Fixed/changed:* Crashed on 1.6-era master (issue filed 2020-12); fixed in v1.7.0 by JuliaLang/julia#40715 (jl_uv_puts/jl_fs_write ct==NULL fallback to raw fd write); still fixed on current master (verified empirically against the HEAD build). | |
| - [ ] [#39307](https://github.com/JuliaLang/julia/issues/39307) **coverage marks local and let without assignment as uncovered** — no longer reproduces | |
| - Pre-1.12 codegen registered every entry of the lowered code's linetable as a coverable line: src/codegen.cpp (pre-#52415) had `// record all lines that could be covered: for (const auto &info : linetable) jl_coverage_all | |
| - *Fixed/changed:* Bug present 1.5 through 1.11; fixed in 1.12.0 by #52415 (6f143eaf24, 'invert linetable representation'), with related coverage fixes in #53354 (61fc907a22) | |
| - [ ] [#39699](https://github.com/JuliaLang/julia/issues/39699) **EXCEPTION_ACCESS_VIOLATION when interrupting a non-interactive readline** — no longer reproduces | |
| - Non-interactive runs set exit_on_sigint(true) (base/client.jl:349). On Windows, Ctrl+C runs sigint_handler (src/signals-win.c, SetConsoleCtrlHandler) on a brand-new OS thread spawned by Windows that has no Julia TLS (ptl | |
| - *Fixed/changed:* Broken in 1.5.1 and 1.6.7 (both reports; all <=1.8 affected per v1.8.5 src/init.c). Fixed since v1.9.0 (jl_atexit_hook adopts the calling foreign thread via jl_adopt_thread). | |
| - [ ] [#40630](https://github.com/JuliaLang/julia/issues/40630) **`Threads.resize_nthreads!` can take a significant time to infer** — no longer reproduces | |
| - The latency was inference/compilation of deepcopy inside resize_nthreads! (base/deprecated.jl:492-500, `A[i] = deepcopy(copyvalue)` at line 497). deepcopy's implementation (base/deepcopy.jl) recurses through deepcopy_int | |
| - *Fixed/changed:* Not a regression. Intrinsic per-type compile cost is similar on 1.6 (~50ms) and master (~42ms); the ecosystem-level symptom disappeared when HTTP.jl/URIs.jl dropped the calls and Julia 1.9 deprecated the function and added native code caching. | |
| - [ ] [#40712](https://github.com/JuliaLang/julia/issues/40712) **Performance gap between foreach and map if the function may throw an error** — no longer reproduces | |
| - Two distinct sub-cases. Case 1 (the reported bug): foreach's generic definition `foreach(f, itr, itrs...) = (for z in zip(itr, itrs...); f(z...); end; nothing)` (base/abstractarray.jl:3285) failed to fully optimize throu | |
| - *Fixed/changed:* Not a regression. Case 1 (foreach slower when f may throw): broken 1.6 through 1.11.9, fixed in 1.12.0 (verified 1.10.11 and 1.11.9 bad, 1.12.6 and 1.14-DEV good). Case 2 gap is by-design in all versions. | |
| - [ ] [#40922](https://github.com/JuliaLang/julia/issues/40922) **ifelse with non-primitive types prevents SIMD** — no longer reproduces | |
| - The symptom was an LLVM limitation, exactly as the OP suspected: Julia codegen for ifelse on an aggregate emits 'select i1 %cond, [2 x double] %a, [2 x double] %b' (emitted in src/codegen.cpp for the ifelse builtin), and | |
| - *Fixed/changed:* Not a regression. Broken 1.7-1.10 (verified 1.8, 1.9, 1.10 on LLVM <= 15); fixed since 1.11 (LLVM 16.0.6). Verified still fixed on master d38fa1c7fb. | |
| - [ ] [#41043](https://github.com/JuliaLang/julia/issues/41043) **Missing coverage for macros that add new lines** — no longer reproduces | |
| - Coverage is now emitted by codegen from per-statement DebugInfo locations (coverageVisitStmt at src/codegen.cpp:9635-9652 and record_line_exists at src/codegen.cpp:9662-9698), not by lowering-inserted code_coverage_effec | |
| - *Fixed/changed:* Not a regression — behavior improved over time. 1.6–1.9: macro quote line counted 1 but call-site line showed 0 (missed) = the reported bug. 1.10–1.11: both lines 0 (missed). 1.12+ (via #52415): call-site + macro lines count 1 for real code; constant-only bodies changed from 0 (missed) to '-' (excluded) via #53354 + #52415's all-zero-codelocs compression. | |
| - [ ] [#41768](https://github.com/JuliaLang/julia/issues/41768) **Julia 1.6.1, stat on ubuntu on termux (ARMv8 Linux) doesn't work** — working-as-intended/duplicate | |
| - Two independent causes, both environmental (Android/Termux proot), one with a small Julia-side hardening opportunity. (1) stat-returns-zeros: Termux's proot did not intercept/emulate the statx syscall (termux/proot#122, | |
| - *Fixed/changed:* Not a Julia regression. Environment bug present with any Julia on termux/proot builds lacking statx emulation (pre termux/proot Oct-2020, fully fixed upstream by late 2021). Julia stat() error handling verified identical-in-behavior from 1.6.1 through current master (master refactored to StatStruct.ioerrno/checkstat in e500754118, 1.12). | |
| - [ ] [#42200](https://github.com/JuliaLang/julia/issues/42200) **LLVM error "ran out of registers during register allocation" on 32-bit x86 with code-coverage** — no longer reproduces | |
| - Original bug was in LLVM's X86 backend (greedy register allocator), not Julia: on i686 with AVX-512-era target features (tigerlake/skylake-avx512 — hence 'Intel CPUs only' since AMD CI hosts of that era lacked AVX-512), | |
| - *Fixed/changed:* Broken (per reporters): 1.5.4-1.8-DEV on Linux+Windows (LLVM 9-13), 1.10.3 and 1.12.0-DEV.462 on Windows/Intel (LLVM 15/17, May 2024). This investigation: NOT reproducible on Linux i686 in 1.10.10, 1.11.9, 1.12.6, nor with master's LLVM 21 on any IR variant. Windows i686 on >=1.12 (atomicrmw coverage + LLVM>=18) has never been reported broken. | |
| - [ ] [#42258](https://github.com/JuliaLang/julia/issues/42258) **optimizer: `ssaflags` validation after optimization ?** — no longer reproduces | |
| - Historical, two-part. Part 1 ('first skew'): statements/flags arrays went out of sync because coverage-statement insertion set ssaflags wrongly (fixed by merged PR #42260) and `type_annotate!` deleted statements without | |
| - *Fixed/changed:* Not a regression. Flag existed 1.6-1.11; flag and the deoptimization it fed removed in 1.12 by #49260. | |
| - [ ] [#42562](https://github.com/JuliaLang/julia/issues/42562) **[Distributed] `Future`s not being cleaned up fast enough bring the execution to a stop/huge slowdown due to GC livelocks** — no longer reproduces | |
| - Historical livelock between WeakKeyDict locking and finalizers in the Distributed Future path. In the 2021 code, finalize_ref(::AbstractRemoteRef) called delete!(client_refs, r) which took the WeakKeyDict lock; unlock re | |
| - *Fixed/changed:* Broken in 1.8-DEV as of Oct 2021 (and earlier releases); fixed by julia#38180 + julia#41846 + julia#42339, all included in the 1.8.0 release. Verified working on 1.8 release and current master (d38fa1c7fb). | |
| - [ ] [#42866](https://github.com/JuliaLang/julia/issues/42866) **make debug fails when cross-compiling Julia for Windows on Linux** — no longer reproduces | |
| - Two stacked causes, both external to current master. (1) Primary crash: a bug in old Wine's (5.0-era) RtlVirtualUnwind implementation, hit from Julia's Windows unwinder jl_unw_step (src/stackwalk.c:726, RtlVirtualUnwind | |
| - *Fixed/changed:* Not a Julia regression. Broken with Wine 5.0 (Ubuntu 20.04); works with newer Wine (Wine_jll, ~7.x, per reporter 2022-03-13). Julia-side residual parsing bug fixed on master by 626f3b20ef (#47352), first released in 1.9. | |
| - [ ] [#43138](https://github.com/JuliaLang/julia/issues/43138) **IR structure in `count` blocks vectorization** — no longer reproduces | |
| - The issue (filed by JeffBezanson off vtjnash's diagnosis in JuliaLang/julia#40564 (comment 825823534)) was that ir_inline_unionsplit! emitted, for a fully-covered union split like ismissing(::Union{Int,Missing}), an isa | |
| - *Fixed/changed:* Broken in 1.6 (the version the referenced benchmark was run on); already fast in 1.7.0 and every later release except an unrelated 1.10-only slowdown (affecting even the generator/function-barrier path) that was fixed in 1.11. | |
| - [ ] [#43237](https://github.com/JuliaLang/julia/issues/43237) **Code coverage does not track `@static` properly** — no longer reproduces | |
| - On <=1.11, flisp lowering created a LineInfoNode linetable entry for every LineNumberNode in the source, including the `@static if ...` macrocall line, even though the macro expansion contains no statement located on tha | |
| - *Fixed/changed:* Broken in 1.6-1.11 (as reported in 2021); fixed in 1.12.0+ by #52415 (invert linetable representation, commit 6f143eaf24, March 2024). Not a regression — a long-standing bug that has since been fixed. | |
| - [ ] [#44559](https://github.com/JuliaLang/julia/issues/44559) **StackOverflowError in test/core.jl with ASAN** — no longer reproduces | |
| - C-stack exhaustion, not a logic bug: lowering/evaluating the 512-field `struct Array_512_Uint8` (test/core.jl:2831 in the 2022 tree) on a Distributed worker task whose stack was JL_STACK_SIZE = 4MB (src/options.h, pre-Au | |
| - *Fixed/changed:* Not a regression. Broken in 1.9-DEV as of 2022-03 (4MB task stacks under ASAN); fixed by JuliaLang/julia#46336 (9f78e04e74, 2022-08-17, in 1.9.0-beta1) which gives ASAN/MSAN builds 64MB task stacks. | |
| - [ ] [#45055](https://github.com/JuliaLang/julia/issues/45055) **Capture SIGINT with @async, in a script or in the REPL** — no longer reproduces | |
| - SIGINT is always raised on thread 1's currently-running task. In script mode that thread is almost never running user code: in 1.8-1.13 the freshly-finished `@async` task blocks inside task_done_hook -> wait -> poptask - | |
| - *Fixed/changed:* worked in 1.7.2; broken in scripts since 1.8/1.9 (fatal no-exc-handler abort, reproduced 100% on 1.11.9, 1.12, 1.13.0-rc1); on pre-2026-07-08 1.14 nightlies the interrupt was silently dropped instead (#58689); fixed on master since fc7ca1bcee (PR #62069, 2026-07-08) | |
| - [ ] [#45569](https://github.com/JuliaLang/julia/issues/45569) **Redirecting `stderr` in a `pipeline` leads to broken Profile stacktrace** — no longer reproduces | |
| - Not a profiler backtrace-stitching bug per se: before PR #57544, when every task on a thread was blocked, the thread slept inside jl_task_get_next/poptask while still executing on the stack of the *last task that called | |
| - *Fixed/changed:* Broken as reported in 1.7, 1.8, 1.10, 1.11, 1.12, 1.13.0-rc1 (mitigated from 1.8 on via Profile.print(groupby=:task)). Fixed on master / 1.14-DEV by #57544 (0d4d6d927d), which was reverted from release-1.13 so 1.13 still shows the old behavior. | |
| - [ ] [#45929](https://github.com/JuliaLang/julia/issues/45929) **Regression: System time is twice as slow vs 1.7.0** — no longer reproduces | |
| - julia#45412 (first released in 1.8.0, present in the 1.9-DEV the reporter tested) added to LinearAlgebra.__init__: `BLAS.set_num_threads(max(1, Sys.CPU_THREADS ÷ 2))` when OPENBLAS_NUM_THREADS/GOTO_NUM_THREADS/OMP_NUM_TH | |
| - *Fixed/changed:* Introduced by julia#45412 (LinearAlgebra.__init__ default BLAS.set_num_threads(Sys.CPU_THREADS÷2)), first in 1.8.0/1.9-DEV; sys-time symptom present 1.8-1.10; converted to user-time spin in 1.11-1.12 (OpenBLAS 0.3.27 idle-wait change); fully fixed in 1.13+ by lazy OpenBLAS loading via LBT on-load callback (verified fixed on master d38fa1c7fb, OpenBLAS 0.3.33). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment