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

[BUG] Parameter named after contextual keyword is lost #397

Closed
JohelEGP opened this issue Apr 30, 2023 · 4 comments
Closed

[BUG] Parameter named after contextual keyword is lost #397

JohelEGP opened this issue Apr 30, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@JohelEGP
Copy link
Contributor

Title: Parameter named after contextual keyword is lost.

Such a Cpp2 parameter is lowered to Cpp1 as no parameter at all.

Minimal reproducer (https://cpp2.godbolt.org/z/1exj84Wb4):

t: type = {
  f: (in) = { }
}
g: (final) = { }
// h: (out, x) = { } // Error!
main: () = { }

Commands:

cppfront -clean-cpp1 main.cpp2
clang++17 -std=c++2b -stdlib=libc++ -lc++abi -I . main.cpp

Expected result:
A diagnostic,
or the equivalent using y as an identifier.

Actual result and error:

#include "cpp2util.h"

class t;
  
class t {
  public: static auto f() -> void;

  public: t() = default;
  public: t(t const&) = delete;
  public: auto operator=(t const&) -> void = delete;
};
auto g() -> void;
// h: (out, x) = { } // Error!
auto main() -> int;

  auto t::f() -> void{}

auto g() -> void{}

auto main() -> int{}
@JohelEGP JohelEGP added the bug Something isn't working label Apr 30, 2023
@JohelEGP
Copy link
Contributor Author

JohelEGP commented Apr 30, 2023

See also #387 (comment).

I believe (in: T) should be a function type with an by-in parameter of type T.

Visualized

See https://highlight-cpp2.godbolt.org/z/K9nvoqKdh.
1685200243

That may be relevant in deciding the semantic meaning of (𝘵𝘩𝘪𝘴-𝘴𝘱𝘦𝘤𝘪𝘧𝘪𝘦𝘳) as a parameter-declaration-list.

@hsutter
Copy link
Owner

hsutter commented Aug 10, 2023

Thanks, this is a good example.

The linked PR #505 would allow this code:

t: type = {
  f: (in) -> _ = in;
}
g: (final) -> _ = final.first;
h: (out, x) -> _ = out(x);

I'm inclined to say that these should be interpreted as a missing parameter name, and should get a better diagnostic and be rejected at compile time.

I don't think I want to allow these. Are they ever necessary? They seem confusing (at least visually) and allowing them creates new things to teach and learn that would not be necessary if we disallowed parameters named the same as a parameter qualifier (parameter-direction or this-specifier).

@JohelEGP
Copy link
Contributor Author

That makes sense.
I wasn't sure before, but now I'm convinced.
I'll rebase #505 to diagnose as you mentioned.

@hsutter
Copy link
Owner

hsutter commented Aug 10, 2023

It's okay, I just made the change and am about to check it in. Thanks again!

zaucy pushed a commit to zaucy/cppfront that referenced this issue Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants