Stream: t-compiler/wg-polonius

Topic: general


Jake Goulding (Mar 11 2019 at 19:47, on Zulip):

I'll speak for myself but I describe Polonius as NLL 2.0

Clearly that should be denoted as NLL(2)

Jake Goulding (Mar 24 2019 at 14:22, on Zulip):

The Zulip documentation uses "Polonius" as an example username. What are the odds?

Albin Stjerna (Apr 08 2019 at 07:11, on Zulip):

I have noticed that I cannot compile the rand crate (which is a very common dependency) with Polonius enabled in the Rust nightly (-Zpolonius -Zborrowck=mir -Ztwo-phase-borrows, though the same happens without -Zpolonius). I get this error:

/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:24: error[E0499]: cannot borrow `_` as mutable more than once at a time
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0506]: cannot assign to `_` because it is borrowed
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0499]: cannot borrow `_` as mutable more than once at a time
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0506]: cannot assign to `_` because it is borrowed
error: aborting due to 4 previous errors
error: Could not compile `rand`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Why is this and should I be using a different set of parameters?

Albin Stjerna (Apr 08 2019 at 07:38, on Zulip):

Also, where is everybody? I haven't heard anything from anyone in weeks now?

pachi (Apr 08 2019 at 08:50, on Zulip):

@Albin Stjerna , some people, like @nikomatsakis and @Santiago Pastorino have been in Rustconf Latam last week.

Albin Stjerna (Apr 08 2019 at 08:50, on Zulip):

@pachi I see, and they stayed for two weeks? Makes sense

pachi (Apr 08 2019 at 08:51, on Zulip):

Probably they were preparing or organising the conf

Santiago Pastorino (Apr 08 2019 at 11:06, on Zulip):

the conference was in Montevideo which is where I live, so I didn't move

Santiago Pastorino (Apr 08 2019 at 11:06, on Zulip):

had a lot of work :)

Santiago Pastorino (Apr 08 2019 at 11:09, on Zulip):

I have noticed that I cannot compile the rand crate (which is a very common dependency) with Polonius enabled in the Rust nightly (-Zpolonius -Zborrowck=mir -Ztwo-phase-borrows, though the same happens without -Zpolonius). I get this error:

/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:24: error[E0499]: cannot borrow _ as mutable more than once at a time
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0506]: cannot assign to _ because it is borrowed
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0499]: cannot borrow _ as mutable more than once at a time
/Users/albin/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.6/src/read.rs:73:29: error[E0506]: cannot assign to _ because it is borrowed
error: aborting due to 4 previous errors
error: Could not compile rand.
warning: build failed, waiting for other jobs to finish...
error: build failed

Why is this and should I be using a different set of parameters?

if you compile that just with nll on I guess that works, right?

Santiago Pastorino (Apr 08 2019 at 11:12, on Zulip):

oh, just noticed that you said that it doesn't work without -Zpolonius, if you do -Zborrowck=mir -Ztwo-phase-borrows you're running in pure nll mode

Santiago Pastorino (Apr 08 2019 at 11:13, on Zulip):

have you checked rand code?

Albin Stjerna (Apr 08 2019 at 11:51, on Zulip):

have you checked rand code?

no, but I did compile it with just NLL (that is, without the Polonius command switch; it works neither with nor without). I figured that I maybe was doing the wrong thing.

Albin Stjerna (Apr 08 2019 at 11:55, on Zulip):

It seems those are from a quite old version though, so maybe that's the reason

Albin Stjerna (Apr 08 2019 at 11:56, on Zulip):

Yes, because it seems the master branch compiles, I think

Albin Stjerna (Apr 08 2019 at 11:56, on Zulip):

Or so my preliminary tests say

Santiago Pastorino (Apr 08 2019 at 14:02, on Zulip):

have you checked rand code?

no, but I did compile it with just NLL (that is, without the Polonius command switch; it works neither with nor without). I figured that I maybe was doing the wrong thing.

I'm not sure what does that means exactly

Santiago Pastorino (Apr 08 2019 at 14:02, on Zulip):

it doesn't work in Polonius

Santiago Pastorino (Apr 08 2019 at 14:02, on Zulip):

it works using migrate mode

Santiago Pastorino (Apr 08 2019 at 14:02, on Zulip):

and it doesn't work in nll only mode

Santiago Pastorino (Apr 08 2019 at 14:02, on Zulip):

?

Santiago Pastorino (Apr 08 2019 at 14:03, on Zulip):

that's what you meant?

Santiago Pastorino (Apr 08 2019 at 14:04, on Zulip):

remember that in migrate mode if nll fails falls back to ast mode

Santiago Pastorino (Apr 08 2019 at 14:04, on Zulip):

it may be happening something like that

Albin Stjerna (Apr 08 2019 at 17:36, on Zulip):

it works using migrate mode

What is migrate mode? No options at all? In that case, yes, I presume it does, or nobody would depend on those crates

Albin Stjerna (Apr 08 2019 at 17:37, on Zulip):

But this is surprising to me, as I thought NLL was supposed to only allow more types of code by expanding the reasoning, so everything that compiles without NLL should compile with it, right?

Vytautas Astrauskas (Apr 09 2019 at 13:57, on Zulip):

But this is surprising to me, as I thought NLL was supposed to only allow more types of code by expanding the reasoning, so everything that compiles without NLL should compile with it, right?

As far as I know, it can happen that the code used to compile because the old AST borrow checker has a bug that was fixed in NLL. In this case, the compiler should report a warning instead of a hard error.

Albin Stjerna (Apr 09 2019 at 13:58, on Zulip):

That was my impression as well, but these are absolutely hard errors. In that case, I think it's worth a bit of detective work to figure out what is going on

Vytautas Astrauskas (Apr 09 2019 at 14:01, on Zulip):

Wait, do you know whether using -Zborrowck=mir isn't basically telling rustc to use the MIR borrow checker without migrate mode?

Vytautas Astrauskas (Apr 09 2019 at 14:04, on Zulip):

It seems that the default for -Zborrowck now is migrate: https://github.com/rust-lang/rust/blob/a5dfdc589a1b44f01cb640cd0244372dcbbd6f37/src/tools/compiletest/src/runtest.rs#L1845.

Vytautas Astrauskas (Apr 09 2019 at 14:05, on Zulip):

@Albin Stjerna Do you get a warning when compiling the rand crate with no flags?

Albin Stjerna (Apr 09 2019 at 14:06, on Zulip):

@Vytautas Astrauskas I haven't tried it, mainly because it's an old version being pulled in as a dependency of another crate, but I presume it must have at some point compiled with something

