replace `@pure` annotations in Base with effect settings #44776

aviatesk · 2022-03-28T13:06:37Z

This commit replaces @pure/@_pure_meta annotations used in Base
with corresponding effect settings (:total or :total_or_throw).

The concrete evaluation mechanism based on the effect system (#43852)
has the following benefits over the @pure-based optimization:

it can fold cases when consistent exception is thrown
it can handle constant union-split situation as well
effects can be propagated inter-procedurally

While revisiting the existing annotations, I removed some unnecessary ones
and also added some more hopefully helpful new annotations (mostly for reflection utilities).
In theory this should give us some performance benefits, e.g. now we
can concrete-evaluate union-spit typeintersect:

@test Base.return_types((Union{Int,Nothing},)) do x
  typeintersect(String, typeof(x))
end |> only === Type{Union{}}

Though this commit ends up bigger than I expected -- we should carefully
check a benchmark result so that it doesn't come with any regressions.

@nanosoldier runbenchmarks(!"scalar", vs=":master")

oscardssmith · 2022-03-28T13:39:20Z

base/essentials.jl

 macro _pure_meta()
    return Expr(:meta, :pure)
 end
+# can be used in place of `@assume_effects :total` (supposed to be used for bootstrapping)
+macro _total_meta()


maybe name this _effect_total? The current name seems fairly confusing.

oscardssmith · 2022-03-28T13:39:35Z

base/essentials.jl

@@ -151,9 +151,29 @@ macro isdefined(s::Symbol)
    return Expr(:escape, Expr(:isdefined, s))
 end

+# can be used in place of `@pure` (supposed to be used for bootstrapping)
 macro _pure_meta()


can we delete _pure_meta now?

(and @pure?)

It's technically internal so we should be able to do so, but I suspect there's a decent amount of package code that uses it, so we should probably at least go through some kind of deprecation process. Or maybe just make PRs to affected packages to not use it if VERSION ≥ v"1.9".

We could also be sneaky and make it a no-op and then see if people actually notice...

is anyone using it correctly? I don't think @vtjnash has added uses to packages, and as far as I understand, he is the only person allowed to use it.

https://juliahub.com/ui/Search?q=pure&type=symbols&t=macro

Now all of these internal macros are no-op when used outside of Base ;)

Keno · 2022-03-28T18:22:32Z

base/reflection.jl

    (!isvarargtype(a) && !isvarargtype(b)) || throw(ArgumentError("invalid typeintersect with Vararg"))
