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

[SR-1554] //*/ does not close multi-line comment #44163

Open
jckarter opened this issue May 18, 2016 · 4 comments
Open

[SR-1554] //*/ does not close multi-line comment #44163

jckarter opened this issue May 18, 2016 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself good first issue Good for newcomers parser Area → compiler: The legacy C++ parser

Comments

@jckarter
Copy link
Contributor

Previous ID SR-1554
Radar rdar://problem/26327545
Original Reporter @jckarter
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Parser, StarterBug
Assignee None
Priority Medium

md5: 2416cb9a05334e4c8d080874b91f289e

Issue Description:

//*/ should close a /* comment, but does not:

/*
//*/
print("wat")
@swift-ci
Copy link
Contributor

Comment by Geoffrey Wiseman (JIRA)

I took a quick look at `Lexer.cpp`. I think I can see the problem.

Assuming you allow nested slash-star comments, which the lexer seems to allow, I am not sure how you're supposed to decide whether or not "//*/" is meant to open or close a comment. In the absence of any other information, I think it should probably do what it's already doing: assuming that the first valid interpretation – that of opening a comment – is the right one.

Did you have another heuristic in mind for how it should decide?

@jckarter
Copy link
Contributor Author

geoffrey.wiseman (JIRA User) Good point, it's nonobvious what the right interpretation is here. Possibly, when lexing a nested /*, we could look ahead to see if there's a / immediately after the * and favor the */ interpretation.

@swift-ci
Copy link
Contributor

Comment by Geoffrey Wiseman (JIRA)

In which case the lexer would prefer /* at the start and */ thereafter.

These would be legit:

/*/ comment /*/
/*/ comment /*/ code /*/ comment /*/

Granted, almost all of these scenarios are edge cases, and will come up infrequently enough that it's probably not THAT big a deal. Your suggestion doesn't seem complicated, and I can't think of a really ugly counter-example that seems to suggest the it's a problem. I'll give this a spin.

@belkadan
Copy link
Contributor

Resetting assignee on all Starter Bugs not modified since 2018.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself good first issue Good for newcomers parser Area → compiler: The legacy C++ parser
Projects
None yet
Development

No branches or pull requests

3 participants