Albin Stjerna (Apr 09 2019 at 14:07, on Zulip):

I wanted to hear if this was expected before investigating further as it's incredibly tangential to what I am actually doing, which is trying out Polonius on some crates

Vytautas Astrauskas (Apr 09 2019 at 15:14, on Zulip):

I see. Makes sense.

Keith Yeung (Apr 10 2019 at 18:43, on Zulip):

is there any outstanding work that I can contribute to? i've been trying to re-familiarize myself with polonius

lqd (Apr 12 2019 at 11:09, on Zulip):

interesting finding about rand-0.4.6 as for me it doesn't build with -Zpolonius (regardless of the variant, and without testing the Hybrid one) on the latest nightly and with these same errors -- but does build with AST and MIR borrowck. AFAICT the rand 0.4.* versions are "old" (0.4.6 is recent but the first 0.4 is from 2017), and the latest, 0.6.5, seems to build both with and without -Zpolonius, I think because the code has been since changed. I'll look at extracting it, but it might be some of the more advanced cases where the behaviour differs in rustc between NLL and polonius (I think because not everything is "hooked up", Matthew would know more since they were the ones who managed to re-enable polonius and I forgot which cases were handled and which weren't -- I could be misremembering though)

lqd (Apr 12 2019 at 14:32, on Zulip):

the rand 0.4.6 NLL / polonius difference: extraction, reduction

lqd (Apr 19 2019 at 17:49, on Zulip):

I've finally moved the parser to dev dependencies so that clean builds are way shorter without having to build lalrpop et al :) (in polonius#106)

nikomatsakis (Apr 19 2019 at 19:45, on Zulip):

Dag nabbit, one of these days I will make LALRPOP build faster.

nikomatsakis (Apr 19 2019 at 19:45, on Zulip):

But in the meantime :P maybe we should switch to that PEG parser crate I see floating about?

nikomatsakis (Apr 19 2019 at 19:45, on Zulip):

This one https://github.com/pest-parser/pest

nikomatsakis (Apr 19 2019 at 19:46, on Zulip):

Looks pretty nifty and -- for this purpose -- PEG seems just fine.

nikomatsakis (Apr 19 2019 at 19:47, on Zulip):

I've finally moved the parser to dev dependencies so that clean builds are way shorter without having to build lalrpop et al :) (in polonius#106)

@lqd merged but see above :)

lqd (Apr 19 2019 at 19:50, on Zulip):

ah yes, interesting thought :) a PEG crate for nom came out recently as well (unsure about licensing though, GPL)

nikomatsakis (Apr 19 2019 at 19:57, on Zulip):

yeah, whichever. I have no opinion about licensing. Prob best to avoid GPL if we can

Albin Stjerna (May 08 2019 at 08:47, on Zulip):

I have a general code style question. One of the things that has been making it hard for me to follow the code in rustc is the use of very large container types with generic names like "facts". I am therefore considering using a style where I write more verbose but also more explicit code. For example, changing the fact-extracting visitor from this:

 LivenessFactsExtractor {
        facts,
        location_table,
}
    .visit_mir(mir);
}

to this:

LivenessPointFactsExtractor {
        var_defined: &mut facts.var_defined,
        var_used: &mut facts.var_used,
        var_drop_used: &mut facts.var_drop_used,
        location_table,
    }
    .visit_mir(mir);
Albin Stjerna (May 08 2019 at 08:48, on Zulip):

What I like about this is that it's now explicit from the code which facts are actually populated, and from the name that it is point-associated facts. What I don't like is that it's way more verbose than before, and what I'm ambivalent about is that it's more brittle to changes in interfaces, which is sometimes a good thing and sometimes a bad thing I think

Albin Stjerna (May 08 2019 at 08:49, on Zulip):

A particular bad smell is that I now have to re-declare the types of the vectors that are populated, which is good (I see the types involved right there in the file I am working on) and bad (if they change I have to change them everywhere)

nikomatsakis (May 08 2019 at 12:47, on Zulip):

Yeah, I can imagine that it's kind of non-obvious which fact sets are populated where. I don't have a strong opinion. I'd say try it for a while and see how it feels.

nikomatsakis (May 08 2019 at 12:48, on Zulip):

Regarding the types, you could also consider a type alias

nikomatsakis (May 08 2019 at 12:48, on Zulip):

But overall I don't think they're repeated that many times, and obviously the compiler will catch any place that you overlook, so I wouldn't worry abut it myself.

lqd (May 14 2019 at 10:24, on Zulip):

I finally posted the notes from the previous meetings, sorry it took this long

lokalmatador (May 14 2019 at 14:52, on Zulip):

I won't be able to attend the meeting tonight as of some work event...sorry...but, to update you: currently working through the profiling stuff and soon able to start emitting data from the compiler - fingers crossed!

lqd (May 14 2019 at 15:40, on Zulip):

@lokalmatador thanks for the heads up :)

nikomatsakis (May 14 2019 at 17:37, on Zulip):

@lokalmatador awesome!

nikomatsakis (May 14 2019 at 17:37, on Zulip):

I actually don't know if I can make it to the meeting tonight either

lqd (May 24 2019 at 09:19, on Zulip):

