-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement a julia specific debug mode with --debug
#53404
base: master
Are you sure you want to change the base?
Conversation
This PR adds a new flag to control when a "julia specific" debug mode is active. When the debug mode is active the following happens: - The `@assert` macro is active - The `isdebug` function returns `true`. Currently, the `--debug` has three options: - `"yes"`: debug mode is active in scripts and packages - `"script": debug mode is active in scripts - `"no": debug is not active anywhere The debug mode is a "compile time option" meaning that it will recompile packages if it changes.
For me these should be separate things (I may need to troubleshoot debug-information emission with ot without |
@@ -218,6 +219,9 @@ julia> @assert isodd(3) "What even are numbers?" | |||
``` | |||
""" | |||
macro assert(ex, msgs...) | |||
enable_asserts = !isdefined(Main, :Base) || Main.Base.julia_debug |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
!isdefined(Main, :Base)
I assume this is the canonical way to check if something is running as a script? possibly should factor that out into an independent iscurrentscript
function somewhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not checking if it is a script actually, it is making sure that asserts are emitted when e.g. building the compiler (and Base
is not defined).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha
just to lightning round
only if Julia was started with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sensible.
The only design alternative I see is to use a preference to allow fine-grained per package setting of this flag. E.g. a user may want to set debug for Enzyme, but not for anything else.
@@ -121,6 +121,23 @@ function setpropertyonce!(x::Module, f::Symbol, desired, success_order::Symbol=: | |||
return Core.setglobalonce!(x, f, val, success_order, fail_order) | |||
end | |||
|
|||
julia_debug::Bool = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes me a bit nervous to have a compiler time setting that I can easily change by writing a global.
In theory one could have something like |
Yeah... I was thinking
But we would need to reserve the preference name. Lookup without depending on Preferences.jl would be:
But that might be too extra for this. |
Your mentioning of What should be the semantics w.r.t Base/Core? We could use For the runtime we use I have been wondering if we should provide pre-built binaries for |
👍 |
I'm wondering if it would make sense to make it changeable at runtime. For example if I set up a function with a bunch of function f(x)
@assert properties(x)
sum(square, x)
end
@test f([0]) == 0
disabling_asserts() do
Optim.optimize(f, ...)
end |
Maybe, but this also adds an |
This PR adds a new flag to control when a "julia specific" debug mode is active. When the debug mode is active the following happens:
@assert
macro is activeisdebug
function returnstrue
.Currently, the
--debug
has three options:"yes"
: debug mode is active in scripts and packages"script"
: debug mode is active in scripts (default)"no"
: debug is not active anywhereThe debug mode is a "compile time option" meaning that it will recompile packages if it changes.
There are still many open questions regarding this:
-g
and coexist with the current behavior of-g
or should it just steal it?Pkg.test
should assertions be enabled everywhere or only in the tested package etc?--debug
has any influence on--check-bounds
?Subsumes #37874
Ref #41342, #53223