diff options
| author | Robin Voetter <robin@voetter.nl> | 2021-10-19 15:08:28 +0200 |
|---|---|---|
| committer | Robin Voetter <robin@voetter.nl> | 2021-10-20 03:44:02 +0200 |
| commit | b65582e834de34f2351fa04a47f20e7f9c16a47c (patch) | |
| tree | 903977d19050915584c568b9a6b04b57e0996d59 /src/zig_clang.cpp | |
| parent | bfedf40c9267367d6ffdad54050dcbd451136b58 (diff) | |
| download | zig-b65582e834de34f2351fa04a47f20e7f9c16a47c.tar.gz zig-b65582e834de34f2351fa04a47f20e7f9c16a47c.zip | |
stage2: remove AstGen none_or_ref
The remaining uses of this result location were causing a bunch of errors
problems where the pointers returned from rvalue and lvalue expressions
would be confused, allowing for extra pointers on rvalue expressions.
For example:
```zig
const X = struct {a: i32};
var x: X = .{.a = 1};
var ptr = &x;
_ = x.a;
```
In the last line, the lookup of x with result location .none_or_ref would
return a double pointer (**X). This would be dereferenced one, after which
a relative pointer to `a` would be fetched and derefenced to get the final
result.
However, this also allows us to manually construct a double pointer, and
fetch the field of the inner type of that:
```zig
_ = &(&(x)).a;
```
This problem also manifests itself with element access. There are two obvious
ways to fix the problem, both of which include replacing the usage of
.none_or_ref for field- and element accesses with something which
deterministically produce either a pointer or value: either result location
.ref or .none. In the former case, this would be paired with .elem_ptr, and
in the latter case with .elem_val.
Note that the stage 1 compiler does not have this problem, because there is
no equivalent of .elem_val and .field_val. In this way it is equivalent to
using the result location .ref for field- and element accesses.
In this case i have used .none, as this matches language behaviour more
closely.
Diffstat (limited to 'src/zig_clang.cpp')
0 files changed, 0 insertions, 0 deletions