(as mentioned a couple weeks ago, I'll be traveling next week :beach:)

Albin Stjerna (May 28 2019 at 10:03, on Zulip):

Apparently, this is a control flow graph: pasted image

Albin Stjerna (May 28 2019 at 10:03, on Zulip):

(I'm extending Polonius to generate graphviz files with liveness data for easier visualisation and debugging)

Albin Stjerna (May 28 2019 at 10:04, on Zulip):

I'm hoping to generate, as my subject reviewer named them, "fat rainbows" of liveness trails across these for my thesis

nikomatsakis (May 28 2019 at 13:47, on Zulip):

Apparently, this is a control flow graph: pasted image

strangely beautiful

lqd (Jun 17 2019 at 19:09, on Zulip):

sorry I might not be able to make it to tomorrow's meeting; I think Niko might be unavailable because of Mozilla All Hands — if that's the case, maybe we can have async updates this week ? (I myself have continued on the the test suite, the easy cases are pretty much done — but will need a 2nd set of eyes — and the more problematic cases seem very much like bugs; I'd like to investigate more, esp around facts which might be missing) (I still haven't typed up notes for last week's meeting sorrryyyyyyyyy my plan is to do so on thursday)

nikomatsakis (Jun 17 2019 at 20:34, on Zulip):

I am indeed unavailable this week

Albin Stjerna (Jun 17 2019 at 20:46, on Zulip):

I'll report in tomorrow, but I have progress (or, well, more failing test cases than before, but still). In case I manage to work everything out before the next meeting and everyone's gone, I can always work on teaching myself enough about type systems to understand the Oxide paper

Albin Stjerna (Jun 18 2019 at 16:03, on Zulip):

Ok, update: I have spent some time working on generating var_initialized_on_exit facts in rustc. It's almost working, and results are promising, but I have a problem with the start of unwind blocks not having their variables initialised. I'm doing this in trace.rs:

fn add_polonius_var_initialized_on_exit_for(&mut self, local: Local) {
    let move_path = self.cx.move_data.rev_lookup.find_local(local);
    let facts = self.cx.typeck.borrowck_context.all_facts.as_mut().unwrap();
    for block in self.cx.body.basic_blocks().indices() {
        debug!("polonius: generating initialization facts for {:?} in {:?}", local, block);

        // iterate through the block, applying the effects of each statement
        // up to and including location, and populate `var_initialized_on_exit`
        self.cx.flow_inits.reset_to_entry_of(block);

        for statement_index in 0..self.cx.body[block].statements.len() {
            let current_location = Location { block, statement_index };

            self.cx.flow_inits.reconstruct_statement_effect(current_location);

            // statement has not yet taken effect:
            if self.cx.flow_inits.has_any_child_of(move_path).is_some() {
                facts
                    .var_initialized_on_exit
                    .push((local, self.cx.location_table.start_index(current_location)));
            }

            // statement has now taken effect
            self.cx.flow_inits.apply_local_effect(current_location);

            if self.cx.flow_inits.has_any_child_of(move_path).is_some() {
                facts
                    .var_initialized_on_exit
                    .push((local, self.cx.location_table.mid_index(current_location)));
            }
        }

        // apply the effects of the terminator and push it if needed
        let terminator_location = self.cx.body.terminator_loc(block);
        self.cx.flow_inits.reset_to_exit_of(block);

        if self.cx.flow_inits.has_any_child_of(move_path).is_some() {
            facts
                .var_initialized_on_exit
                .push((local, self.cx.location_table.mid_index(terminator_location)));
        }
    }
}

In other words, I am going through the statements of each block and for each statement emit facts for the start and mid-point of each Location before and after the statement has taken effect respectively. I suspect I should do something before the first statement of each block to get the flow analysis to "catch up". Any suggestions?

Albin Stjerna (Jun 18 2019 at 16:05, on Zulip):

(I had to emit facts for each Location, as the propagation of drop-liveness would stop as soon as it reached a Location where the facts were not emitted, due to how the rules are currently written)

Albin Stjerna (Jun 18 2019 at 16:05, on Zulip):

(for return blocks everything works fine)

Albin Stjerna (Jun 18 2019 at 16:06, on Zulip):

...I think

Albin Stjerna (Jun 18 2019 at 16:36, on Zulip):

Yes, I can confirm: if I manually edit the input facts so that the first Location has the same initialization for Start as for Mid, it produces the same region_live_atas rustc does for one of the problematic test cases

lokalmatador (Jun 18 2019 at 17:20, on Zulip):

hi, I unfortunately won't be able to make it to the meeting tonight. Nevertheless, short update: working on perf stuff, should have some results next week.

Albin Stjerna (Jun 19 2019 at 17:09, on Zulip):

Also, ping @nikomatsakis for https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius/topic/general/near/168415534 whenever you get back! I still haven't figured this out.

Albin Stjerna (Jun 19 2019 at 17:11, on Zulip):

I will also be away next week from Wednesday, as my girlfriend finally comes back from Australia on Wednesday, and I have a family vacation Thursday--Sunday.

nikomatsakis (Jun 24 2019 at 18:25, on Zulip):

@Albin Stjerna sorry, was very busy last week, let me check that out now

nikomatsakis (Jun 24 2019 at 18:28, on Zulip):

I'm wondering if you are having some problems due to the before_statement_effect, which I kind of forgot about

nikomatsakis (Jun 24 2019 at 18:29, on Zulip):

Yes, I can confirm: if I manually edit the input facts so that the first Location has the same initialization for Start as for Mid, it produces the same region_live_atas rustc does for one of the problematic test cases

can you say a bit more about this?

nikomatsakis (Jun 24 2019 at 18:29, on Zulip):

i.e., what is the value before you changed it, and what is the value afterwards?

nikomatsakis (Jun 24 2019 at 18:30, on Zulip):

actually the before_statement_effect is only relevant to the "borrows" set, which isn't the dataflow we're walking over here, so that's probably irrelevant

nikomatsakis (Jun 24 2019 at 18:46, on Zulip):

i.e., what is the value before you changed it, and what is the value afterwards?

another option @Albin Stjerna would be to point me at your branch + the test in question

Albin Stjerna (Jun 24 2019 at 19:35, on Zulip):

@nikomatsakis Welcome back! Ok, what seems to happen is that with the new fact-generation code and the new var_drop_live code, the maybe-initialized-drop-with-uninitialized-fragments test case _almost_ works. However, in the specific case of an unwind block when some variables are initialised in the parent block, they seem to be not initialised (that is, missing) in the generated facts for the start of the first line of the unwind block. They "become" initialised again at mid-point, but by then the liveness propagation may have stopped and it's too late.

What I specifically did was adding the following facts to var_initialized_on_exit:

- "_6"  "Start of bb9[0]"
- "_6"  "Start(bb3[0])"
- "_6"  "Start(bb11[3])"
- "_6"  "Start(bb13[0])"
- "_6"  "Start(bb14[3])"
- "_6"  "Start(bb12[0])"
- "_2"  "Start(bb3[0])"
Albin Stjerna (Jun 24 2019 at 19:35, on Zulip):

This is all very weird, because it works for the return successor!

Albin Stjerna (Jun 24 2019 at 19:36, on Zulip):

So I suspect I am somehow missing some detail of how the reset of flow_init works. Maybe I need to shake something/pull some lever for something to reset-but-not-that-much

nikomatsakis (Jun 24 2019 at 19:45, on Zulip):

@Albin Stjerna yeah that code is just a bit subtle...

nikomatsakis (Jun 24 2019 at 19:45, on Zulip):

let me check out the dumped mir I guess

Albin Stjerna (Jun 24 2019 at 19:46, on Zulip):

Thanks :)

nikomatsakis (Jun 24 2019 at 19:59, on Zulip):

@Albin Stjerna do you know if all of those are needed?

nikomatsakis (Jun 24 2019 at 19:59, on Zulip):

e.g., the first one is a bit strange

nikomatsakis (Jun 24 2019 at 19:59, on Zulip):

since (from what I can tell) _6 is moved in bb7 which dominates bb9 (I think)

nikomatsakis (Jun 24 2019 at 19:59, on Zulip):

otoh bb3 .. seems correct

nikomatsakis (Jun 24 2019 at 20:01, on Zulip):

hmm but bb9 has a drop of _6

nikomatsakis (Jun 24 2019 at 20:01, on Zulip):

I guess I should view the dot

Albin Stjerna (Jun 24 2019 at 20:02, on Zulip):

maybe-initialized-drop-with-uninitialized-fragments-facts.pdf maybe-initialized-drop-with-uninitialized-fragments-liveness.pdf

nikomatsakis (Jun 24 2019 at 20:02, on Zulip):

since (from what I can tell) _6 is moved in bb7 which dominates bb9 (I think)

ok that's mistaken, it's a move of _6.1

nikomatsakis (Jun 24 2019 at 20:04, on Zulip):

@Albin Stjerna what are you using var_initialized_on_exit for?

nikomatsakis (Jun 24 2019 at 20:04, on Zulip):

that's a .. dangerous concept

nikomatsakis (Jun 24 2019 at 20:04, on Zulip):

er wait

nikomatsakis (Jun 24 2019 at 20:04, on Zulip):

I meant specifically around the terminator

Albin Stjerna (Jun 24 2019 at 20:04, on Zulip):

@nikomatsakis I am using it for var_drop_live, as you proposed

nikomatsakis (Jun 24 2019 at 20:04, on Zulip):

yeah sorry I was confusing myself

Albin Stjerna (Jun 24 2019 at 20:05, on Zulip):

Haha it's ok, you've been away

Albin Stjerna (Jun 24 2019 at 20:05, on Zulip):

That's very normal

Albin Stjerna (Jun 24 2019 at 20:06, on Zulip):

Anyway the code for var_drop_liveis now:

// var_drop_live(V, P) :-
        //     var_drop_live(V, Q),
        //     cfg_edge(P, Q),
        //     !var_defined(V, P)
        //     var_initialized_on_exit(V, P).
        // extend p with v:s from q such that v is not in q, there is an edge from p to q
        var_drop_live_var.from_leapjoin(
            &var_drop_live_var,
            (
                var_defined_rel.extend_anti(|&(v, _q)| v),
                cfg_edge_reverse_rel.extend_with(|&(_v, q)| q),
                var_initialized_on_exit_rel.extend_with(|&(v, _q)| v),
            ),
            |&(v, _q), &p| (v, p),
        );
nikomatsakis (Jun 24 2019 at 20:07, on Zulip):

there is this subtle distinction

nikomatsakis (Jun 24 2019 at 20:07, on Zulip):

that may be relevant here

nikomatsakis (Jun 24 2019 at 20:07, on Zulip):

if you have a basic block that ends on a call like:

X = foo(...) return BB1 unwind BB2
nikomatsakis (Jun 24 2019 at 20:07, on Zulip):

then X is initialized on entry to BB1 but not on entry to BB2

nikomatsakis (Jun 24 2019 at 20:07, on Zulip):

but I don't immediately see how that's relevant to the example

nikomatsakis (Jun 24 2019 at 20:09, on Zulip):

that said

nikomatsakis (Jun 24 2019 at 20:09, on Zulip):

I'm wondering if var_initialized_on_exit_rel is really what we want, as opposed to var_initialized_on_entry

nikomatsakis (Jun 24 2019 at 20:12, on Zulip):

I'm not sure how much this matters though to your problem though

Albin Stjerna (Jun 24 2019 at 20:12, on Zulip):

I think I should think hard about those variable names in general

Albin Stjerna (Jun 24 2019 at 20:13, on Zulip):

Because they are getting very inconsistent

nikomatsakis (Jun 24 2019 at 20:14, on Zulip):

I think we want on entry -- i.e., it is live on entry to P if it is initialized on entry to P and might be dropped later

nikomatsakis (Jun 24 2019 at 20:15, on Zulip):

but what I'm trying to remember now is whether there is a good flag to dump the "initialization" data in flow-graph form

nikomatsakis (Jun 24 2019 at 20:15, on Zulip):

maybe -Zunpretty=flowgraph=main

nikomatsakis (Jun 24 2019 at 20:15, on Zulip):

but it doesn't seem to work for things that get a compilation error

nikomatsakis (Jun 24 2019 at 20:20, on Zulip):

@Matthew Jasper or @pnkfelix : is there a way to dump out the dataflow stats as part of a MIR dump?

nikomatsakis (Jun 24 2019 at 20:22, on Zulip):

I guess not

Albin Stjerna (Jun 24 2019 at 20:26, on Zulip):

I think we want on entry -- i.e., it is live on entry to P if it is initialized on entry to P and might be dropped later

I'm not completely sure this isn't what I am actually doing in the code above. :)

Albin Stjerna (Jun 24 2019 at 20:26, on Zulip):

Ok, I'm going to bed now, but I'll read up on what happened while I was away in the morning!

nikomatsakis (Jun 24 2019 at 20:41, on Zulip):

I'm not completely sure this isn't what I am actually doing in the code above. :)

