Revision history - refs/heads/sds/inline_bindings - snapshot: a72e953ecd624a7df6e6196bbdd05851996c5e40

swh:1:snp:a72e953ecd624a7df6e6196bbdd05851996c5e40

Newer
Older

Revision	Author	Date	Message	Commit Date
50faa84	Simeon David Schaub	12 February 2022, 22:55:29 UTC	wip	12 February 2022, 22:55:29 UTC
071ae18	Cameron Bieganek	12 February 2022, 18:17:56 UTC	doc: add note about `reduce([hv]cat, x)` in `[hv]cat` (#44049)	12 February 2022, 18:17:56 UTC
7826ac8	Tim Besard	12 February 2022, 17:46:05 UTC	Generalize storage of factorizations. (#42594) Introduce additional type parameters to remove hard-coded arrays from structures.	12 February 2022, 17:46:05 UTC
4c101a1	Jasha10	12 February 2022, 17:09:55 UTC	fix asyncmap docs typo (#43571)	12 February 2022, 17:09:55 UTC
e422590	Thibaut Lienart	12 February 2022, 17:07:42 UTC	clarify mkpath docstring (#43987) Close #43964	12 February 2022, 17:07:42 UTC
3326cc3	Jameson Nash	12 February 2022, 17:04:24 UTC	Revert "use specialized code when compiling opaque closure expressions (#43320)" (#44149) This reverts commit 5cb0f14a1beb65fe562ef24d27741e9ec92d1feb due to failing on CI (analyzegc).	12 February 2022, 17:04:24 UTC
e7f2307	Bogumił Kamiński	12 February 2022, 17:02:45 UTC	Fix docstring for keepat! (#44128) `keepat!` also works with `BitVector`	12 February 2022, 17:02:45 UTC
aad5c1c	Jakob Nybo Nissen	12 February 2022, 14:41:50 UTC	doc: improve docstring of eachsplit (#43745)	12 February 2022, 14:41:50 UTC
f6aab71	Atsushi Sakai	12 February 2022, 13:47:51 UTC	RFC: Add description to load a local module and using it in example codes. (#41398) * Add description to load a local module and using it in example codes. * make example codes to doctests. Co-authored-by: Viral B. Shah <ViralBShah@users.noreply.github.com>	12 February 2022, 13:47:51 UTC
0a91e71	Fons van der Plas	12 February 2022, 03:00:46 UTC	Docs: clarify `JULIA_NUM_THREADS=auto` compat 1.7 (#43842)	12 February 2022, 03:00:46 UTC
b1d152d	Felipe Noronha	12 February 2022, 02:57:05 UTC	improve Channel special constructor docstring (#43979)	12 February 2022, 02:57:05 UTC
e376fcc	Ian Butterworth	12 February 2022, 02:17:45 UTC	Add a `:dynamic` scheduling option for `Threads.@threads` (#43919) Co-authored-by: Julian Samaroo <jpsamaroo@jpsamaroo.me> Co-authored-by: Takafumi Arakaki <29282+tkf@users.noreply.github.com> Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com>	12 February 2022, 02:17:45 UTC
4409a1b	Oscar Smith	11 February 2022, 21:00:58 UTC	remove tuple indexing by non-integer (#43760) Co-authored-by: Fredrik Ekre <ekrefredrik@gmail.com> Co-authored-by: Simeon Schaub <schaub@mit.edu>	11 February 2022, 21:00:58 UTC
a557536	Keno Fischer	11 February 2022, 17:51:10 UTC	Add a few missing effects taints (#44125) Should fix Downloads test (it decided Downloads' easy_hook didn't do anything and accidentally deleted it).	11 February 2022, 17:51:10 UTC
5cb0f14	Jeff Bezanson	11 February 2022, 16:47:35 UTC	use specialized code when compiling opaque closure expressions (#43320) invoke specialization when an OC is created at run time	11 February 2022, 16:47:35 UTC
98e60ff	Cameron Bieganek	11 February 2022, 14:41:52 UTC	Add `allequal` (#43354) * Add `allequal`.	11 February 2022, 14:41:52 UTC
32a026a	Eric Hanson	10 February 2022, 19:24:53 UTC	Test: document and export `TestLogger` and `LogRecord`. (#44080)	10 February 2022, 19:24:53 UTC
85c83a7	Jeff Bezanson	10 February 2022, 19:19:03 UTC	some improvements to GC stat printing (#44098) - line up `elapsed time` - print most numbers unconditionally - print minor/full collections instead of all/full collections - count `free` calls for arrays, since we count `malloc`s for them	10 February 2022, 19:19:03 UTC
0bf6ce3	Fredrik Ekre	10 February 2022, 15:07:51 UTC	Fix doctests for CodeUnits indexing. (#44105)	10 February 2022, 15:07:51 UTC
94bbfd4	Jeremiah	10 February 2022, 14:02:00 UTC	[Docs] Add missing code block (#44094) * [Docs] Add missing code block * Fix block order	10 February 2022, 14:02:00 UTC
aae68a5	Pete Vilter	10 February 2022, 08:04:01 UTC	alloc profiler: add compat note to docstring (#44100)	10 February 2022, 08:04:01 UTC
c360a58	Louis Ponet	10 February 2022, 07:16:20 UTC	Fixed inference on String and Symbol causing invalidations in show.jl (#44091)	10 February 2022, 07:16:20 UTC
fed4544	Shuhei Kadowaki	10 February 2022, 05:58:41 UTC	inference: follow up #43852 (#44101) This commit consists of minor follow up tweaks for #43852: - inlining: use `ConstResult` if available - refactor tests - simplify `CodeInstance` constructor signature - tweak `concrete_eval_const_proven_total_or_error` signature for JET integration	10 February 2022, 05:58:41 UTC
708873a	Oscar Smith	10 February 2022, 05:03:03 UTC	actually add the atributes (#44097) Co-authored-by: oscarddssmith <oscar.smith@juliacomputing.com>	10 February 2022, 05:03:03 UTC
93a5f69	Eric Hanson	09 February 2022, 22:59:56 UTC	Test.TestLogger: add `respect_maxlog` option (#44085)	09 February 2022, 22:59:56 UTC
f090992	Keno Fischer	09 February 2022, 22:24:00 UTC	Take purity modeling seriously (#43852) * Implement new effect system * TLDR Before: ``` julia> let b = Expr(:block, (:(y += sin($x)) for x in randn(1000))...) @eval function f_sin_perf() y = 0.0 $b y end end f_sin_perf (generic function with 1 method) julia> @time @code_typed f_sin_perf() 15.707267 seconds (25.95 M allocations: 1.491 GiB, 3.30% gc time) [lots of junk] ``` After: ``` julia> @time @code_typed f_sin_perf() 0.016818 seconds (187.35 k allocations: 7.901 MiB, 99.73% compilation time) CodeInfo( 1 ─ return 27.639138714768546 ) => Float64 ``` so roughly a 1000x improvement in compile time performance for const-prop heavy functions. There are also run time improvements for functions that have patterns like: ``` function some_function_to_big_to_be_inlined_but_pure(x) .... end function foo(x) some_function_to_big_to_be_inlined_but_pure(x) return x end ``` The inliner will now be able to see that some_function_to_big_to_be_inlined_but_pure is effect free, even without inlining it and just delete it, improving runtime performance (if some_function_to_big_to_be_inlined_but_pure is small enough to be inlined, there is a small compile time throughput win, by being able to delete it without inlining, but that's a smaller gain than the compile time gain above). * Motivation / Overview There are two motivations for this work. The first is the above mentioned improvement in compiler performance for const-prop heavy functions. This comes up a fair bit in various Modeling & Simulation codes we have where Julia code is often auto-generated from some combination of parameterized model codes and data. This ends up creating enormous functions with significant need for constant propagation (~50k statements with ~20k constant calls are not uncommon). Our current compiler was designed for people occasionally throwing a `sqrt(2)` or something in a function, not 20k of them, so performance is quite bad. The second motivation is to have finer grained control over our purity modeling. We have `@Base.pure`, but that has somewhat nebulous semantics and is quite a big hammer that is not appropriate in most situations. These may seem like orthogonal concerns at first, but they are not. The compile time issues fundamentally stem from us running constant propagation in inference's abstract interpreter. However, for simple, pure functions, that is entirely unnecessary, because we have a super-fast, JIT compiler version of that function just laying around in general. The issue is that we currently, we generally do not know when it is legal to run the JIT-compiled version of the function and when we need to abstractly interpret it. However, if the compiler were able to figure out an appropriate notion of purity, it could start doing that (which is what it does now for `@Base.pure` functions). This PR adds that kind of notion of purity, converges it along with type information during inference and then makes use of it to speed up evaluation of constant propagation (where it is legal to do so), as well as improving the inliner. * The new purity notions The new purity model consists of four different kinds flags per code instance. For builtins and intrinsics the existing effect free and nothrow models are re-used. There is also a new macro `@Base.assume_effects` available, which can set the purity base case for methods or `:foreigncall`s. Here is the docstring for that macro, which also explains the semantics of the new purity flags: ``` @assume_effects setting... ex @assume_effects(setting..., ex) `@assume_effects` overrides the compiler's effect modeling for the given method. `ex` must be a method definition. WARNING: Improper use of this macro causes undefined behavior (including crashes, incorrect answers, or other hard to track bugs). Use with care an only if absolutely required. In general, each `setting` value makes an assertion about the behavior of the function, without requiring the compiler to prove that this behavior is indeed true. These assertions are made for all world ages. It is thus advisable to limit the use of generic functions that may later be extended to invalidate the assumption (which would cause undefined behavior). The following `settings` are supported. `:idempotent` The `:idempotent` setting asserts that for egal inputs: - The manner of termination (return value, exception, non-termination) will always be the same. - If the method returns, the results will always be egal. Note: This in particular implies that the return value of the method must be immutable. Multiple allocations of mutable objects (even with identical contents) are not egal. Note: The idempotency assertion is made world-arge wise. More formally, write fₐ for the evaluation of `f` in world-age `a`, then we require: ∀ a, x, y: x === y → fₐ(x) === fₐ(y) However, for two world ages `a, b` s.t. `a != b`, we may have `fₐ(x) !== fₐ(y)`` Note: A further implication is that idempontent functions may not make their return value dependent on the state of the heap or any other global state that is not constant for a given world age. Note: The idempontency includes all legal rewrites performed by the optimizizer. For example, floating-point fastmath operations are not considered idempotent, because the optimizer may rewrite them causing the output to not be idempotent, even for the same world age (e.g. because one ran in the interpreter, while the other was optimized). `:effect_free` The `:effect_free` setting asserts that the method is free of externally semantically visible side effects. The following is an incomplete list of externally semantically visible side effects: - Changing the value of a global variable. - Mutating the heap (e.g. an array or mutable value), except as noted below - Changing the method table (e.g. through calls to eval) - File/Network/etc. I/O - Task switching However, the following are explicitly not semantically visible, even if they may be observable: - Memory allocations (both mutable and immutable) - Elapsed time - Garbage collection - Heap mutations of objects whose lifetime does not exceed the method (i.e. were allocated in the method and do not escape). - The returned value (which is externally visible, but not a side effect) The rule of thumb here is that an externally visible side effect is anything that would affect the execution of the remainder of the program if the function were not executed. Note: The effect free assertion is made both for the method itself and any code that is executed by the method. Keep in mind that the assertion must be valid for all world ages and limit use of this assertion accordingly. `:nothrow` The `:nothrow` settings asserts that this method does not terminate abnormally (i.e. will either always return a value or never return). Note: It is permissible for :nothrow annotated methods to make use of exception handling internally as long as the exception is not rethrown out of the method itself. Note: MethodErrors and similar exceptions count as abnormal termination. `:terminates_globally` The `:terminates_globally` settings asserts that this method will eventually terminate (either normally or abnormally), i.e. does not infinite loop. Note: The compiler will consider this a strong indication that the method will terminate relatively quickly and may (if otherwise legal), call this method at compile time. I.e. it is a bad idea to annotate this setting on a method that technically, but not practically, terminates. Note: The `terminates_globally` assertion, covers any other methods called by the annotated method. ** `:terminates_locally` The `:terminates_locally` setting is like `:terminates_globally`, except that it only applies to syntactic control flow within the annotated method. It is this a much weaker (and thus safer) assertion that allows for the possibility of non-termination if the method calls some other method that does not terminate. Note: `terminates_globally` implies `terminates_locally`. * `:total` The `setting` combines the following other assertions: - `:idempotent` - `:effect_free` - `:nothrow` - `:terminates_globally` and is a convenient shortcut. Note: `@assume_effects :total` is similar to `@Base.pure` with the primary distinction that the idempotency requirement applies world-age wise rather than globally as described above. However, in particular, a method annotated `@Base.pure` is always total. ``` * Changes to data structures - Each CodeInstance gains two sets of four flags corresponding to the notions above (except terminates_locally, which is just a type inference flag). One set of flags tracks IPO-valid information (as determined by inference), the other set of flags tracks optimizer-valid information (as determined after optimization). Otherwise they have identical semantics. - Method and CodeInfo each gain 5 bit flags corresponding 1:1 to the purity notions defined above. No separate distinction is made between IPO valid and optimizer valid flags here. We might in the future want such a distinction, but I'm hoping to get away without it for now, since the IPO-vs-optimizer distinction is a bit subtle and I don't really want to expose that to the user. - `:foreigncall` gains an extra argument (after `cconv`) to describe the effects of the call. * Algorithm Relatively straightforward. - Every call or builtin accumulates its effect information into the current frame. - Finding an effect (throw/global side effect/non-idempotenct, etc.) taints the entire frame. Idempotency is technically a dataflow property, but that is not modeled here and any non-idempotent intrinsic will taint the idempotency flag, even if it does not contribute to the return value. I don't think that's a huge problem in practice, because currently we only use idempotency if effect-free is also set and in effect-free functions you'd generally expect every statement to contribute to the return value. - Any backedge taints the termination effect, as does any recursion - Unknown statements (generic calls, things I haven't gotten around to) taint all effects * Make INV_2PI a tuple Without this, the compiler cannot assume that the range reduction is idempotent to make use of the new fast constprop code path. In the future this could potentially be an ImmutableArray, but since this is relatively small, a tuple is probably fine. * Evalute :total function in the proper world * Finish effects implementation for ccall * Add missing `esc` * Actually make use of terminates_locally override * Mark ^(x::Float64, n::Integer) as locally terminating * Shove effects into calling convention field * Make inbounds taint consistency Inbounds and `--check-bounds=no` basically make the assertion: If this is dynamically reached during exceution then the index will be inbounds. However, effects on a function are a stronger statement. In particular, for any input values (not just the dynamically reached ones), the effects need to hold. This is in particular true, because inference can run functions that are dynamically dead, e.g. ``` if unknown_bool_return() # false at runtime, but inference doesn't know x = sin(1.0) end ``` Inference will (and we want it to) run the `sin(1.0)` even though it is not dynamically reached. For the moment, make any use of `--check-bounds=no` or `@inbounds` taint the consistency effect, which is semantically meaningful and prevents inference from running the function. In the future, we may want more precise tracking of inbounds that would let us recover some precision here. * Allow constprop to refine effects * Properly taint unknown call in apply * Add NEWS and doc anchor * Correct effect modeling for arraysize * Address Shuhei's review * Fix regression on inference time benchmark The issue wasn't actually the changes here, they just added additional error paths which bridged inference into the Base printing code, which as usual takes a fairly long time to infer. Add some judicious barriers and nospecialize statements to bring inference time back down. * refine docstrings of `@assume_effects` This commit tries to render the docstring of `@assume_effects` within Documenter.jl-generated HTML: - render bullet points - codify the names of settings - use math syntax - use note admonitions * improve effect analysis on allocation Improves `:nothrow` assertion for mutable allocations. Also adds missing `IR_FLAG_EFFECT_FREE` flagging for non-inlined callees in `handle_single_case!` so that we can do more dead code elimination. * address some reviews * Address Jameson's review feedback * Fix tests - address rebase issues Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>	09 February 2022, 22:24:00 UTC
76fa182	Pete Vilter	09 February 2022, 22:23:13 UTC	alloc profiler: adjust warnings in docs; remove logged warning from implementation (#44077) * docs: update warning in the manual; add to reference * remove missed allocs warning from `fetch` since we think we've gotten all the allocs * remove tests of warning message, since it's no longer there	09 February 2022, 22:23:13 UTC
6b16eba	Dilum Aluthge	09 February 2022, 21:37:22 UTC	doc: remind users that versioninfo may include secrets (#43839) Add a warning to the docstring of `InteractiveUtils.versioninfo()` reminding users to remove sensitive information before sharing the output text.	09 February 2022, 21:37:22 UTC
a84a058	Jameson Nash	09 February 2022, 19:50:41 UTC	Merge pull request #43953 from JuliaLang/jn/43636 impose stricter and earlier validation on ccall/cfunction types	09 February 2022, 19:50:41 UTC
dc0aa61	Tomas Fiers	09 February 2022, 16:53:16 UTC	Manual for `JULIA_EDITOR`: note `code.cmd` for vscode on Windows (#44083)	09 February 2022, 16:53:16 UTC
2118a08	Keno Fischer	09 February 2022, 11:19:23 UTC	Add an option to not emit unionsplit fallback blocks (#43923) When union splitting, we currently emit a fallback block that prints `fatal error in type inference (type bound)`. This has always been an oddity, because there are plenty of other places in the compiler that we rely on the correctness of inference, but it has caught a number of issues over the years and we do still have a few issues (e.g. #43064) that show this error. Nevertheless, the occurrence of issues like this has become less frequent, so it might be time to turn it off soon. At the same time, we have downstream users of the compiler infrastructure that get confused by having extra `throw` calls inserted into functions that (post-#43852) were inferred as `:nothrow`. Here we add an optimization param (defaulted to on) to determine whether or not to insert the unionsplit fallback block. Because of the conservative default, we can decide later what the correct default is (maybe turn it on in `debug` mode?), while letting downstream consumers play with the setting for now to see if any issues crop up.	09 February 2022, 11:19:23 UTC
0bdf24f	N5N3	09 February 2022, 09:11:36 UTC	Move `reinterpret`-based optimization for complex matrix * real vec/mat to lower level. (#44052)	09 February 2022, 09:11:36 UTC
33a71b7	Sebastian Stock	09 February 2022, 09:00:55 UTC	Allow negative `stride(A,2)` in `gemv!` (#42054)	09 February 2022, 09:00:55 UTC
a947fc7	Keno Fischer	09 February 2022, 06:36:07 UTC	Add a donotdelete builtin (#44036) In #43852 we noticed that the compiler is getting good enough to completely DCE a number of our benchmarks. We need to add some sort of mechanism to prevent the compiler from doing so. This adds just such an intrinsic. The intrinsic itself doesn't do anything, but it is considered effectful by our optimizer, preventing it from being DCE'd. At the LLVM level, it turns into call to an external varargs function. The docs for the new intrinsic are as follows: ``` donotdelete(args...) This function prevents dead-code elimination (DCE) of itself and any arguments passed to it, but is otherwise the lightest barrier possible. In particular, it is not a GC safepoint, does model an observable heap effect, does not expand to any code itself and may be re-ordered with respect to other side effects (though the total number of executions may not change). A useful model for this function is that it hashes all memory `reachable` from args and escapes this information through some observable side-channel that does not otherwise impact program behavior. Of course that's just a model. The function does nothing and returns `nothing`. This is intended for use in benchmarks that want to guarantee that `args` are actually computed. (Otherwise DCE may see that the result of the benchmark is unused and delete the entire benchmark code). Note: `donotdelete` does not affect constant foloding. For example, in `donotdelete(1+1)`, no add instruction needs to be executed at runtime and the code is semantically equivalent to `donotdelete(2).` *# Examples function loop() for i = 1:1000 # The complier must guarantee that there are 1000 program points (in the correct # order) at which the value of `i` is in a register, but has otherwise # total control over the program. donotdelete(i) end end ```	09 February 2022, 06:36:07 UTC
2e2b1d2	Louis Ponet	09 February 2022, 03:46:26 UTC	Fixed inference on String causing invalidations in binaryplatform (#44084)	09 February 2022, 03:46:26 UTC
7ccc83e	Julian Samaroo	09 February 2022, 01:36:22 UTC	Add USDTs for the task runtime (#43453) Co-authored-by: Takafumi Arakaki <aka.tkf@gmail.com>	09 February 2022, 01:36:22 UTC
0639d0d	DilumAluthgeBot	09 February 2022, 00:07:44 UTC	🤖 Bump the Pkg stdlib from 89517355 to c991ce0a (#44075) Co-authored-by: Dilum Aluthge <dilum@aluthge.com>	09 February 2022, 00:07:44 UTC
d7fd3b7	Nathan Daly	08 February 2022, 21:18:35 UTC	`===` Optimization: Defer recursion into pointees (#43658) * jl_egal Optimization: Defer recursion into pointees Immutable struct comparisons with `===` can be arbitrarily expensive for deeply recursive but (almost) equal objects. Whenever possible, it's valuable to defer the potentially expensive recursion by first comparing the struct fields for bitwise equality. Before this commit, two structs are compare elementwise, in the order of the struct definition, recursing when pointer fields are encountered. This commit defers the recursion into pointed-to fields until after all other non-pointer fields of the struct are compared. This has two advantages: 1. It defers the expensive part of === comparison as long as possible, in the hopes that we can exit early from dissimilarities discovered elsewhere in the struct instances. 2. It improves cache-locality by scanning the whole struct before jumping into any new places in memory (and reducing comparisons needed on the current cache line after returning from the recursive call). The drawback is that you'll have to scan the pointer fields again, which means potentially more cache misses if the struct is very large. The best way to tell if this is helpful or harmful is benchmarking. Here is the motivating benchmark, which indeed improves by 10x with this commit, compared to master: ```julia julia> using BenchmarkTools julia> struct VN val::Float32 next::Union{VN, Array} # put a mutable thing at the end, to prevent runtime from sharing instances end julia> struct NV next::Union{NV, Array} # put a mutable thing at the end, to prevent runtime from sharing instances val::Float32 end julia> function make_chain_vn(n, sentinal) head = VN(1, sentinal) for i in 2:n head = VN(rand(Int), head) end return head end make_chain_vn (generic function with 1 method) julia> function make_chain_nv(n, sentinal) head = NV(sentinal, 1) for i in 2:n head = NV(head, rand(Int)) end return head end make_chain_nv (generic function with 1 method) julia> vn1, vn2 = make_chain_vn(10000, []), make_chain_vn(10000, []); julia> nv1, nv2 = make_chain_nv(10000, []), make_chain_nv(10000, []); ``` Master: ``` julia> @btime $vn1 === $vn2 7.562 ns (0 allocations: 0 bytes) false julia> @btime $nv1 === $nv2 # slower, since it recurses pointers unnecessarily 76.952 μs (0 allocations: 0 bytes) false ``` After this commit: ``` julia> @btime $vn1 === $vn2 8.597 ns (0 allocations: 0 bytes) false julia> @btime $nv1 === $nv2 # We get to skip the recursion and exit early. :) 10.280 ns (0 allocations: 0 bytes) false ``` However, I think that there are probably other benchmarks where it harms performance, so we'll have to see... For example, here's one: In the exact opposite case as above, if the two objects _are_ (almost) equal, necessitating checking every object, the `NV` comparisons could have exited after all the recursive pointer checks, and never compare the fields, whereas now the fields are checked first, so this gets slower. I'm not exactly sure why the `VN` comparisons get somewhat slower too, but it's maybe because of the second scan mentioned above. ```julia julia> function make_chain_nv(n, sentinal) head = NV(sentinal, 1) for i in 2:n head = NV(head, i) end return head end make_chain_nv (generic function with 1 method) julia> function make_chain_vn(n, sentinal) head = VN(1, sentinal) for i in 2:n head = VN(i, head) end return head end make_chain_vn (generic function with 1 method) julia> vn1, vn2 = make_chain_vn(10000, []), make_chain_vn(10000, []); julia> nv1, nv2 = make_chain_nv(10000, []), make_chain_nv(10000, []); ``` Master: ``` julia> @btime $vn1 === $vn2 95.996 μs (0 allocations: 0 bytes) false julia> @btime $nv1 === $nv2 82.192 μs (0 allocations: 0 bytes) false ``` This commit: ``` julia> @btime $vn1 === $vn2 127.512 μs (0 allocations: 0 bytes) false julia> @btime $nv1 === $nv2 126.837 μs (0 allocations: 0 bytes) ``` * Ignore pointer fields completely in the first pass of === Delay the nullptr checks until all non-ptr fields have been compared, since we have to go back to those anyways to follow the pointers. Co-authored-by:Jeff Bezanson <jeff.bezanson@gmail.com>	08 February 2022, 21:18:35 UTC
60f414e	Valentin Churavy	08 February 2022, 20:38:50 UTC	Merge pull request #44081 from oscardssmith/fix-linux32-ci fix #43978 (missing parens)	08 February 2022, 20:38:50 UTC
9c9bb86	N5N3	08 February 2022, 20:22:30 UTC	Make `to_indices` infered better for CartesianIndex/Indices (#42055)	08 February 2022, 20:22:30 UTC