-    return ccall(:jl_type_intersection, Any, (Any, Any), a, b)
+    # equivalent to: @assume_effects :total @ccall jl_type_intersection(a::Any, b::Any)::Any
+    return $(Expr(:foreigncall, QuoteNode(:jl_type_intersection),


How feasible would it be to define the ccall macro earlier or maybe have a limited version of it. I was fine with one or two of those, but if this expands, it's a bit of a nightmare.

Might even be worth making it a non-proper scheme macro (not handled by macroexpand), since it can be rather complex to unpack the various possible arguments, but therefore also worthwhile to have very early in bootstrapping

I spent a bit time to rearrange utilities of essentials.jl/reflection.jl/expr.jl, but didn't succeed to bootstrap. The most difficult part might be that operators.jl isn't available at a time of using @ccall in reflection.jl.

For these specific utilities, I think we can use @_total_but_may_throw_meta instead and it won't be that bad.

nanosoldier · 2022-03-28T18:56:38Z

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

base/broadcast.jl

base/essentials.jl

vtjnash · 2022-03-28T19:09:30Z

base/irrationals.jl

@@ -48,7 +48,8 @@ AbstractFloat(x::AbstractIrrational) = Float64(x)::Float64
 Float16(x::AbstractIrrational) = Float16(Float32(x)::Float32)
 Complex{T}(x::AbstractIrrational) where {T<:Real} = Complex{T}(T(x))

-@pure function Rational{T}(x::AbstractIrrational) where T<:Integer
+# XXX this may change `DEFAULT_PRECISION`, thus not effect free


horribly, the return value also includes novel memory allocation and depends on the global runtime state of the DEFAULT_PRECISION

base/tuple.jl

KristofferC · 2022-03-28T19:58:54Z

["broadcast", "mix_scalar_tuple", (3, "scal_tup_x3")] looks like a real regression in the benchmarks.

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

aviatesk · 2022-03-30T05:55:44Z

["broadcast", "mix_scalar_tuple", (3, "scal_tup_x3")] looks like a real regression in the benchmarks.

I'd conclude this is not a regression. This benchmark is actually fully constant folded and so the difference may just be a noise. This benchmark is equivalent to the following code snippet, which would be fully folded both on master and this PR:

julia> t1 = (1,2,3)
(1, 2, 3)

julia> @eval code_typed() do
           broadcast(+, 1, $t1, 1, $t1, 1, $t1)
       end
1-element Vector{Any}:
 CodeInfo(
1 ─     return (6, 9, 12)
) => Tuple{Int64, Int64, Int64}

aviatesk · 2022-03-30T06:57:46Z

I'd like to move #44785 forward first before merging this. #44785 will allow us to test certain Base functions have expected effects so that they are guaranteed to be optimized.

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ```

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ``` Co-authored-by: Takafumi Arakaki <[email protected]>

@test

This commit adds new reflection utility named `Base.infer_effects` that works in the same way as `Base.return_types` but returns inferred effects instead. It would be helpful to test that certain method call has an expected effects. For example, we can now remove `Base.@pure` annotation from the definition of `BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N}` and checks it's still eligible for concrete evaluation like this (see <#44776 (comment)> for the context): ```julia julia> import Base.Broadcast: AbstractArrayStyle, DefaultArrayStyle, Unknown julia> function BroadcastStyle(a::A, b::B) where {A<:AbstractArrayStyle{M},B<:AbstractArrayStyle{N}} where {M,N} if Base.typename(A) === Base.typename(B) return A(Val(max(M, N))) end return Unknown() end BroadcastStyle (generic function with 1 method) julia> # test that the above definition is eligible for concrete evaluation @test Base.infer_effects(BroadcastStyle, (DefaultArrayStyle{1},DefaultArrayStyle{2},)) |> Core.Compiler.is_total_or_error Test Passed ``` Co-authored-by: Takafumi Arakaki <[email protected]>

aviatesk · 2022-04-02T02:12:22Z

@nanosoldier runbenchmarks(!"scalar", vs=":master")

nanosoldier · 2022-04-02T08:00:45Z

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

aviatesk · 2022-04-04T06:07:25Z

@nanosoldier runbenchmarks("inference" || "collection" || "random", vs=":master")

nanosoldier · 2022-04-04T07:20:49Z

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

aviatesk · 2022-04-04T09:43:46Z

Okay, only the inference benchmark set gets regressed by this change. It seems to be slightly costly to use concrete_eval_call pass rather than bailing out with pure_eval_call, which is very expected as the former requires a preceding effects analysis to be done by abstract_call_method.

I confirmed that there seems to be no regression in the inference benchmark if we use the @assume_effects settings within pure_call_eligible (this is technically breaking the semantics of @assume_effects though):

diff --git a/base/compiler/abstractinterpretation.jl b/base/compiler/abstractinterpretation.jl
index 0cca9c38d2..5d65895a28 100644
--- a/base/compiler/abstractinterpretation.jl
+++ b/base/compiler/abstractinterpretation.jl
@@ -676,7 +676,17 @@ function pure_eval_eligible(interp::AbstractInterpreter,
     # XXX we need to check that this pure function doesn't call any overlayed method
     return f !== nothing &&
            length(applicable) == 1 &&
-           is_method_pure(applicable[1]::MethodMatch) &&
+           begin
+               match = applicable[1]::MethodMatch
+               is_method_pure(match) || begin
+                   if isoverlayed(method_table(interp))
+                       false
+                   else
+                       effects = decode_effects_override(match.method.purity)
+                       effects.consistent && effects.effect_free && effects.terminates_globally
+                   end
+               end
+           end &&
            is_all_const_arg(arginfo)
 end

I'd rather accept that slight regression for now though, as I believe we will focus our development efforts on the new effects analysis rather than putting more on the @pure-based optimization.

@test

This commit replaces `@pure`/`@_pure_meta` annotations used in `Base` with corresponding effect settings (`:total` or `:total_or_throw`). The concrete evaluation mechanism based on the effect system (#43852) has the following benefits over the `@pure`-based optimization: - it can fold cases when consistent exception is thrown - it can handle constant union-split situation as well - effects can be propagated inter-procedurally While revisiting the existing annotations, I removed some unnecessary ones and also added some more hopefully new annotations (mostly for reflection utilities). In theory this should give us some performance benefits, e.g. now we can concrete-evaluate union-spit `typeintersect`: ```julia @test Base.return_types((Union{Int,Nothing},)) do x typeintersect(String, typeof(x)) end |> only === Type{Union{}} ``` Though this commit ends up bigger than I expected -- we should carefully check a benchmark result so that it doesn't come with any regressions.

We discussed that for certain methods like `:total`ly-declared method or `@nospecialize`d method we may want to only do constant propagation while disabling preceding only-type-level inference. This commit implements a simple infrastructure for such early constant propagation, and especially setups early concrete evaluation pass. This commit should recover the regression reported at <#44776 (comment)> while preserving the advantages and correctness improvements of the `@assume_effects`-based concrete evaluation enabled in the PR.

aviatesk · 2022-04-11T11:13:04Z

@nanosoldier runbenchmarks("inference", vs=":master")

nanosoldier · 2022-04-11T11:45:40Z

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

aviatesk · 2022-04-11T12:01:07Z

Just confirmed that #44934 will fix the regressions detected by the inference benchmark.

We discussed that for certain methods like `:total`ly-declared method or `@nospecialize`d method we may want to only do constant propagation while disabling preceding only-type-level inference. This commit implements a simple infrastructure for such early constant propagation, and especially setups early concrete evaluation pass. This commit should recover the regression reported at <#44776 (comment)> while preserving the advantages and correctness improvements of the `@assume_effects`-based concrete evaluation enabled in the PR.

timholy · 2022-06-28T12:18:28Z

I was doing a little hacking on inference and noticed that include("compiler/compiler.jl") (see https://docs.julialang.org/en/v1/devdocs/inference/#Debugging-compiler.jl) no longer works. Is there a substitute? I post this here because

julia> include("compiler/compiler.jl")
WARNING: replacing module Compiler.
ERROR: LoadError: UndefVarError: ntuple not defined
Stacktrace:
 [1] getindex(t::Tuple, r::Core.Compiler.UnitRange{Int64})
   @ Core.Compiler ./range.jl:414
 [2] var"@assume_effects"(__source__::LineNumberNode, __module__::Module, args::Vararg{Any})
   @ Core.Compiler ./expr.jl:628
 [3] include
   @ ./boot.jl:368 [inlined]
 [4] include(x::String)
   @ Core.Compiler ~/src/julia-master/base/compiler/compiler.jl:23
 [5] top-level scope
   @ ~/src/julia-master/base/compiler/compiler.jl:93
 [6] eval(m::Module, e::Any)
   @ Core ./boot.jl:370
 [7] top-level scope
   @ ~/src/julia-master/base/compiler/compiler.jl:3
 [8] include(fname::String)
   @ Base.MainInclude ./client.jl:472
 [9] top-level scope
   @ REPL[1]:1
in expression starting at namedtuple.jl:221
in expression starting at namedtuple.jl:221
in expression starting at /home/tim/src/julia-master/base/compiler/compiler.jl:3

traces to a line in namedtuple.jl that was touched as part of this PR.

aviatesk · 2022-06-29T02:07:58Z

Should be fixed by #45849.

aviatesk requested a review from vtjnash March 28, 2022 13:06

oscardssmith reviewed Mar 28, 2022

View reviewed changes

Keno reviewed Mar 28, 2022

View reviewed changes

vtjnash reviewed Mar 28, 2022

View reviewed changes

base/broadcast.jl Outdated Show resolved Hide resolved

vtjnash reviewed Mar 28, 2022

View reviewed changes

base/essentials.jl Outdated Show resolved Hide resolved

vtjnash reviewed Mar 28, 2022

View reviewed changes

base/tuple.jl Outdated Show resolved Hide resolved

aviatesk mentioned this pull request Mar 29, 2022

effects: add reflection utility for the new effect analysis #44785

Merged

aviatesk force-pushed the avi/total_or_error branch 3 times, most recently from fdf30db to 16aabfa Compare March 30, 2022 04:32

aviatesk force-pushed the avi/pure2effects branch from 52400d9 to 7865fc2 Compare March 30, 2022 04:32

aviatesk force-pushed the avi/total_or_error branch from 16aabfa to 4e68d57 Compare March 30, 2022 04:33

aviatesk force-pushed the avi/pure2effects branch from 7865fc2 to 5bd710a Compare March 30, 2022 04:34

aviatesk force-pushed the avi/pure2effects branch from 5bd710a to 506e444 Compare March 30, 2022 06:50

aviatesk force-pushed the avi/pure2effects branch 2 times, most recently from 4fd0b88 to 91bef41 Compare April 2, 2022 02:12

aviatesk force-pushed the avi/pure2effects branch from 91bef41 to 659bfe8 Compare April 4, 2022 06:05

aviatesk force-pushed the avi/pure2effects branch from 659bfe8 to 0953fa9 Compare April 8, 2022 08:09

aviatesk force-pushed the avi/pure2effects branch from 0953fa9 to cdb7c37 Compare April 11, 2022 11:12

aviatesk mentioned this pull request Apr 11, 2022

inference: early const-prop' pass #44934

Open

aviatesk added the merge me PR is reviewed. Merge when all tests are passing label Apr 11, 2022

aviatesk merged commit dfe0e34 into master Apr 11, 2022

aviatesk deleted the avi/pure2effects branch April 11, 2022 14:34

ericphanson mentioned this pull request Apr 12, 2022

Switch to effects system from @pure on 1.9? JuliaData/Tables.jl#280

Open

DilumAluthge removed the merge me PR is reviewed. Merge when all tests are passing label Apr 12, 2022

maleadt mentioned this pull request Jan 20, 2023

Overlay methods disabling IR interpreter breaks const-prop of GPU-incompatible code JuliaGPU/GPUCompiler.jl#384

Closed

vchuravy mentioned this pull request Apr 24, 2023

Mark typeintersect pure for Julia 1.9 JuliaArrays/StaticArrays.jl#1156

Merged

johnomotani mentioned this pull request Aug 8, 2023

Type instability in ccolor on julia-1.9.x when using --check-bounds=no JuliaGraphics/ColorTypes.jl#292

Open

maleadt mentioned this pull request Jan 17, 2024

Improve optimization of overlay methods #52940

Closed

aviatesk mentioned this pull request Sep 26, 2024

invalid usage of @assume_effects in base/irrationals.jl #55874

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

replace `@pure` annotations in Base with effect settings #44776

replace `@pure` annotations in Base with effect settings #44776

aviatesk commented Mar 28, 2022 •

edited

Loading

oscardssmith Mar 28, 2022

oscardssmith Mar 28, 2022

oscardssmith Mar 28, 2022

StefanKarpinski Mar 28, 2022

simeonschaub Mar 28, 2022 •

edited

Loading

oscardssmith Mar 30, 2022

KristofferC Mar 30, 2022

aviatesk Mar 30, 2022

Keno Mar 28, 2022

vtjnash Mar 28, 2022

aviatesk Mar 30, 2022

nanosoldier commented Mar 28, 2022

vtjnash Mar 28, 2022

KristofferC commented Mar 28, 2022

aviatesk commented Mar 30, 2022

aviatesk commented Mar 30, 2022

aviatesk commented Apr 2, 2022

nanosoldier commented Apr 2, 2022

aviatesk commented Apr 4, 2022

nanosoldier commented Apr 4, 2022

aviatesk commented Apr 4, 2022 •

edited

Loading

aviatesk commented Apr 11, 2022

nanosoldier commented Apr 11, 2022

aviatesk commented Apr 11, 2022

timholy commented Jun 28, 2022 •

edited

Loading

aviatesk commented Jun 29, 2022

replace @pure annotations in Base with effect settings #44776

replace @pure annotations in Base with effect settings #44776

Conversation

aviatesk commented Mar 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simeonschaub Mar 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nanosoldier commented Mar 28, 2022

Choose a reason for hiding this comment

KristofferC commented Mar 28, 2022

aviatesk commented Mar 30, 2022

aviatesk commented Mar 30, 2022

aviatesk commented Apr 2, 2022

nanosoldier commented Apr 2, 2022

aviatesk commented Apr 4, 2022

nanosoldier commented Apr 4, 2022

aviatesk commented Apr 4, 2022 • edited Loading

aviatesk commented Apr 11, 2022

nanosoldier commented Apr 11, 2022

aviatesk commented Apr 11, 2022

timholy commented Jun 28, 2022 • edited Loading

aviatesk commented Jun 29, 2022

replace `@pure` annotations in Base with effect settings #44776

replace `@pure` annotations in Base with effect settings #44776

aviatesk commented Mar 28, 2022 •

edited

Loading

simeonschaub Mar 28, 2022 •

edited

Loading

aviatesk commented Apr 4, 2022 •

edited

Loading

timholy commented Jun 28, 2022 •

edited

Loading