Heh, yes. I think you're computing something in the middle..

nikomatsakis (Jun 24 2019 at 20:47, on Zulip):

Ah, there is this attribute, but it appears to have bitrotted:

#[rustc_mir(borrowck_graphviz_postflow="mir_dump/main.dot")]
nikomatsakis (Jun 24 2019 at 20:48, on Zulip):

at least, the output I get is rejected by dot

nikomatsakis (Jun 24 2019 at 20:59, on Zulip):

@Albin Stjerna is this code pushed to your branch in https://github.com/rust-lang/rust/pull/60266 ?

nikomatsakis (Jun 24 2019 at 21:00, on Zulip):

seems like no :(

pnkfelix (Jun 24 2019 at 21:24, on Zulip):

The attribute you identified is indeed what I would have used

pnkfelix (Jun 24 2019 at 21:25, on Zulip):

It is too bad we have not been testing that dot would be able to handle the output. Or that it conforms to a way smaller subset grammar

Albin Stjerna (Jun 25 2019 at 06:31, on Zulip):

Albin Stjerna is this code pushed to your branch in https://github.com/rust-lang/rust/pull/60266 ?

No, I wanted to avoid having 5000 commits with non-working code, but I'll push it soon!

Albin Stjerna (Jun 25 2019 at 06:32, on Zulip):

I really expected this to be something small of the type "no no you dummy you have to call yak_shave first to make the magic florb frob the bar"

Albin Stjerna (Jun 25 2019 at 06:33, on Zulip):

Err, it's 2 am where you are so maybe there's no rush

Albin Stjerna (Jun 25 2019 at 07:13, on Zulip):

@nikomatsakis Pushed! https://github.com/rust-lang/rust/pull/60266/commits/aa520f76f9330aab9e0d36a7173f92acc4a5a6d6

nikomatsakis (Jun 25 2019 at 15:59, on Zulip):

@Albin Stjerna ok let me see if I can reproduce then

nikomatsakis (Jun 25 2019 at 18:43, on Zulip):

@Albin Stjerna looks like I need some version of polonius with var_initialized_on_exit in the fact set

nikomatsakis (Jun 25 2019 at 18:44, on Zulip):

although i'm trying to do a local build where I remove some of that stuff and just insert debug!

Albin Stjerna (Jun 25 2019 at 18:44, on Zulip):

Ah, you can use this branch if you want to: https://github.com/albins/polonius/tree/phase-1-initialization

Albin Stjerna (Jun 25 2019 at 18:44, on Zulip):

It, err, should work

nikomatsakis (Jun 25 2019 at 18:45, on Zulip):

mostly I wanted debug output anyway

nikomatsakis (Jun 25 2019 at 18:45, on Zulip):

it's building now

Albin Stjerna (Jun 25 2019 at 18:45, on Zulip):

That sounds reasonable

nikomatsakis (Jun 25 2019 at 19:35, on Zulip):

@Albin Stjerna I've been inspecting these results

nikomatsakis (Jun 25 2019 at 19:37, on Zulip):

first question, you have this diff:

           //self.cx.flow_inits.reconstruct_terminator_effect(terminator_location);
            //self.cx.flow_inits.apply_local_effect(terminator_location);
            self.cx.flow_inits.reset_to_exit_of(block);
nikomatsakis (Jun 25 2019 at 19:37, on Zulip):

I assume that's just you messing around?>

nikomatsakis (Jun 25 2019 at 19:37, on Zulip):

I think the bug is really simple

nikomatsakis (Jun 25 2019 at 19:37, on Zulip):

though it took me a while to see it

Albin Stjerna (Jun 25 2019 at 19:38, on Zulip):

This is precisely what I expected!

Albin Stjerna (Jun 25 2019 at 19:38, on Zulip):

And yes, there was quite some messing around

nikomatsakis (Jun 25 2019 at 19:38, on Zulip):

you are pushing results for mid_index(terminator_location)

nikomatsakis (Jun 25 2019 at 19:38, on Zulip):

but never any results for start_index(terminator_location)

nikomatsakis (Jun 25 2019 at 19:38, on Zulip):

I think your pattern is roughly correct

nikomatsakis (Jun 25 2019 at 19:39, on Zulip):

also I've decided that "on exit" is probably indeed what we were looking for

nikomatsakis (Jun 25 2019 at 19:39, on Zulip):

though I imagine it's .. roughly equivalent to "on entry"

Albin Stjerna (Jun 25 2019 at 19:39, on Zulip):

Aaah, and I need to do that?

nikomatsakis (Jun 25 2019 at 19:40, on Zulip):

yes, all of your missing points were the start location of a terminator

Albin Stjerna (Jun 25 2019 at 19:40, on Zulip):

Doesn't the first row of the loop do that?

Albin Stjerna (Jun 25 2019 at 19:40, on Zulip):

Hm, no because that starts at the first point I guess

Albin Stjerna (Jun 25 2019 at 19:40, on Zulip):

Which isn't at the terminator?

nikomatsakis (Jun 25 2019 at 19:40, on Zulip):

it does the start/mid points of statements

Albin Stjerna (Jun 25 2019 at 19:40, on Zulip):

Ah, and the terminator isn't...ok I get it

nikomatsakis (Jun 25 2019 at 19:41, on Zulip):

anyway I think that's what's missing

nikomatsakis (Jun 25 2019 at 19:41, on Zulip):

re: on exit vs on entry, well, we have an edge P -> Q

Albin Stjerna (Jun 25 2019 at 19:42, on Zulip):

Hmm, ok, wait no, the reset_to_exit_of wasn't spurious

nikomatsakis (Jun 25 2019 at 19:42, on Zulip):

we can't say "live on entry to Q" because that's too imprecise -- Q may have multiple predecessors

Albin Stjerna (Jun 25 2019 at 19:42, on Zulip):

I thought that was the right way to "fast-forward" the flow analysis to the state at the terminator

nikomatsakis (Jun 25 2019 at 19:42, on Zulip):

Hmm, ok, wait no, the reset_to_exit_of wasn't spurious

I think it's equivalent but I'm not 100% sure

nikomatsakis (Jun 25 2019 at 19:42, on Zulip):

it would indeed fast-forward if you hadn't walked the statements already

nikomatsakis (Jun 25 2019 at 19:43, on Zulip):

but I also think it's fine

Albin Stjerna (Jun 25 2019 at 19:43, on Zulip):

Which I should have done

Albin Stjerna (Jun 25 2019 at 19:43, on Zulip):

So it should be a no-op

nikomatsakis (Jun 25 2019 at 19:43, on Zulip):

the key thing is to do this

            // apply the effects of the terminator and push it if needed
            let terminator_location = self.cx.body.terminator_loc(block);

            if self.cx.flow_inits.has_any_child_of(move_path).is_some() {
                debug!(
                    "var_initialized_on_exit({:?}, {:?})",
                    local,
                    self.cx.location_table.start_index(terminator_location),
                );
            }

            //self.cx.flow_inits.reconstruct_terminator_effect(terminator_location);
            //self.cx.flow_inits.apply_local_effect(terminator_location);
            self.cx.flow_inits.reset_to_exit_of(block);

            if self.cx.flow_inits.has_any_child_of(move_path).is_some() {
                debug!(
                    "var_initialized_on_exit({:?}, {:?})",
                    local,
                    self.cx.location_table.mid_index(terminator_location),
                );
            }
nikomatsakis (Jun 25 2019 at 19:43, on Zulip):

except not with debug! logs :)

nikomatsakis (Jun 25 2019 at 19:43, on Zulip):

So it should be a no-op

yeah I think it's .. well, not a no-op, but equivalent to the commented out lines

Albin Stjerna (Jun 25 2019 at 19:43, on Zulip):

The question is whether I need to make some additional statement at the terminator take effect before emitting the state at mid-point?

Albin Stjerna (Jun 25 2019 at 19:44, on Zulip):

That's what I think I thought too

nikomatsakis (Jun 25 2019 at 19:44, on Zulip):

you do need to do something between start/end

Albin Stjerna (Jun 25 2019 at 19:44, on Zulip):

Aah ok

Albin Stjerna (Jun 25 2019 at 19:44, on Zulip):

I'll try that and see what happens!

nikomatsakis (Jun 25 2019 at 19:44, on Zulip):

I think applying the "reconstructed terminator effect"

nikomatsakis (Jun 25 2019 at 19:44, on Zulip):

and "reset to exit of" is equivalent

nikomatsakis (Jun 25 2019 at 19:45, on Zulip):

reset to exit of basically jumps back to the start and then applies the "complete gen/kill sets" for the entire block, which I believe include all statements + terminator

nikomatsakis (Jun 25 2019 at 19:45, on Zulip):

(as it is, you've already applied the gen/kill sets up to but not including the terminator)

nikomatsakis (Jun 25 2019 at 19:45, on Zulip):

pretty sure it's "six in one, half a dozen in the other", as they say...

Albin Stjerna (Jun 25 2019 at 19:45, on Zulip):

Ok, that's where I was confused

Albin Stjerna (Jun 25 2019 at 19:45, on Zulip):

I thought the terminator was a statement

nikomatsakis (Jun 25 2019 at 19:45, on Zulip):

I see

Albin Stjerna (Jun 25 2019 at 19:47, on Zulip):

Ok, recompiling now...

Albin Stjerna (Jun 25 2019 at 20:13, on Zulip):

HA, it works for the previously failing cases

Albin Stjerna (Jun 25 2019 at 20:13, on Zulip):

But err, has a regression

Albin Stjerna (Jun 25 2019 at 20:14, on Zulip):

I'll have to look at that later

Albin Stjerna (Jun 25 2019 at 20:14, on Zulip):

I have to go to sleep now :)

Albin Stjerna (Jun 25 2019 at 20:15, on Zulip):

Or well, at least stop working and start winding down

nikomatsakis (Jun 26 2019 at 00:52, on Zulip):

But err, has a regression

which one :)

Albin Stjerna (Jun 29 2019 at 15:46, on Zulip):

@nikomatsakis (intermittently back to explain this): it's both optional_drop_enum() and drop_enum() from enum-drop-access. What seems to happen in drop_enum() (and I'd bet it's the same in optional_drop_enum()) is:

 bb8: {
          drop(_1) -> [return: bb9, unwind: bb1]; // bb8[0]: scope 0 at enum-drop-access.rs:20:1: 20:2
  }
enum DropOption<T> {
    Some(T),
    None,
}

impl<T> Drop for DropOption<T> {
    fn drop(&mut self) {}
}

// Dropping opt could access the value behind the reference,
fn drop_enum(opt: DropOption<&mut i32>) -> Option<&mut i32> {
    match opt {
        DropOption::Some(&mut ref mut r) => { //~ ERROR
            Some(r)
        },
        DropOption::None => None,
    }
}

I don't see why this bug would appear now, given that I have only added more initialisation facts from Rustc, but one is not supposed to understand everything I guess.

Albin Stjerna (Jun 29 2019 at 16:17, on Zulip):

I'll have a closer look on Monday :)

Albin Stjerna (Jul 01 2019 at 11:59, on Zulip):

Update: the reason for the problem was stale region_live_at data with incorrect locations, so I added back the code to generate region_live_at to Rustc for now, and everything is working.

Albin Stjerna (Jul 01 2019 at 12:04, on Zulip):

I'm considering if it would be a good idea to split the inputs from Rust into separate structs internally early on entry and have AllFacts just be an interface into the engine, so that the now rather orthogonal components (such as the liveness parts) can handle their own data separately. Any thoughts?

lqd (Jul 01 2019 at 17:20, on Zulip):

so I added back the code to generate region_live_at to Rustc for now, and everything is working.

this means liveness in Polonius computes the same region_live_at facts in memory, as the ones we read on disk from rustc ? if so, :tada: :)

nikomatsakis (Jul 01 2019 at 18:25, on Zulip):

@Albin Stjerna glad to hear things are working

Albin Stjerna (Jul 01 2019 at 18:30, on Zulip):

@lqd yes, precisely. :)

lqd (Jul 01 2019 at 20:32, on Zulip):

most of the test failures are triaged, there 4 cases left (3 variations on a theme, and seems possibly simple to categorize; and another "weird but probably straightforward to categorize); and in addition some cases that could be bugs in fact generation

lqd (Jul 01 2019 at 20:33, on Zulip):

possibly "ready to double check"

lqd (Jul 01 2019 at 20:35, on Zulip):

even though until all of those have issues filed or PRs posted, one could still go on — so I'll probably do so (and post the PR for the commits I have, for the issues which just look fine; if others agree with this pre-triage)

lokalmatador (Jul 02 2019 at 06:10, on Zulip):

hi, I unfortunately again won't be able to attend tonight as of going to a concert; got the tickets last year...

nikomatsakis (Jul 02 2019 at 16:32, on Zulip):

@Albin Stjerna what should I be reviewing :)

lqd (Jul 02 2019 at 16:34, on Zulip):

#60266 needs a rebase + handling conflicts it seems

lqd (Jul 02 2019 at 16:35, on Zulip):

or maybe is it still WIP :thinking:

Albin Stjerna (Jul 02 2019 at 18:18, on Zulip):

@lqd, @nikomatsakis: yes, but we also need to version-bump Polonius with the new dummy initialisation facts before the Rust branch can be merged. I’ll get that done tomorrow morning and poke you when it’s ready to review, Niko!

Albin Stjerna (Jul 02 2019 at 18:19, on Zulip):

Oh it would be so good to have the rustc branch merged and not have to deal with the constant rebasing

lqd (Jul 02 2019 at 18:31, on Zulip):

ah true :)

lqd (Jul 02 2019 at 18:46, on Zulip):

since we talked about it last week (I have not written the notes from last week's meeting :face_palm:) I think there are a couple tasks which could be tackled by new contributors:
- some refactoring: especially about naming relations, variables, or datalog rules; we were talking how requires is a name we should change, maybe test organization and the likes
- increase the coverage of the rustc integration: after talking with Matthew it seems we probably should test more of the fact generation system, add the missing features etc

lqd (Jul 02 2019 at 18:54, on Zulip):

not that they should be done by someone else, just that they might :) (I was planning on looking at fact generation next actually)

lqd (Jul 02 2019 at 18:55, on Zulip):

for debugging, some datalog provenance would be nice as well, à la Yannis Smaragdakis (who I think Niko knows) — and such a feature would likely cause naming confusion if we renamed regions to provenances :joy:

Albin Stjerna (Jul 03 2019 at 11:54, on Zulip):

