-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Comparing changes
Open a pull request
base repository: JuliaLang/julia
base: 133e8ce5402b2aa6c48f9dd7a0c408f8a2967093
head repository: JuliaLang/julia
compare: fb6f42df15fbeae6cad79bb0179bd161793a18e0
- 8 commits
- 38 files changed
- 7 contributors
Commits on May 3, 2024
-
Allow optimized OC in :new_opaque_closure (#54329)
This isn't officially supported, but some packages are currently using the pattern of creating an optimized opaque closure, pulling out its method and then using that in `:new_opaque_closure` to change the environment. This stopped working properly when I changed optimized ocs to not have a ->source field in the method. Let's keep this working for now, but I'd like to provide a more first class mechanism for these kinds of use cases in the near future.
Configuration menu - View commit details
-
Copy full SHA for 2e1fc88 - Browse repository at this point
Copy the full SHA 2e1fc88View commit details -
show: Fix non-stacktrace show of toplevel MethodInstance (#54338)
While we're here, also check before accessing the `uninferred` field. Top-level MethodInstances should always have this, but the system doesn't enforce this and it's rude for a `show` method to throw on corrupted data (since that's what people use to debug that).
Configuration menu - View commit details
-
Copy full SHA for cad6d1d - Browse repository at this point
Copy the full SHA cad6d1dView commit details -
Pass CLANGSA_CXXFLAGS to clangsa tests (#54337)
`CLANGSA_CXXFLAGS` are defined in `Make.inc`, https://github.com/JuliaLang/julia/blob/f712512a1159771d9a61e1a768e1a8b297a493c8/Make.inc#L1501 and it is included in the Makefile for clangsa tests. https://github.com/JuliaLang/julia/blob/f712512a1159771d9a61e1a768e1a8b297a493c8/test/clangsa/Makefile#L4 But it does not get passed to clangsa tests properly. This PR fixes this.
Configuration menu - View commit details
-
Copy full SHA for 2d87ce3 - Browse repository at this point
Copy the full SHA 2d87ce3View commit details -
When accessing the data pointer for an array, first decay it to a Der…
Configuration menu - View commit details
-
Copy full SHA for 9d59ecc - Browse repository at this point
Copy the full SHA 9d59eccView commit details
Commits on May 4, 2024
-
add a precompile signature to Artifacts code that is used by JLLs (#5…
…4350) ``` # before julia> @time using GR_jll 0.202372 seconds (421.29 k allocations: 23.172 MiB, 4.93% gc time, 37.90% compilation time: 2% of which was recompilation) # after julia> @time using GR_jll 0.176863 seconds (151.62 k allocations: 9.064 MiB, 6.16% gc time, 4.11% compilation time: 29% of which was recompilation)'' ```
Configuration menu - View commit details
-
Copy full SHA for 5c549a1 - Browse repository at this point
Copy the full SHA 5c549a1View commit details -
🤖 [master] Bump the Pkg stdlib from a0851bcfd to ed7a8dca8 (#54352)
Stdlib: Pkg URL: https://github.com/JuliaLang/Pkg.jl.git Stdlib branch: master Julia branch: master Old commit: a0851bcfd New commit: ed7a8dca8 Julia version: 1.12.0-DEV Pkg version: 1.12.0 Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaLang/Pkg.jl@a0851bc...ed7a8dc ``` $ git log --oneline a0851bcfd..ed7a8dca8 ed7a8dca8 add note about `activate -` to command help (#3888) c26ad23e9 Use `Base.format_bytes` (#3763) c59b37ffd add hint kwarg to complete_line (#3886) ``` Co-authored-by: Dilum Aluthge <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for da6892f - Browse repository at this point
Copy the full SHA da6892fView commit details
Commits on May 5, 2024
-
A better mechanism for coordinating internal breaking changes. (#53849)
This was origiginally supposed to be an issue, but I just started writing out the whole code in the issue text to explain what I want all the behavior to be, so instead, here's the actual implementation of it, with the motativation in the commit message, and the details of the actual behavior in the code change ;) Sometimes packages rely on Julia internals. This is in general discouraged, but of course for some packages, there isn't really any other option. If your packages needs to hook the julia internals in a deep way or is specifically about introspecting the way that julia itself works, then some amount of reliance on internals is inevitable. In general, we're happy to let people touch the internals, as long as they (and their users) are aware that things will break and it's on them to fix things. That said, I think we've been a little bit too *caveat emptor* on this entire business. There's a number of really key packages that rely on internals (I'm thinking in particular of Revise, Cthulhu and its dependency stacks) that if they're broken, it's really hard to even develop julia itself. In particular, these packages have been broken on Julia master for a more than a week now (following #52415) and there has been much frustration. I think one of the biggest issues is that we're generally relying on `VERSION` checks for these kinds of things. This isn't really a problem when updating a package between released major versions, but for closely coupled packages like the above you run into two problems: 1. Since the VERSION number of a package is not known ahead of time, some breaking changes cannot be made atomically, i.e. we need to merge the base PR (which bumps people's nightly) in order to get the version number, which we then need to plug into the various PRs in all the various packages. If something goes wrong in this process (as it did this time), there can be extended breakage. 2. The VERSION based comparison can be wrong if you're on an older PR (that's a head of the base branch, but with different commits). As a result, when working on base PRs, you not infrequently run into a situation, where you get a VERSION false-positive from updating a package, introducing errors you didn't see before. This one isn't usually that terrible, because a rebase will fix it (and you'll probably need to rebase anyway), but it can be very confusing to get new and unexpected errors from random packages. I would propose that going forward, we strongly discourage closely coupled packages from using `VERSION` comparisons and intead: 1. Where possible, probe for the feature or method signature that they're actually looking for, if it's something small (e.g. a rename of base type). 2. That we as julia base establish a mechanism for probing whether your current pre-release julia has a certain change. My sketch proposal is in this PR.
2Configuration menu - View commit details
-
Copy full SHA for 2cf469d - Browse repository at this point
Copy the full SHA 2cf469dView commit details -
This changes the canonical source of truth for va handling from `Method` to `CodeInfo`. There are multiple goals for this change: 1. This addresses a longstanding complaint about the way that CodeInfo-returning generated functions work. Previously, the va-ness or not of the returned CodeInfo always had to match that of the generator. For Cassette-like transforms that generally have one big generator function that is varargs (while then looking up lowered code that is not varargs), this could become quite annoying. It's possible to workaround, but there is really no good reason to tie the two together. As we observed when we implemented OpaqueClosures, the vararg-ness of the signature and the `vararg arguments`->`tuple` transformation are mostly independent concepts. With this PR, generated functions can return CodeInfos with whatever combination of nargs/isva is convenient. 2. This change requires clarifying where the va processing boundary is in inference. #54076 was already moving in that direction for irinterp, and this essentially does much of the same for regular inference. As a consequence the constprop cache is now using non-va-cooked signatures, which I think is preferable. 3. This further decouples codegen from the presence of a `Method` (which is already not assumed, since the code being generated could be a toplevel thunk, but some codegen features are only available to things that come from Methods). There are a number of upcoming features that will require codegen of things that are not quite method specializations (See design doc linked in #52797 and things like #50641). This helps pave the road for that. 4. I've previously considered expanding the kinds of vararg signatures that can be described (see e.g. #53851), which also requires a decoupling of the signature and ast notions of vararg. This again lays the groundwork for that, although I have no immediate plans to implement this change. Impact wise, this adds an internal field, which is not too breaking, but downstream clients vary in how they construct their `CodeInfo`s and the current way they're doing it will likely be incorrect after this change, so they will require a small two-line adjustment. We should perhaps consider pulling out some of the more common patterns into a more stable package, since interface in most of the last few releases, but that's a separate issue.
Configuration menu - View commit details
-
Copy full SHA for fb6f42d - Browse repository at this point
Copy the full SHA fb6f42dView commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 133e8ce5402b2aa6c48f9dd7a0c408f8a2967093...fb6f42df15fbeae6cad79bb0179bd161793a18e0