Skip to content
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

Operator new not properly parsed in &convert #1598

Closed
bbannier opened this issue Nov 22, 2023 · 0 comments · Fixed by #1756
Closed

Operator new not properly parsed in &convert #1598

bbannier opened this issue Nov 22, 2023 · 0 comments · Fixed by #1756
Labels

Comments

@bbannier
Copy link
Contributor

bbannier commented Nov 22, 2023

I would like to turn a data behind a unit field into a reference, e.g., to avoid copying when passing that field on. This works if I introduced a helper function.

module foo;

type X = unit {
    xs: bytes &eod &convert=as_ref($$);
};

function as_ref(xs: bytes): bytes& { return new xs; }

I however cannot seem to avoid the function, e.g.,

type X = unit {
    xs: bytes &eod &convert=new $$;
};
$ spicyc -j foo.spicy
[error] foo.spicy:4:33: syntax error, unexpected DOLLARDOLLAR
[error] spicyc: parse error

The only way I could make this syntax was to use a literal there which is not what I intend.

Looking at the parser, it looks like $$ might not be a scoped expression here,

| NEW ctor { $$ = hilti::expression::UnresolvedOperator(hilti::operator_::Kind::New, {hilti::expression::Ctor(std::move($2), __loc__), hilti::expression::Ctor(hilti::ctor::Tuple({}, __loc__))}, __loc__); }
| NEW scoped_id { $$ = hilti::expression::UnresolvedOperator(hilti::operator_::Kind::New, {hilti::expression::UnresolvedID(std::move($2), __loc__), hilti::expression::Ctor(hilti::ctor::Tuple({}, __loc__))}, __loc__); }
| NEW scoped_id '(' opt_exprs ')' { $$ = hilti::expression::UnresolvedOperator(hilti::operator_::Kind::New, {hilti::expression::UnresolvedID(std::move($2), __loc__), hilti::expression::Ctor(hilti::ctor::Tuple(std::move($4), __loc__))}, __loc__); }

rsmmr added a commit that referenced this issue Jun 7, 2024
So far we allowed some more generic expressions as well, but it's hard
for the parser to support arbitrary expressions here due to parsing
ambiguities, leaving things inconsistent. So we now limit it to what
was pretty much the intent originally anyways.

Note that the error message for #1598 stays the same: it's not great,
but seems good enough. However, we now actually disallow the
workaround shown in the ticket as well for consistency. The
work-around is shown in the changes to `hilti.codegen.type-info`.

Closes #1598.
@rsmmr rsmmr closed this as completed in 892fcaa Jun 13, 2024
rsmmr added a commit that referenced this issue Jun 13, 2024
* origin/topic/robin/gh-1598-new-expr:
  Enforce that the argument `new` is either a type or a ctor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant