STOP named_string #172
Assignees
Labels
Comments
|
This has now been fixed and will be in the next release |
|
As for the colouring of the stop label, for consistency reasons it has to be classified under |
krvajal
pushed a commit
that referenced
this issue
Oct 20, 2021
* Updated CHANGELOG for v2.2.2 * Incremented package version to 2.2.2 * Minor aesthetic improvements to CHANGELOG * Adds OpenACC unit test * Updated tasks and launch files - The file structures have been updated to abide with the latest config syntax - Updated build commands in package.json - Deleted tasks.json.old * Fixes Remove unused packages #243 Regenerated npm and yarn .json files * Updated README badges * Updated workflows to run on Ubuntu latest * Fix overzealous OpenMP regex. The OpenMP regex did not allow for the OpenACC syntax scope to trigger. This has now been fixed and both should be displayed correctly. The only outstanding problem is that the unittest (.snap) does not trigger the right scopes, which means open acc/openmp are not tested thoroughly. I look into it * Updating changelog.md * New minor release * Housekeeping Changes all fortls instances with global variable and makes pip install user based with upgrade. * Added info to package.json * Fixes in-house documentaiton hover Fixes #250 * Now the deocumentation displays correctly Having preceding characters to ``` caused a problem in the hover result * Formatting .json doc files with prettier * Updated README.md * Adds VS marketplace automated release Fixes Setting up VSCE releases from GitHub releases #237 * Further improvements to the hover documentation * further fixes for internal documentation * Adds autoclosing for strings * Updates Fortran extensino and adds .pFUnit support Fixes #185. * Updates CHANGELOG.md * Fixes preprocessor syntax highlighting The line continuation operator is a bit too aggressive so instead of adding lookaheads for every case where we don't need to apply it we have excluded the preprocessor directives from the lint cont. The original .cson highlighting does the same, see: https://github.com/dparkins/language-fortran/blob/master/grammars/fortran%20-%20free%20form.cson for injections see: https://gist.github.com/Aerijo/b8c82d647db783187804e86fa0a604a1 Fixes Preprocessor statements in line continuations break syntax highlighting #248 Fixes Erroneous syntax highlighting for preprocessor conditionals in derived types #249 * Preprocessor assignment i.e. = is not a thing The regex was doing a negative look ahead and lookbehind for = but using = is illegal code and will not compile. e.g. #define VAR = 1 Also I went ahead and changed the patterns #define can match to be both string literals and numerical values #define VAR 1 is legal. * Preprocessor operator fixes - Adds support for all Fortran supported logical preprocessor operators - Adds support for arithmetic operators - Adds support for C++ preprocessor integers - Changes the syntax highlighting of preprocessor commands to use the `meta` scope which should result in consistent coloring between C++ and Fortran. A few things are not supported like macro function argument highlighting but I do not believe it is important for now * Fixes Erroneous syntax highlighting, when argument is called "function" or "procedure" #207 I have used non-fixed width ngative lookbehinds which should not be permitted in traditional Oniguruma regex. VSCode's implementation of the regex engine does not seem to care hence the solution * Adds unittest for #207 and updates CHANGELOG * Adds syntax highlighting support for fypp also extends the support for pfunit. Not sure if .pf and .fpp are considered to be fixed-form by default I don't think that is the case but fypp and pfunit use them so we default them to free-form * Add MIT license badge back to README * Adds names specific to individual scopes This is meant to make debugging syntax highlighting bugs easier to trace The unittests are also updated to contain the new scope names. * Fixes Erroneous syntax highlighting of if construct with tags #204 Labels were only captured at the start and end of a statement. Now we are also capturing them in between for if conditionals. The edits in the end in "named-control-constructs" are meant to correctly handle whitespaces which before they were placed as part of the group returned to the invalid.error.xxx A unittest has been added testing the conditionals with/out labels. * Updated CHANGELOG.md * Fixes STOP named_string #172 `stop` can now handle labels * Comments are correctly highlighted for type,... Fixes Erroneous syntax highlighting with type,abstract :: var #262 A unittest has been added and the CHANGELOG has been updated. * Add syntax test for fixed form fortran * Switches to @types/vscode & @vscode/test-electron Also updates the tests to use strictEqual Adds production, test and dev tscofig compilation Fixes Migrate from vscode module #263 * Updated changelog * Updated yarn.lock * Increments version to 2.4.0 Release a tag after token is uploaded * Updated tasks.json and launch.json External extensions are enabled since we need the C++ extension for VSCode to launch without throwing an error. The tasks.json has been updated to call directly scripts from package. * Updated names of scopes to contain fortran * Fixes normal labeled construct end statements * Adds error highlighting for else labeled * Upgraded package.json grammar update
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since some Fortran standard you can use a named string (or concatenations of them) after the STOP statement like in the image, but this gets highlighted as an error.
Actually its not too bad because its easy to see that it's an error message, but I guess it's a bug. Having this as a feature would be nice, but maybe not in the "syntax-error color", and with regular string also highlighted in the same way.
Thanks a lot!
The text was updated successfully, but these errors were encountered: