woonki

> There's no "precedence rule". The precedences are: whatever the parser gives you. So the level of precedence is implicit in the code. I believe await has the same precedence...

If the pipe has the same precedence as the arrow `=>`, the current parsed AST looks correct. `await` has higher precedence than the pipe and arrow. ```rescript await a->b //...

Parsing looks okay now, but the printing error is due to an infinite loop. ```rescript let f12 = @a (@b x) => 3 let f13 = @a @b (~x) =>...

> expression (tests/printer/expr/asyncAwait.res[97,2562+23]..[97,2562+24]) > Pexp_constant PConst_int (3,None) ``` expression (tests/printer/expr/asyncAwait.res[97,2562+23]..[97,2562+24]) Pexp_constant PConst_int (3,None) ``` I think this is the body returns "3"

I ran a test of the compiler with the syntax submodule checked out to this branch. The test result looks fine. ``` $ make test-all ```

Rebaed to master to resolve the confict in the test txt

Rebased to master

I have the same issue here. As @SpaceK33z raised the e.g. Django filter property, Prisma needs one.

Is there any hacky way to resolve this? I have data such as `John` in DB field. How can I run query and filter for this kind of data in...

#5703