assemblyscript
assemblyscript copied to clipboard
Parser error, i think
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.
Steps to reproduce
run
let tries = 64;
const aliof = alignof<typeof tries>();
// or
const siof = sizeof<typeof tries>();
AssemblyScript version
v0.27.15
I'm not sure if AS supports typeof yet.
I'm not sure if AS supports
typeofyet.
yes. typeof will return a string of object type
I'm not sure if AS supports
typeofyet.
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
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.
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.
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.
Interesting thing is TS also have similar problem.
true<false>(true); is valid but let a=true;a<false>(true); is invalid.
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.