Skip to content

Emit deprecation warnings without switching tasks.#831

Merged
maleadt merged 2 commits into
mainfrom
tb/safe_depwarn
Jun 5, 2026
Merged

Emit deprecation warnings without switching tasks.#831
maleadt merged 2 commits into
mainfrom
tb/safe_depwarn

Conversation

@maleadt
Copy link
Copy Markdown
Member

@maleadt maleadt commented Jun 4, 2026

Base.depwarn logs through the active logger, and the I/O involved can switch tasks. That is illegal while holding the typeinf lock, which our @locked compilation entry points do on Julia 1.10/1.11, and caused hangs (#830).

Replace it with safe_depwarn, which writes the warning synchronously to Core.stderr like @safe_warn does. Caller attribution, warning once per call site, and throwing under --depwarn=error still behave like Base.depwarn; on 1.12+, where compilation doesn't hold the typeinf lock, it just forwards there.

Closes #831

`Base.depwarn` logs through the active logger, and the I/O involved can
switch tasks. That is illegal while holding the typeinf lock, which our
`@locked` compilation entry points do on Julia 1.10/1.11, and caused
hangs (#830).

Replace it with `safe_depwarn`, which writes the warning synchronously
to `Core.stderr` like `@safe_warn` does. Caller attribution, warning
once per call site, and throwing under `--depwarn=error` still behave
like `Base.depwarn`; on 1.12+, where compilation doesn't hold the
typeinf lock, it just forwards there.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 4, 2026

Codecov Report

❌ Patch coverage is 67.74194% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.36%. Comparing base (a0d1302) to head (68043ee).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/driver.jl 0.00% 4 Missing ⚠️
src/deprecated.jl 0.00% 3 Missing ⚠️
src/irgen.jl 0.00% 2 Missing ⚠️
src/utils.jl 95.45% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #831      +/-   ##
==========================================
+ Coverage   79.28%   79.36%   +0.07%     
==========================================
  Files          25       25              
  Lines        4562     4584      +22     
==========================================
+ Hits         3617     3638      +21     
- Misses        945      946       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

The call-site dedup set was typed too narrowly: interpreted call sites
(e.g., calls from top-level scope) are identified by a Base.InterpreterIP
rather than a plain instruction pointer, making safe_depwarn throw a
conversion error. Widen the set's key type, and add a regression test.

Also avoid unqualified `findall` in the new testset: it resolved the
binding to Base.findall, silently breaking the later import of
Core.Compiler.findall used by the StackedMethodTable tests on 1.10/1.11.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@maleadt maleadt merged commit 81a0987 into main Jun 5, 2026
35 of 37 checks passed
@maleadt maleadt deleted the tb/safe_depwarn branch June 5, 2026 06:57
@simeonschaub
Copy link
Copy Markdown
Member

Thanks, that's a much better solution! Would you mind also bumping the GPUCompiler version as well as the CUDA compat, so we can fix CoolPDLP CI?

@maleadt
Copy link
Copy Markdown
Member Author

maleadt commented Jun 5, 2026

as well as the CUDA compat

Releasing CUDA.jl is quite a bit of effort, and won't happen right away. Or what do you mean?

@simeonschaub
Copy link
Copy Markdown
Member

I mean that the currently released CUDA version does not seem to be compatible with GPUCompiler 1.18. If I install the latest release of CUDA.jl inside an environment and then try to add GPUCompiler#main, I get:

    Updating git-repo `https://github.com/JuliaGPU/GPUCompiler.jl.git`
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package CUDACore [bd0ed864]:
 CUDACore [bd0ed864] log:
 ├─possible versions are: 6.0.1 - 6.1.1 or uninstalled
 ├─restricted by compatibility requirements with GPUCompiler [61eb1bfa] to versions: uninstalled
 │ └─GPUCompiler [61eb1bfa] log:
 │   ├─possible versions are: 1.18.0 or uninstalled
 │   └─GPUCompiler [61eb1bfa] is fixed to version 1.18.0
 └─required (without additional version restrictions) by CUDA [052768ef]
   └─CUDA [052768ef] log:
     ├─possible versions are: 0.1.0 - 6.1.0 or uninstalled
     ├─restricted to versions * by project [0dc50556], leaving only versions: 0.1.0 - 6.1.0
     │ └─project [0dc50556] log:
     │   ├─possible versions are: 0.0.0 or uninstalled
     │   └─project [0dc50556] is fixed to version 0.0.0
     ├─restricted by julia compatibility requirements to versions: [2.3.0, 2.5.0 - 6.1.0] or uninstalled, leaving only versions: [2.3.0, 2.5.0 - 6.1.0]
     ├─restricted by compatibility requirements with LLVM [929cbde3] to versions: 5.5.0 - 6.1.0 or uninstalled, leaving only versions: 5.5.0 - 6.1.0
     │ └─LLVM [929cbde3] log:
     │   ├─possible versions are: 0.9.0 - 9.8.2 or uninstalled
     │   └─restricted to versions 9.8.1 - 9 by GPUCompiler [61eb1bfa], leaving only versions: 9.8.1 - 9.8.2
     │     └─GPUCompiler [61eb1bfa] log: see above
     └─restricted by compatibility requirements with GPUCompiler [61eb1bfa] to versions: 6.0.0 - 6.1.0 or uninstalled, leaving only versions: 6.0.0 - 6.1.0
       └─GPUCompiler [61eb1bfa] log: see above

Is there a reason CUDA.jl declares such strict compat bounds for GPUCompiler?

@maleadt
Copy link
Copy Markdown
Member Author

maleadt commented Jun 5, 2026

Yes, GPUCompiler switched to llc from LLVM 22, while older versions were using the in-process one. This prompted retroactively changing compat bounds: JuliaRegistries/General@67cd467
Normally we don't have to do this, and play by semver, but this was an exception (not worth tagging a breaking release for).

@simeonschaub
Copy link
Copy Markdown
Member

Ah, I see! Any ETA when CUDA will be compatible with the latest GPUCompiler again?

@simeonschaub
Copy link
Copy Markdown
Member

Since this is a bugfix, should we perhaps backport this to GPUCompiler 1.17?

@maleadt
Copy link
Copy Markdown
Member Author

maleadt commented Jun 5, 2026

Yes, backporting would be fine too.

maleadt added a commit that referenced this pull request Jun 5, 2026
`Base.depwarn` logs through the active logger, and the I/O involved can
switch tasks. That is illegal while holding the typeinf lock, which our
`@locked` compilation entry points do on Julia 1.10/1.11, and caused
hangs (#830).

Replace it with `safe_depwarn`, which writes the warning synchronously
to `Core.stderr` like `@safe_warn` does. Caller attribution, warning
once per call site, and throwing under `--depwarn=error` still behave
like `Base.depwarn`; on 1.12+, where compilation doesn't hold the
typeinf lock, it just forwards there.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants