Move error reporting and initialisation clean-up

[amandasystems]

This PR mainly implements move error reporting. It also:

• No longer assumes child is transitive (i.e. actually maps some ancestor relation); children are now direct children, i.e child(Daughter, Mother) but not child(Daughter, Grandmother). This means it is now safe to simplify the generation code in Rust. This closes the Polonius part of child facts should only contain immediate children #120.
• Does the elaboration of move paths mentioned by Niko.
• Removes the strictly unnecessary imprecision with regards to move paths (addressed in the review of my previous PR).
• Updats the names of all facts in accordance with the new formulation, and uses the logic described there (with minor modifications).
• Removes a lot of unused input facts
• Does some slight renaming of inputs in polonius-parser

Left to do:

• Writing at least some tests Let's just use compiletest
• Document everything in the book (this would also address document init_var_maybe_initialized_on_exit #116, document how to run Polonius in Rust's unit tests in the book #119) Is now the independent Issue Import the rules from HackMD into the Polonius book #141

As mentioned in one of the comments below, polonius-parser and the unit tests need a lot of work to function with this set of new facts. The current version of polonius-parser is essentially a re-skin of the old version with the new fact names. It has no facilities for generating any of the new facts, which means that it cannot exercise any of the new logic. Additionally, there's an open and ongoing discussion about what precisely the model language used by the parser should look like, how much work it should do on its own, etc.

[amandasystems]

Facts left to add to polonius-parser:

• var_used_at
• var_dropped_at
• var_drops_region
• var_defined_at
• use_of_var_derefs_origin
• drop_of_var_derefs_origin
• child_path (I don't use Niko's reversed parent_path as I need it in this reversed form for joins due to first-tuple-part-join-limitations in Datafrog)
• path_begins_with_var
• path_assigned_at_base
• path_accessed_at_base
• path_moved_at_base

There are probably also additionally renamings.

I think we should abbreviate the names of dops, uses, and moves to just drop(x), use(x), etc. I also think there should be a single assigned(x) for both initialization-assignment and move analysis-assignment. The question then becomes how smart we should be about e.g. automatically finding variables and their paths (if I use(x.y), does that automatically declare x.y with their entire hierarchy including the root var, and emit path_moved_at_base for e.g. drops?

[amandasystems]

I have removed the WIP marker because I think this is is perhaps ready to merge now.

[lqd]

The existing tests in polonius-parser seem to fail compiling, probably fallout from the fact renaming.

[lqd]

Sorry but it's hard to tell from the GH interface: it seems most/all of the unused input facts are removed by this PR, but some are still referenced in the inputs/collect-facts.sh script ?

[amandasystems]

The existing tests in polonius-parser seem to fail compiling, probably fallout from the fact renaming.

That's really weird! Or are they not run by cargo test in the root? They all pass on my machine (tm).

[amandasystems]

Sorry but it's hard to tell from the GH interface: it seems most/all of the unused input facts are removed by this PR, but some are still referenced in the inputs/collect-facts.sh script ?

Correct; that's an oversight I'll have to fix!

[lqd]

As the tests are in a subcrate, its tests are run on demand with cargo test --all. This is the command ran by CI and about which it is complaining, for example here https://travis-ci.com/rust-lang/polonius/jobs/287849345 which has the compile error messages around the bottom.

[amandasystems]

I…didn’t think about that. Thanks; I’ll look into it!

[lqd]

🚀