Also, gitter perhaps appears to be down? This could cause a problem for chatting 
This has the additional advantage that you can easily pickle problematic inputs, and I can pick them up and check them out cry uncle as appropriate. It's a bit easier to do "perf work" on Datalog stuffs when you can toss in some relation counting, or cardinality measurements, etc.
Yes. I also love the idea of having a “reference implementation” – if we take this approach, we can maintain two implementations in parallel. The naive one, which is basically just transcribing the datalog rules, and the optimized one. (I’m not yet 100% sure if the optimized one should use differential-dataflow or not, as an aside.) Then we can compare the results. Seems awesome!
anything that reduces the surface area for contributing is a welcome change 
OK, as a first step then, I’m going to see if I can extract the -Znll-facts PR.
1 Like
OK, this is now on the branch nll-alias-analysis-flat. I’m going to rebase and open a PR.
Update: the repository is here:
I’ve been opening various issues describing improvements we can make. I’m starting to get into the more meaty ones, which describe possible performance experiments. The repo includes some sample inputs as well as instructions for how to generate more.
4 Likes
@pnkfelix and I had a chat today about strategy. We decided to try for a two-pronged assault:
- On rust-lang master, we will land a weakened version of NLL that we hypothesize will be much more efficient (but much less expressive). This will be based on the SEME regions described by @zwarich in RFC 396.
- I’ve implemented the RFC in this github repo and I plan to try and integrate it with the existing NLL implementation.
- In the meantime, we will continue to improve the more expressive
borrow-checkdefinition implementation until it is performant.
The idea is that if we can get a working, but suboptimal, NLL sooner, that will let us put more effort into the “polish” (e.g., error messages). We can also proceed to enabling warnings and things derived from MIR borrowck, which closes a large number of bugs with the existing AST-based borrowck.
(I do not believe that SEME regions alone will be a terribly satisfying final result – they don’t cover a lot of the examples we had in mind for NLL. But they will definitely be a big improvement on the status quo in the meantime, and they are expressive enough to overcome a number of false positives that arise from fixing the bugs in the AST borrowck.)
(In parallel, I expect us to continue working on the borrow-check repo. Once we are able to get the analysis sufficiently fast, we can work on converting the MIR borrowck to use those results. Personally I hope to drive that development more through mentoring than direct coding, in part because I would like to have a group of people that know the codebase well, rather than being the only one.)
7 Likes
@nikomatsakis If the algorithm is sound why don't just for everything 1. check with SEME regions 2. if errors detected, just use the more expressive algorithm to check it again and replace the previous errors detected with the new result. Can't it work this way?
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.