Rust ref pattern

[paldepind]

This PR aims to add support for ref in patterns.

For a let statement these two lines are equivalent:

let a = &foo;
let ref a = foo;

So we'd like their effect to be the same. For a pattern like Some(ref a) the introduced variable a is a reference and should have the content of the matched value stored in the reference content type.

The cleanest way to do this is to add a new store edge from ref a (identity pattern) -> a (name) in the data flow graph. But, currently the name nodes in the AST are not really considered everywhere from the CFG to the data flow library.

Hence this PR:

• Include names in patterns in the CFG
• Let SSA writes target the name inside identifier patterns instead of the pattern itself
• Include relevant names in the data flow graph
• Add a store step from a identifier patterns with ref into the contained name. So we have an edge ref a -> a that stores in the reference content type. For identifier patterns without a ref we add a normal value preserving step, that maintains current behavior.

Here are some diagrams depicting the change in the CFG.

Example 1

Here there is a new map node before the mut map node.

fn method_call() {
    let mut map = HashMap::new();
    map.insert(37, "a");
}

Before

flowchart TD
1["enter fn method_call"]
10["map.insert(...)"]
11["ExprStmt"]
12["37"]
13[""a""]
2["exit fn method_call"]
3["exit fn method_call (normal)"]
4["{ ... }"]
5["let ... = ..."]
6["mut map"]
7["...::new"]
8["...::new(...)"]
9["map"]

1 --> 5
3 --> 2
4 --> 3
5 --> 7
6 -- match --> 11
7 --> 8
8 --> 6
9 --> 12
10 --> 4
11 --> 9
12 --> 13
13 --> 10

Loading

After

flowchart TD
1["enter fn method_call"]
10["map"]
11["map.insert(...)"]
12["ExprStmt"]
13["37"]
14[""a""]
2["exit fn method_call"]
3["exit fn method_call (normal)"]
4["{ ... }"]
5["let ... = ..."]
6["mut map"]
7["map"]
8["...::new"]
9["...::new(...)"]

1 --> 5
3 --> 2
4 --> 3
5 --> 8
6 -- match --> 12
7 --> 6
8 --> 9
9 --> 7
10 --> 13
11 --> 4
12 --> 10
13 --> 14
14 --> 11

Loading

Example 2

This shows that the PR also makes a change regarding splitting, in that it is no longer done for identifier patterns.

fn identifier_pattern_with_ref() -> i64 {
    let mut a = 10;
    match a {
        ref mut n @ 1..10 => *n += 10,
        ref mut n => *n = 0,
    };
    a
}

Before

flowchart TD
1["enter fn identifier_pattern_with_ref"]
10["a"]
11["[match(true)] ref mut n @ ..."]
12["1"]
12["1"]
14["RangePat"]
15["10"]
15["10"]
17["* ..."]
18["... += ..."]
19["n"]
2["exit fn identifier_pattern_with_ref"]
20["10"]
21["ref mut n"]
22["* ..."]
23["... = ..."]
24["n"]
25["0"]
26["a"]
3["exit fn identifier_pattern_with_ref (normal)"]
4["{ ... }"]
5["let ... = 10"]
6["mut a"]
7["10"]
8["match a { ... }"]
9["ExprStmt"]

1 --> 5
3 --> 2
4 --> 3
5 --> 7
6 -- match --> 9
7 --> 6
8 --> 26
9 --> 10
10 --> 14
11 -- match --> 19
12 -- match --> 15
12 -- no-match --> 21
12 --> 12
14 -- match --> 12
14 -- no-match --> 21
15 -- match --> 11
15 -- no-match --> 21
15 --> 15
17 --> 20
18 --> 8
19 --> 17
20 --> 18
21 -- match --> 24
22 --> 25
23 --> 8
24 --> 22
25 --> 23
26 --> 4

Loading

After

flowchart TD
1["enter fn identifier_pattern_with_ref"]
10["ExprStmt"]
11["a"]
12["ref mut n @ ..."]
13["n"]
14["1"]
14["1"]
16["RangePat"]
17["10"]
17["10"]
19["* ..."]
2["exit fn identifier_pattern_with_ref"]
20["... += ..."]
21["n"]
22["10"]
23["ref mut n"]
24["n"]
25["* ..."]
26["... = ..."]
27["n"]
28["0"]
29["a"]
3["exit fn identifier_pattern_with_ref (normal)"]
4["{ ... }"]
5["let ... = 10"]
6["mut a"]
7["a"]
8["10"]
9["match a { ... }"]

1 --> 5
3 --> 2
4 --> 3
5 --> 8
6 -- match --> 10
7 --> 6
8 --> 7
9 --> 29
10 --> 11
11 --> 16
12 -- match --> 21
12 -- no-match --> 24
13 --> 12
14 -- match --> 17
14 -- no-match --> 24
14 --> 14
16 -- match --> 14
16 -- no-match --> 24
17 -- match --> 13
17 -- no-match --> 24
17 --> 17
19 --> 22
20 --> 9
21 --> 19
22 --> 20
23 -- match --> 27
24 --> 23
25 --> 28
26 --> 9
27 --> 25
28 --> 26
29 --> 4

Loading

[hvitved]

Overall LGTM, some minor things. As we discussed offline, there are a few CFG issues to look into follow-up. Also, remember DCA :-)

[hvitved]

I think I prefer for this to be more explicit, i.e.

last(this.getPat(), pred, c) and
first(this.getName(), succ) and
c.(MatchCompletion).succeeded()

then we should also change StandardPostOrderTree to just PostOrderTree.

[paldepind]

True, that is clearer.

[hvitved]

DCA doesn't look too happy; probably a bad join somewhere.

[paldepind]

I've fixed a very bad cartesian product. DCA went from 😭 to 😐. A few things went up and down by tiny amounts, which I don't think matters. We should be good to merge.