Improve consistency of lexing of class-like names in C++ lexer #1495
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
There are are a number of issues mentioned in #394, but for ease of reference, I note that this will fix two of the bullet points in the OP. |
|
@integricho Sorry to lean on you again but if you're able to have a peek at this, that'd be great. I don't think I'll ever not feel out of my depth when it comes to C++ :P |
n0phx
reviewed
Apr 10, 2020
|
Looks good, thanks! but take everything I say with a grain of salt :) |
|
@integricho Thanks for your help! I've merged this into the main branch and it will be part of the next release of Rouge. That's scheduled for release on Tuesday 14 April 🎉 |
mattt
pushed a commit
to NSHipster/rouge
that referenced
this pull request
May 21, 2020
…ouge-ruby#1495) Rouge's C++ lexer currently tokenises identifiers that come after the class keyword with the `Name::Class` token and identifiers that come after the `struct` keyword with the generic `Name` token. This is despite the fact that the only difference between a struct and a class in C++ is the default access specifier. Similarly, when used in a template definition, a typename is equivalent to a class but Rouge treats the identifiers that follow the `typename` and `class` keywords differently. This commit addresses this problem. It treats class and struct as equivalent in all cases while treating typename as equivalent when used in a template definition.
pyrmont
added a commit
that referenced
this pull request
Jul 4, 2020
The change in #1495 to the way that the `template` keyword caused template parameter packs not to be highlighted correctly. This commit fixes that bug while also introducing a more robust set of rules for highlighting identifiers succeeding the `template` keyword.
mattt
pushed a commit
to NSHipster/rouge
that referenced
this pull request
May 19, 2021
The change in rouge-ruby#1495 to the way that the `template` keyword caused template parameter packs not to be highlighted correctly. This commit fixes that bug while also introducing a more robust set of rules for highlighting identifiers succeeding the `template` keyword.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rouge's C++ lexer currently tokenises identifiers that come after the
classkeyword with theName::Classtoken and identifiers that come after thestructkeyword with the genericNametoken. This is despite the fact that the only difference between a struct and a class in C++ is the default access specifier. Similarly, when used in a template definition, a typename is equivalent to a class but Rouge treats the identifiers that follow thetypenameandclasskeywords differently.This PR addresses this problem. It treats
classandstructas equivalent in all cases while treatingtypenameas equivalent when used in a template definition.It fixes #1484.