#rust-lang

/

      • Zoxc
        eddyb: So if we have a generator created in this function which doesn't escape, we can replace it with it's variables and the state variable and use those directly when inlining resume()?
      • cjm joined the channel
      • That does get rid of the loads and stores atleast
      • eddyb
        aaaah the nonescaping part is
      • hmm
      • no you can always inline resume
      • it's just weirder
      • bleh
      • Zoxc
        eddyb: I just though of a generalization of my await optimization
      • Say we have some loop that runs an freshly created generator to completion and handles every yield with some body of code. We can then inline the generator and replace yield statements inside with the body of code which handles it. This would apply to both await/`yield from` and for loops over iterators. This is kind of like 2-way inlining.
      • eddyb
        that is how inlining returns works :P
      • you branch to the call destination
      • you might also be thinking of jumo threading
      • I wish there was a compendium of compiler optimizations somewhere
      • Ericson2314
        Zoxc: push-based?
      • I've wanted to do this
      • Zoxc
        This is a bit higher level though, and could possibly cut down compile time (if iterators are implemented as generators)
      • Ericson2314
        call it pasts-rs lolololol
      • eddyb
        Zoxc: it's the same thing
      • the only novelty is threading an enum return
      • as multiple returns (see: Thorin)
      • Ericson2314
        multiple return pointers?!?!
      • my fav
      • eddyb
        but the language they use has GC closure so they don't seem to put a lot of emphasis on low-level constraints
      • Ericson2314: my latest plans for decompiler stuff involves CPS :P
      • Ericson2314
        *de*compiler?
      • Zoxc
        eddyb: It doesn't have to be novel, it just has to work =P
      • Ericson2314
        is this a new distraction? :D
      • eddyb
        old distraction revisited
      • I reinvented binary lambda calculus from first principles sooo meh
      • Zoxc
        eddyb: LLVM cannot perform that optimization if the body of code handling yield itself contains a yield
      • eddyb
        Zoxc: there is no such thing as body of codr
      • if you look at a CFG you'll know what I mean
      • Zoxc
        eddyb: Any idea how we can use generators in the Iterator default methods?
      • I guess that wouldn't be a good idea
      • eddyb
        not unless you can figure out how to make them go backwards
      • Zoxc
        Not sure how I can fit a generator into the public struct implementing debug either
      • eddyb: Look at the LLVM output of gen_test() here https://is.gd/WOD0Dz
      • gen_test corresponds to the pre-transform IR of a generator which awaits on generator A
      • It really wants to keep that loop around. It does figure out the return value though
      • kimundi has quit
      • kimundi joined the channel
      • nagisa joined the channel
      • succ has quit
      • succ joined the channel
      • niconii has quit
      • blank_name2 has quit
      • nagisa has quit
      • nagisa joined the channel
      • blank_name2 joined the channel
      • nagisa has quit
      • nagisa joined the channel
      • Sascha joined the channel
      • Sascha has quit
      • Sascha joined the channel
      • nagisa has quit
      • Sascha has quit
      • nagisa joined the channel
      • vadimcn has quit
      • Aaronepower has quit
      • shymega has quit
      • shymega joined the channel
      • arielby joined the channel
      • blank_name2 has quit
      • Aaronepower joined the channel
      • mib_3ebnwj joined the channel
      • mib_3ebnwj has quit
      • nagisa has quit
      • blank_name joined the channel
      • petso joined the channel
      • niconii joined the channel
      • petso has quit
      • brson joined the channel
      • brson has quit
      • brson joined the channel
      • russ_za joined the channel
      • brson has quit
      • arielby has quit
      • acrichto joined the channel
      • aturon
        nmatsakis: i'm confused about a few things in your latest comment on the privacy thread
      • you say "Just saying that it is an error to access private methods/fields/etc (but allowing private types to be inferred elsewhere) feels like a relatively simple rule, but it does admit a few odd things"
      • and then one example of that is "Similarly, it feels odd (to me) to have to normalize an associated type to find out if a type is illegal"
      • but these seem at odds to me?
      • it depends i guess on what "private types to be inferred elsewhere" means
      • nmatsakis
        aturon: yeah I think I lost track of what I was talking about in that bullet list :)
      • it seems like I shifted to petrochenkov's proposal half-way through
      • humbug
      • aturon
        nmatsakis: i'll write a reply with some of my other questions and try to clarify a bit more
      • nmatsakis
        k
      • jareks joined the channel
      • brson joined the channel
      • jareks has quit
      • Aaronepower has quit
      • Tobba has quit
      • Tobba joined the channel
      • brson has quit
      • brson joined the channel