assemblyscript icon indicating copy to clipboard operation
assemblyscript copied to clipboard

Parser error, i think

Open lortonx opened this issue 2 years ago • 8 comments

Bug description

I understand that I am doing the wrong things in the assembly script, but it seems to me that this error should not look like what is shown below. Hope this helps improve Assemblyscript. image

Steps to reproduce

run

let tries = 64;
const aliof = alignof<typeof tries>();
// or
const siof = sizeof<typeof tries>();

AssemblyScript version

v0.27.15

lortonx avatar Nov 05 '23 15:11 lortonx

I'm not sure if AS supports typeof yet.

CountBleck avatar Nov 05 '23 16:11 CountBleck

I'm not sure if AS supports typeof yet.

yes. typeof will return a string of object type

HerrCai0907 avatar Nov 06 '23 01:11 HerrCai0907

I'm not sure if AS supports typeof yet.

The problem is not even that, the problem is an error in the parser. Unfortunately, I didn’t check the typeof, but I saw that this have checks in tests https://github.com/AssemblyScript/assemblyscript/blob/main/tests/compiler/typeof.ts

lortonx avatar Nov 06 '23 03:11 lortonx

I have token a look about this issue. It is because parser handle alignof< typeof 1 > (); as Identifier LessThan Expression GreaterThan NotFinishedFunctionExpression. It is hard to distinguish generic and lessThan and greaterThan operator without semantic analysis. But unfortunately, we will not do any semantic analysis in parser stage.

HerrCai0907 avatar Nov 06 '23 03:11 HerrCai0907

typeof x when used as a type is parsed separately and differently from typeof x when used as an expression. For instance, typeof x(), typeof (x), typeof x[a ? b : c], and so on are parser errors in TS.

I suspect that typeof for types hasn't been implemented yet.

CountBleck avatar Nov 06 '23 03:11 CountBleck

The error you reported indicates the parser expected code like this, which is seen as (y < typeof x) > ((): i32 => 0), without the extra parentheses.

Edit: @HerrCai0907 beat me to it by 6 minutes and I didn't notice.

CountBleck avatar Nov 06 '23 03:11 CountBleck

Interesting thing is TS also have similar problem. true<false>(true); is valid but let a=true;a<false>(true); is invalid.

HerrCai0907 avatar Nov 06 '23 04:11 HerrCai0907

It is hard to distinguish generic and lessThan and greaterThan operator without semantic analysis.

Semantic analysis isn't necessary. TypeScript eagerly parses generics (which makes sense; practically no one would write a < typeof b, let alone a < typeof b > () => ... or a < typeof b > (c))

Interesting thing is TS also have similar problem.

You actually brought up what I typed above as I was typing it. 😆 Calling it a problem is a bit of an exaggeration, and true is probably treated specially as a keyword, thereby causing that case to be valid. It's not a major issue, since true < false > (true) is a generally useless expression.

CountBleck avatar Nov 06 '23 04:11 CountBleck