Well, judging by my background research, it seems Smaragdakis is one of the go-to authorities on static analysis in Datalog

Albin Stjerna (Jul 03 2019 at 11:54, on Zulip):

@lqd Is that a trace of how the tuple propagation works?

lqd (Jul 03 2019 at 11:57, on Zulip):

yeah a provenance graph for the facts, say, this tuple was emitted at this round, because of rule X and input tuples Y from relations Z, and so on for the dependent tuples, would be useful to understand why Polonius ultimately computes an error

Albin Stjerna (Jul 03 2019 at 11:57, on Zulip):

Ah, yes; it's what I have been doing in my head to debug my code :)

lqd (Jul 03 2019 at 11:58, on Zulip):

either for debugging the whole analysis, or specific rules while we're implementing new ones (or also useful to see duplicate tuple generation, eg for performance)

Albin Stjerna (Jul 03 2019 at 11:58, on Zulip):

It's kind of fun though, propagating things across graphs. Sort of like crossword puzzles

lqd (Jul 03 2019 at 11:58, on Zulip):

yeah :)

Albin Stjerna (Jul 03 2019 at 11:58, on Zulip):

Ooh yes

lqd (Jul 03 2019 at 12:01, on Zulip):

(or an interactive mode, "please Polonius, proceed to the next round", or datafrog REPL)

lokalmatador (Jul 07 2019 at 08:27, on Zulip):

Hi,

by now I know I have not contributed much. However, I unfortunately cannot continue at this point. As of a recent job switch, I'm horribly exhausted due to an increase in work load. Also, I recently committed to training a local RoboCup team (robotics still being my favorite hobbyhorse), meaning that my evenings now will be very busy. That said and considering my own list or priorities I for now have to resign from contributing to rustc as I just don't know anymore how to fit this into my schedule. Sorry for letting you guys down, but for now this is the only feasible way for me. If at some point I again find the time to contribute, be sure I will call out once again.

Albin Stjerna (Jul 07 2019 at 20:21, on Zulip):

@lokalmatador Ok, so I can't speak in any official capacity or anything given that I'm just a random student and all, but I think this sounds like a very good way of handling shifting ground conditions and the best possible failure mode under the circumstances? The way I see things you haven't let anybody down at all. Good luck with your new job, and I hope it gets better as you settle in!

Also, please remember to take care of yourself in case it doesn't. I say this as someone who hardly knows someone who hasn't gone through completely avoidable burnout anymore.

lqd (Jul 07 2019 at 20:58, on Zulip):

@lokalmatador no worries, take care of yourself first :)

lqd (Jul 08 2019 at 15:04, on Zulip):

with Albin ending their master thesis soon, and Niko on vacation next week, maybe this WG won't need weekly sync meetings for the summer/until fall, as well ? (like wg-traits for example)

lqd (Jul 08 2019 at 18:28, on Zulip):

what do you think @nikomatsakis ?

lqd (Jul 08 2019 at 18:32, on Zulip):

(esp if there's other/more pressing work to be done during this time?)

nikomatsakis (Jul 08 2019 at 18:34, on Zulip):

that sounds right

nikomatsakis (Jul 08 2019 at 18:34, on Zulip):

I actually can't make the mtg tomorrow either

lqd (Jul 08 2019 at 18:35, on Zulip):

alright :)

nikomatsakis (Jul 08 2019 at 18:35, on Zulip):

I will adjust the calendar I guess

lqd (Jul 08 2019 at 18:39, on Zulip):

I've made progress in identifying issues in the dedicated thread and will try to continue on this and the other potential refinement until you're back

lqd (Jul 09 2019 at 11:17, on Zulip):

@Albin Stjerna it's likely going to be just us two tonight, so no real pressing need to have a meeting in the evening :) my update is: I've myself worked on the test suite quite a bit and found some interesting things, and have a promising lead thanks to Matthew and Niko. I've continued a bit on the refinement prototype and also found some interesting things there (though I still wish to investigate / need to test more). I didn't manage to write up the previous meeting notes yet (I'm not sure anybody reads them but I'll get it done eventually ;)

Albin Stjerna (Jul 09 2019 at 12:07, on Zulip):

@lqd Oh, that's great! I skimmed some of your posts but I haven't yet taken the time to get into the details of what you are doing. :)

I don't think I need a meeting either, but just to say something, I have been working a bit on my thesis and continued work on collecting crates and benchmarking/profiling their facts. It looks like the final tally might be around 10 000 repositories analysed, but workloads now take a long time to run so it's not done yet. I also did the final work to prepare the pull requests for liveness, and have written notes about what I expect to have to do to get the full initialisation analysis done. If Niko doesn't have any time to introduce me, I'll go out on a limb and see where that gets me.

Finally, I am also sort of working on taking Aaron's work on formalising the borrow check in Oxide and showing how it translates to the Polonius rules via some fudging about Mir for my thesis, with as little fudging as possible (I mean, I would love to have something formal, but I'm never going to have time for that).

lqd (Jul 09 2019 at 12:24, on Zulip):

these 10 000 repositories will come in handy to check for correctness !

lqd (Jul 09 2019 at 12:25, on Zulip):

at the very least we should be able to have a clearer picture on possible regressions, and have test cases for the features we know are missing, with your crater-lite

lqd (Jul 09 2019 at 12:27, on Zulip):

really cool, awesome job! I'm also looking forward to the rustc liveness PR landing hopefully soon :tada:

Albin Stjerna (Jul 09 2019 at 18:39, on Zulip):

Thank you, and me too!

Albin Stjerna (Jul 09 2019 at 18:43, on Zulip):

Meanwhile, in my benchmarking scripts; I am letting my Python process analysing the nll-facts call itself as a child process with each crate in order to be able to set rlimits for the child process and avoid being OOM-killed on huge inputs

lqd (Sep 26 2019 at 17:45, on Zulip):

@Matthew Jasper :tada: on https://github.com/rust-lang/rust/pull/64749 - I was actually running tests with the Location::All hack removed earlier today

lqd (Sep 26 2019 at 17:47, on Zulip):

awesome job

lqd (Sep 26 2019 at 17:49, on Zulip):

GG on the hrtb due-to-where-clause fix as well

lqd (Sep 26 2019 at 17:51, on Zulip):

I assume CI didn't run the nll compare mode but you probably did

lqd (Sep 26 2019 at 17:51, on Zulip):

(or maybe t-infra enabled it on PR builders already)

lqd (Sep 27 2019 at 19:01, on Zulip):

btw you mention a commit to revert in that PR, was it the one about running the polonius compare mode on CI which was already removed, or the latest one which is more about NLLs than Polonius per se ?

Matthew Jasper (Sep 27 2019 at 19:03, on Zulip):

I was talking about the commit that I have already reverted.

lqd (Sep 27 2019 at 19:03, on Zulip):

ah alright, I'll mark the comment resolved then

lqd (Sep 27 2019 at 19:05, on Zulip):

and S-waiting-on-review as well, since everything seems done ? (it's waiting on author rn)

lqd (Sep 27 2019 at 19:06, on Zulip):

done

lqd (Sep 30 2019 at 11:05, on Zulip):

I've been playing with rewriting the Naive rules to model demand propagation as if they were evaluated top-down (à la magic sets), and they should look like this (modulo some massaging around the errors entry point):

errors(B, P) :- d_errors_bb(B, P), invalidates(B, P), borrow_live_at(B, P).
borrow_live_at(B, P) :- d_borrow_live_at_bb(B, P), requires(R, B, P), region_live_at(R, P).
requires(R, B, P) :- d_requires_fbb(B, P), borrow_region(R, B, P).
requires(R2, B, P) :- d_requires_fbb(B, P), requires(R1, B, P), subset(R1, R2, P).
requires(R, B, Q) :- d_requires_fbb(B, Q), requires(R, B, P), !killed(B, P), cfg_edge(P, Q), region_live_at(R, Q).
requires(R, B, P) :- d_requires_fbf(B), borrow_region(R, B, P).
requires(R2, B, P) :- d_requires_fbf(B), requires(R1, B, P), subset(R1, R2, P).
requires(R, B, Q) :- d_requires_fbf(B), requires(R, B, P), !killed(B, P), cfg_edge(P, Q), region_live_at(R, Q).
subset(R1, R2, P) :- d_subset_bfb(R1, P), outlives(R1, R2, P).
subset(R1, R3, P) :- d_subset_bfb(R1, P), subset(R1, R2, P), subset(R2, R3, P).
subset(R1, R2, Q) :- d_subset_bfb(R1, Q), subset(R1, R2, P), cfg_edge(P, Q), region_live_at(R1, Q), region_live_at(R2, Q).
subset(R1, R2, P) :- d_subset_bff(R1), outlives(R1, R2, P).
subset(R1, R3, P) :- d_subset_bff(R1), subset(R1, R2, P), subset(R2, R3, P).
subset(R1, R2, Q) :- d_subset_bff(R1), subset(R1, R2, P), cfg_edge(P, Q), region_live_at(R1, Q), region_live_at(R2, Q).
d_borrow_live_at_bb(B, P) :- d_errors_bb(B, P), invalidates(B, P).
d_requires_fbb(B, P) :- d_borrow_live_at_bb(B, P).
d_subset_bfb(R1, P) :- d_requires_fbb(B, P), requires(R1, B, P).
d_requires_fbf(B) :- d_requires_fbb(B, Q).
d_subset_bfb(R1, P) :- d_requires_fbf(B), requires(R1, B, P).
d_subset_bfb(R2, P) :- d_subset_bfb(R1, P), subset(R1, R2, P).
d_subset_bff(R1) :- d_subset_bfb(R1, Q).
d_subset_bfb(R2, P) :- d_subset_bff(R1), subset(R1, R2, P).
lqd (Sep 30 2019 at 11:06, on Zulip):

as luck would have it, the result is still stratified (which was likely, but still)

lqd (Sep 30 2019 at 11:07, on Zulip):

I haven't tested this yet, but that wall of text begs a datalog-to-datafrog "compiler" (or helper at least) so I've been toying with that as well

Albin Stjerna (Sep 30 2019 at 20:03, on Zulip):

I haven't tested this yet, but that wall of text begs a datalog-to-datafrog "compiler" (or helper at least) so I've been toying with that as well

Nearing Soufflé at a frightening pace

Albin Stjerna (Sep 30 2019 at 20:03, on Zulip):

I was just going to drop in and apologise for missing the meeting when I realised it's Monday today, so that's how my day is going

Albin Stjerna (Sep 30 2019 at 20:04, on Zulip):

Just out of curiosity, how are you doing the datalog-to-datafrog-ification, are you generating Rust code or is it a macro?

Albin Stjerna (Sep 30 2019 at 20:05, on Zulip):

Can you even make Rust macros that powerful to begin with?

lqd (Sep 30 2019 at 20:24, on Zulip):

Just out of curiosity, how are you doing the datalog-to-datafrog-ification, are you generating Rust code or is it a macro?

right now just generating analysis data, rules, some indices (the joins are a bit trickier, not that much, but I haven't completed them yet). no proc macro yet, while I think it's probably doable albeit a bit tricky, it's likely to me that a macro hides too much of the generated code, whereas we'd like to see everything, reorder, remove indices, etc

lqd (Sep 30 2019 at 20:26, on Zulip):

I planned on testing this first with soufflé, and then promptly forgot about it, so I've been implementing it with datafrog and the million intermediary steps and indices ... :face_palm:

lqd (Oct 11 2019 at 16:59, on Zulip):

https://github.com/rust-lang/polonius/pull/133 fixes clap

Albin Stjerna (Oct 23 2019 at 11:25, on Zulip):

A person at SPLASH had an entire infrastructure for scraping GitHub and performing experiments so I talked to them about adapting that for my Polonius evaluations. I have no idea if that’s a good idea or not, but I figured that heck why not try. :)

Albin Stjerna (Oct 23 2019 at 11:34, on Zulip):

From what I gathered the pipeline sounded reasonable anyway

Albin Stjerna (Oct 23 2019 at 11:35, on Zulip):

I know we already have crater but if there’s an actual generalised crawling system for these types of things going around I can see why it might be a good idea to get on the bandwagon

Vytautas Astrauskas (Nov 06 2019 at 10:54, on Zulip):

A person at SPLASH had an entire infrastructure for scraping GitHub and performing experiments so I talked to them about adapting that for my Polonius evaluations. I have no idea if that’s a good idea or not, but I figured that heck why not try. :)

@Albin Stjerna Do you remember who?

Albin Stjerna (Nov 06 2019 at 11:30, on Zulip):

Yes! Andrea Rosa with the NAB project. Here: https://2019.splashcon.org/details/splash-2019-Posters/6/NAB-Automated-Large-scale-Multi-language-Dynamic-Program-Analysis-in-Public-Code-Rep

Albin Stjerna (Nov 06 2019 at 11:30, on Zulip):

I'm in an email conversation with them about how hard it would be to adapt this for my Polonius input study

Vytautas Astrauskas (Nov 06 2019 at 11:37, on Zulip):

Thanks!

Last update: Nov 15 2019 at 21:15UTC