I don't think we can really have a runtime flag that affects how Base is parsed, because we cache compiled code to improve startup time. How is theese problems solved with --check-bounds and --int-literals?
kl. 15:36:42 UTC+2 fredag 25. juli 2014 skrev Magnus Lie Hetland følgende: > > Looks interesting! Haven't quite absorbed it yet, though :-} > > Wrote a simple implementation of a switch (trying to follow the style of > what's already in client.jl), and then use the corresponding config value > to determine the definition of assert and @assert. However … my > straightforward approach would require the code in client.jl to be > executed before that of error.jl, which it isn't. Should/could I somehow > trigger a redefinition once the code in client.jl has been run? > > I'm working on a kind of a solution now, but it seems a bit iffy. A > summary: > > - I've defined use_assertions and useassertions() – similar to other > flags in client.jl – but placed it in base.jl, so it's available when > we get to the assertion definition. I've done this rather than place the > assertion definitions after client.jl, because assertions are used > elsewhere, of course. (Though they may be getting the wrong definitions, > now – at least initially). > - I've split out assertions into assert.jl. This is then loaded just > after error.jl to keep the parser/compiler happy, but it is then > reloaded after client.jl, when useassertions() has its correct value. > > Now, I'm guessing this can't work. When @assert is used before client.jl, > the first (possibly wrong) definition will be used, and the code will be > constructed based on that. That can't be undone when @assert is > redefined, I guess. So … what to do? Move the client code earlier? Sneak in > a lone option check just for this, early on? Avoid assertions for error > checking in the earlier code (if we're talking about using it more for > testing purposes anyway), so assertions can be imported only once, after > client.jl? > > I guess some kind of juggling along these lines (perhaps a combination) > would work. Though there *are* currently (as far as I can see) twenty > files that (*i*) are included before client.jl, and (*ii*) use assertions > (89 uses). Not sure how many of these the client code depend on, though? > > Another option: We could have an internal assert that is always used – a > renaming of the current assert(s). Then the publicly available one (called > assert) would either be a no-op or call the internal one. Then the internal > one could be used in the library code. This would mean we couldn't turn off > the assertions used in the library, though (or in the code defined before > the client runs). > > Suggestions/thoughts? >
