Backports for 1.12.0-beta3 #58270
Backports for 1.12.0-beta3 #58270
Conversation
…lls (#58200) `op` should not be `inbounds`-ed here the test case I added might technically be an illegal (or at least bad) use of `@propagate_inbounds` in case anyone has a suggestion for a more natural test case, but nonetheless it demonstrates getting a `BoundsError` instead of a segfault (worse) or incorrect / junk data (more worse), both of which happen on master (cherry picked from commit bdab032)
Change the implementation of the allocations to always add a function call (closure) wrapper so that the inner code can be optimized, even if the outer scope is `@latestworld`. The implementation creates a closure if necessary (the code is complex) or just makes a call if the expression is simple (just a call on symbols). Many packages in the wild are observed to already be doing this themselves. (cherry picked from commit a47b58f)
Since the size of the array is encoded in the type, we may define `one` on the type. This is useful in certain linear algebra contexts. (cherry picked from commit d9fafab)
Fix the subtyping hang found in #58115 (comment) (cherry picked from commit c9ad04d)
…mpletions (#58218) The test for this crashes on my machine, leading me to notice that the implementation of this function was nonsense. Fortunately, we already had a more correct implementation of this function in the REPL docview code that we could borrow from to fix this. While here, also filter out macros, since those are rather strange looking to see appearing in the results. We could alternatively use `Base.is_valid_identifier`, since the main point here is to print functions that are accessible in the module by identifier. ``` julia> @eval Base.MainInclude export broken julia> broken = 2 2 julia> ?(┌ Error: Error in the keymap │ exception = │ UndefVarError: `broken` not defined in `Base.MainInclude` ``` (cherry picked from commit 8780aa9)
(cherry picked from commit 4616aa2)
(cherry picked from commit dc8bc73)
alternate to #58214. --------- Co-authored-by: Jeff Bezanson <[email protected]>
Co-authored-by: Alex Arslan <[email protected]> Co-authored-by: Nick Robinson <[email protected]>
Will need to be manually backported since this is in NEWS.md on 1.12 rather than HISTORY. Closes #57596 --------- Co-authored-by: Shuhei Kadowaki <[email protected]>
(cherry picked from commit b9a0497)
(cherry picked from commit d4f2e8a)
Co-authored-by: Cody Tapscott <[email protected]> (cherry picked from commit 485575c)
Generalized from JuliaData/Parsers.jl#197 (cherry picked from commit 1f18391)
The current language of `:consistent` for assume_effects is problematic, because it explicitly promises something false: That you're allowed to mark a method as `:consistent` even in the face of redefinitions. To understand this problem a bit better, we need to think about the primary use case of the `:consistent` annotation: To perform constant propagation evaluation of fuctions with constant arguments. However, since constant evaluation only runs in a single world (unlike the abstract interpreter, which symbolically runs in multiple worlds and keeps track of which world range its result is valid for), we run into a bit of a problem. In principle, for full correctness and under the current definition of consistentcy, we can only claim that we know the result for a single world age (the one that we ran in). This is problematic, because it would force us to re-infer the function for every new world age. In practice however, ignoring `@assume_effects` for the moment, we have a stronger guarantee. When inference sets the :consistent effect bit, it guarantees consistentcy across the entire computed min_world:max_world range. If there is a redefinition, the world range will be terminated, even if it is `:consistent` both before and after and even if the redefinition would not otherwise affect inference's computed information. This is useful, because it lets us conclude that the information derived from concrete evluation is valid for the entire min_world:max_world range of the corresponding code instance. Coming back to `@assume_effects` we run into a problem however, because we have no way to provide the required edges to inference. In practice inference will probably be able to figure it out, but this is insufficient as a semantic guarantee. After some discussion within the compiler team, we came to the conclusion that the best resolution was to change the documented semantics of `@assume_effects :consistent` to require consistent-cy across the entire defined world range of the method, not just world-age-by-world-age. This is a significantly stronger guarantee, but appears necessary for semantic correctness. In the future we may want to consider `:consistent` annotations for particular if blocks, which would not require the same restrictions (because it would still rely on inference to add appropriate edges for redefinitions). Closes #46156 (cherry picked from commit d7cd271)
Using the fallback REPL interactively prints the prompt only after user input, making the scrollback confusing: ``` $ JULIA_FALLBACK_REPL=1 julia 1 + 2 julia> 3 ``` --------- Co-authored-by: Jameson Nash <[email protected]> Co-authored-by: Dilum Aluthge <[email protected]> (cherry picked from commit ccef01a)
In #53959, an new `LimitIO` object was defined to display at the REPL, but it hid the displaysize of the underlying `io`. This patch just forwards this information. Before: ``` julia> Dict(1 => fill(UInt(0), 4)) Dict{Int64, Vector{UInt64}} with 1 entry: 1 => [0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x000000000… ``` After: ``` Dict{Int64, Vector{UInt64}} with 1 entry: 1 => [0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000] ``` (cherry picked from commit 35bfba9)
(cherry picked from commit 7b64cec)
This does not fix the underlying issue that can occur here which is a collision of build_ids.lo between modules in IR decompression. Fixing that requires a somewhat significant overhaul to the serialization of IR (probably using the module identity as a key). This does mean we use a lot more of the bits available here so it makes collisions a lot less likely( they were already extremely rare) but hrtime does tend to only use the lower bits of a 64 bit integer and this will hopefully add some more randomness and make this even less likely (cherry picked from commit 7157407)
This is close to the expected behavior after deprecations are removed (other than that the b->globalref->mod in the printed message here will be the source module instead of the destination module, which may sometimes cause confusing printing here, but probably rarely). I also needed this recently to find a place this warning occurred, so I think it should be merged now and get feedback later. Closes #57969 (cherry picked from commit 0682158)
(cherry picked from commit 3204987)
While #58156 was supposed to be fairly trivial, it ended up uncovering many bugs in the unusual ways that trimming and binding partition had been added to the serialization format. This attempts to reorganize them to be handled more consistently and with fewer mistakes. (cherry picked from commit 828e3a1)
The `jl_get_binding_partition_with_hint` version of the bpart lookup did not properly set the `max_world` of the gap, leaving it at `~(size_t)0`. Having a `gap` with that `max_world`, but with `gap.replace` set is inconsistent and ended up causing an integer overflow downstream in the computation of `expected_prev_min_world`, which looked like a concurrent modification causing an infinite retry. Fixes #58257 (cherry picked from commit fc8e6e7)
Inspired by a bug I hit on MinGW recently with weak symbol resolution. I'm not sure why we started using these in 70000ac, since I believe we should be able to lookup these symbols just fine in our `jl_exe_handle` as long as it was linked / compiled with `-rdynamic` Migrating away from weak symbols seems a good idea, given their uneven implementation across platforms. (cherry picked from commit 4a6ada6)
Prevent infinite inference when dealing with LimitedAccuracy by declining to cache them. Presence in the cache triggers further compilation to resolve it, so removing infinite work from the cache also prevents infinite work at pre-compile/jit compile time. Fix #57098 Fix #57873 (cherry picked from commit 48bd673)
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed14 packages crashed only on the current version.
✖ Packages that failed362 packages failed only on the current version.
10 packages failed on the previous version too. ✔ Packages that passed tests60 packages passed tests on the previous version too. ➖ Packages that were skipped altogether1 packages were skipped on the previous version too. |
Introduce `jl_image_buf_t` to represent the in-memory details of an unparsed system image and clean-up several global variables and split loading logic in staticdata.c so that we get (almost) everything we need from the sysimage handle at once. This allows sysimage loading to be separated into three phases: 1. Lookup the raw sysimage buffer as a `jl_image_buf_t` 2. For .so sysimages, parse the sysimage and initialize JIT targets, etc. 3. Finally load the sysimage into a `jl_image_t` Care was taken to preserve the existing behavior of calling `jl_set_sysimg_so` to configure the sysimage before initializing Julia, although this is likely to be next on the chopping block in a follow-up. Dependent on #57523.
This adds `jl_pgcstack_default_func` to allow an uninitialized runtime to make it into `jl_autoinit_and_adopt_thread` The init changes themselves are left to #57498 --------- Co-authored-by: Cody Tapscott <[email protected]>
…lier (#58231) This changes the order of initialization slightly. The goal is to be able to initialize executables and share libraries without having to explicitly call init functions. This still doesn't address the thread safety
This accidentally diverged when #58141 was merged without adjusting the test to match (these tests shouldn't be re-implementing the `juliac` link step anyway, but they currently do) Unfortunately, this hid a bug where `jl_pathname_for_handle` does not understand the main executable.
This adds the changes required to guess the MethodInstance that the runtime will eventually invoke for this call, enqueue it for codegen, and then verify its presence in the verifier.
Otherwise this will match `ftyp === Builtin`, which is pretty silly since that could just as well be any other built-in.
See #58143 for details.
…xx` (#58325) Otherwise these subroutines may raise `unhandled Vararg` errors when compiling e.g. CassetteOverlay for complex call graphs.
Backported PRs:
@inboundsannotations inaccumulate.jlto only indexing calls #58200stat#58212onefor theSizedArraytest helper #58209bindinChannelmethod doc string #58113JIT_Totalzone with function names #58219@assume_effects:consistent #58254Varargchecks in newly addedabstract_eval_xxx#58325src.nargsforvalidate_code!#58327Need manual backport:
init.cfrom test #58197Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
IteratorSizemethod forGenerator#58110transcode: prevent Windows sysimage invalidation #58038@nospecializeforstring_index_err#57604maxthreadidfromThreads#57490