-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add repro for issue #4323 and cater for a conformity annotation #4324
Conversation
and use `function`
Cool. Have you got a follow on PR? This one makes the grammar a bit weird (pulling the equal sign into the annotation grammar), so I'd rather review the effect of both in case there's a cleaner refactoring. |
{ let t = Option.join t in | ||
let sort = Type.(match s.it with | ||
| Actor -> "actor" | Module -> "module" | Object -> "object" | ||
| _ -> assert false) in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This covers Memory
, but that cannot happen via obj_sort
, so this is dead.
leave "strange" productions like ``` Motoko module M : module {} {} ``` where `}` and `{` collide, but we can rectify that by coming up with a formatter rule to insert `=` in-between
@@ -150,7 +150,7 @@ x * y + x | |||
|
|||
A declaration list is not itself (immediately) an *expression*, so we cannot (immediately) declare another variable with its final value (`3`). | |||
|
|||
**Block expressions.** We can form a *block expression* from this list of declarations by enclosing it with matching *curly braces*. Blocks are only allowed as sub-expressions of control flow expressions like `if`, `loop`, `case`, etc. In all other places, we use `do { … }` to represent block expression, to distinguish blocks from object literals. For example, `do {}` is the empty block of type `()`, while `{}` is an empty record of record type `{}`. | |||
**Block expressions.** We can form a *block expression* from this list of declarations by enclosing it with matching *curly braces*. Blocks are only allowed as sub-expressions of control flow expressions like `if`, `loop`, `case`, etc. In all other places, we use `do { … }` to represent block expression, to distinguish blocks from object literals. For example, `do {}` is the empty block of type `()`, while `{}` is an empty record of record type `{}`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was an invisible character in do { … }
, I deleted it, maybe I shouldn't have!
@@ -292,7 +292,7 @@ | |||
<dec_nonvar> ::= | |||
'let' <pat> '=' <exp> | |||
'type' <id> ('<' <list(<typ_bind>, ',')> '>')? '=' <typ> | |||
<obj_sort> <id>? '='? <obj_body> | |||
<obj_sort> <id>? (':' <typ>)? '='? <obj_body> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the chapter of object
declarations (grep for "where <obj_body>
is of the form =? { <dec-field>;* }
"), <obj_body>
is said to contain the =?
, but it is not consistent all over this document. This needs to be fixed-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was a "hairline space" 0x200b. The =?
problem was resolved in d1007d1.
@@ -2434,7 +2445,7 @@ and infer_dec env dec : T.typ = | |||
display_typ_expand t' | |||
display_typ_expand t'' | |||
| Some typ, T.Actor -> | |||
local_error env dec.at "M0135" "actor class has non-async return type" | |||
local_error env dec.at "M0135"(*FIXME: repeated?*) "actor class has non-async return type" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to fix this, though it is a previous problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Claudio Russo <claudio@dfinity.org>
Co-authored-by: Claudio Russo <claudio@dfinity.org>
@Mergifyio refresh |
✅ Pull request refreshed |
Closes #4327. |
reproduce feature request #4323 and implement it
This won't restrict the resulting type (as pointed out by @rossberg), but merely verifies the interface.
public
and type annotations on bindings inside the block are there for shaping the former (just like inclass
definitions).TODO:
Changelog.md
FIXME
— chore: remove theFIXME
for duplicatedM0135
#4355