Add support for vscode by jonnysoe · Pull Request #92 · lexxmark/winflexbison

jonnysoe · 2023-03-11T18:04:51Z

No description provided.

GitMensch

Thank you for taking the time to document this. Please move the docs to a separate "vscode" folder, following the current docs structure.

Furthermore I do have concerns related to the proprietary extensions used, and I won't pull it myself as long as those are used. Lexxmark may see this different.

GitMensch · 2023-03-12T12:08:28Z

+
+    // List of extensions which should be recommended for users of this workspace.
+    "recommendations": [
+        "ms-vscode.cpptools-extension-pack",        // Comes with CMake for Debugging C++


I personally won't recommend those proprietary extensions (only daohong-emilio.yash is free to use), which hinders me to pull this. Please drop all but yash (I wasn't even aware of it, thanks for sharing!) and consider adding cmake specific extension.

I'll limit this to ms-vscode.cmake-tools, this alone is minimal and enough for normal use case

GitMensch · 2023-03-12T12:09:57Z

+            // https://code.visualstudio.com/docs/cpp/config-msvc
+            // https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
+            "name": "(windbg) Launch",
+            "type": "cppvsdbg",


similar, this one is sadly not free; you may want to use clangd for intellisense and native-debug for debugging when you want to add those to the repo

This is the launcher for debugger, it has nothing to do with clangd as it is the language server for code navigation, and I'll leave clangd out since its interfering with IntelliSense, may cause problems for others too, IntelliSense will be removed from the workspace recommended extensions.json.

The debugger may be problematic, I'm not entirely sure about the free licensing you're referring to or what native-debug is, however this is the only debugger for MSVC which is what we're using, its not entirely WinDbg per se, but the same free proprietary tools Windows SDK bundles - Debugging TOols for Windows, WinDbg, CDB, KD, NTSD...

On a side note, did you mean open source? Please clarify

@GitMensch ,
is your "free" referring to free-as-in-speech (libre)? WinDbg is part of Windows SDK which is free-as-in-beer (gratis), but its the only debugger for MSVC, its just configuration and we are not even redistributing this to users or developers

This is about the extension necessary - the cppvsdbg debug type is only part of a Microsoft extension that can only be used with Visual Studio Code, so "free beer if you sit only on a specific chair with no single adjustment, that comes pre-configured to tell the maker whenever you sit on it" (and the beer likely doing the same); and with the adjusted recommendations we don't have that available any more, I think. Am I wrong?

Note: If I remember correctly you can use LLDB to debug msvc generated modules, too - for this setup there are some free extensions (like "free to use for anything, anywhere, including adjusting the extension and re-distribute it"- "libre"), too.

Nope, its a known issue which is why its never published in the vscode documentation, it may be possible in the CLI/TUI but LLDB cannot be used to debug MSVC-generated symbols in vscode as it lacks LLDB-MI for non-Apple platforms at the moment, the closest LLDB for vscode is the CodeLLDB extension which is not compatible with MSVC-based symbols; not even MSVC-based Clang programs, MSVC-based Clang programs will still need to use WinDbg since its PDB symbols are MSVC-based...
Getting LLDB-MI to work on Windows will require quite some effort from the community, which is inactive at the moment...

Yes, the recommended beer will be gone from the recommended extensions, I think having this debug configuration is not as evil as telling devs "the free beer is required or recommended", for now the codebase is only compatible with this beer (MSVC), if you need to debug, this is the only available beer (which we did not bundle) at the moment 🙊

P.S. I can try to get the codebase compatible with WinLibs/UCRT after this, just not within this PR as it requires quite some changes

LLDB folks are GNU guys?
GNU guys don't like C++or STLs (just have a look what some of the GNU software is written in...)?

Note: for GDB you commonly want pretty-print handlers for C++ and STL types, maybe this is similar with LLDB?

fair warning: I'm a GNU guy and when I (seldom) do C++ or STL it is in other people's code

The debugger may be problematic, I'm not entirely sure about the free licensing you're referring to

the microsoft extension is not free, as you can see in its license

You may install and use any number of copies of the software only with Microsoft [...] Visual Studio Code

--> this explicit disallows use with any other built of vscode repo and the extension also checks for the Microsoft identifiers in product.json, so disables itself when it "believes" it is not run on the "single blessed binary product"... and they even have a wiki page explaining that: https://github.com/microsoft/vscode-cpptools/wiki/Microsoft-Native-Debugger-licensing-and-Microsoft-Visual-Studio-Code

or what native-debug is

It is one of the extensions that can work with lldb-mi, so if you have a binary lldb-mi, then you can use it.

however this is the only debugger for MSVC which is what we're using,

No, as noted you can use the lldb extension which distributes windows binaries, too (but not lldb-mi) to debug MSVC generated binaries as well as any debug extension that supports lldb-mi.

My point was exactly that I don't this repo to suggest people to use the non-free extension (that will only work on "MS' blessed binaries, so for example not any of my vscode installations)and let all others have a note in their problems pane that the debug type is unsupported.

Thank you so much for going above and beyond to clarify, now I understood what you meant, it is free if user/dev is on MS tool suites, not free for any other variants or forks of Code - OSS
TL;DR the rule for this free beer is MS binaries

TL;DR the rule for this free beer is MS binaries

yes, along with binaries where the code is explicit not released - and both have an explicit opt-out of telemetry (which you can set, but as the sources are closed you can only check what goes out by firewall [blocking some of that works, others broke the extension, but that's a too unrelated thing to this PR and I also have no recent data about that, so "ignore that part of my rant, please - just keep in mind 'nobody but MS can actually check what the software does'"]).

Replaced VS Debugger with codelldb

GitMensch · 2023-03-12T12:10:57Z

@@ -0,0 +1,10 @@
+{


It seems those settings would best be user-scope, not specific to this workspace.
Please share your reasoning if your disagree.

Workspace is the appropriate place for codebase consistency settings, unless that is something we don't want...

First is editor settings, most users have different settings which will make the codebase inconsistent, the proper way to have consistent code is clang-format, but that will format the whole code instead being just limited to the addtional lines introduced by developers; and will probably make it more difficult to sync with upstream.
Trailing whitespace is undesirable, for consistency and nothing much to explain further

Ruler indicator is just a mindful/useful indicator, I see GNU have an unwritten rule of 80 character line limit, but some codes go up to 120 chars in flex/bison, I'll say this is optional, I can remove this if you don't like to see these lines

The git operations are minimal and good to have for new developers, it helps to ensure git pull in vscode don't branch and merge, prune is optional as it helps to cleanup deleted branches in origin just that the code base is not super active at the moment

CMake preferred generator won't mess up the system as it only uses Ninja if its installed, although the codebase is small, it approximately halves the compilation time for debugging

Workspace is the appropriate place for codebase consistency settings, unless that is something we don't want...

Usually you don't want this, since users will mess with that around and accidentally push private & personal settings / metadata.

the proper way to have consistent code is clang-format, but that will format the whole code instead being just limited to the addtional lines introduced by developers

It doesn't necessarily format the whole base, you can just configure it to only format modified lines. And it's totally in the scope of the contributing developer.

@Febbe ,

accidentally push private & personal settings / metadata

Personal settings stay within their user directory settings.json by default when changes are made from the GUI, so if the contributor manually does questionable changes for the code base, then catching questionable changes or they're justifiable is what reviewers are here for

It doesn't necessarily format the whole base

I don't recall git clang-format limits changes to the modified lines back in llvm 15

I’ve been using git clang-format for much longer, and its sole purpose is to only operate on the modified lines.
There used to be a run-clang-format.py script that formatted everything.
Additionally, you can configure clangd in VS Code as the formatter for C/C++, and restrict it to formatting only modified lines. That has the same effect as git-clang-format as clangd linked clang-format into its server.

Yes, I know of the extension being able to format by lines, I just couldn't get it to work when I use command line...

GitMensch · 2023-03-12T12:14:22Z


 ## HowTo
 You may use win_flex and win_bison directly on the command line or [use them via CustomBuildRules in VisualStudio](custom_build_rules/README.md).
+### Visual Studio Code


Following the current README's and repo structure this file and images should be moved out to a separate vscode folder, linked here as done for the CustomBuildRules.
Please also consider using "vscode" instead, because there are more binary packages then the one distributed by Microsoft.

I'll try to mirror that directory...

I've recaptured the screenshots and moved everything to the new vscode directory

GitMensch · 2023-03-12T12:15:23Z


 ## License
-Flex uses a [BSD license](flex/src/COPYING), GNU Bison is [licensed under the GNU General Public License (GPLv3+)](bison/src/COPYING).  
+Flex uses a [BSD license](flex/src/COPYING), GNU Bison is [licensed under the GNU General Public License (GPLv3+)](bison/src/COPYING).


.md files should not be whitespace-trimmed at the end. Those two trailing spaces lead to a line break, otherwise it would be a block text, please revert this part.

Its trimmed by trimTrailingWhitespace, I'll reinsert them and add md files as exception

GitMensch · 2023-03-12T12:19:13Z

@@ -25,10 +25,37 @@ The release page includes the full Changelog but you may also see the [changelog

 ## Build requirements
 * Visual Studio 2017 or newer


We should change that to say "... build tools" (which is a separate package, for example pre-installed in several CI environments) or specify builds; this is not related to this PR but could be done together.

The pre-installed build tools I see in AppVeyor are all VS...
What does "... build tools" mean? Does that mean "Visual Studio 2017 or newer build tools"?
Or you you wanted something different like the following?

C++ build tools (MS BuildTools, Visual Studio 2017 or newer)

I mean - you don't need the full Visual Studio installed, the Build Tools for C++ (which are included in Visual Studio) are enough.

Alright, its the latter, I'll update it 👌

I left this unchanged after rebase

GitMensch · 2023-03-12T12:21:24Z

+            ],
+```
+
+6. Setup the IDE for inspection [debugging](https://code.visualstudio.com/docs/editor/debugging), eg. breakpoints, logpoints.


it likely is more reasonable to not use "IDE" here; not sure if "editor" as used in the vscode docs is the best option, but it would be better.

Wording/spacing/punctuation: "Set up" and "e.g. breakpoints or logpoints."

How about calling it "codebase"? It'll be vague but indicative

I'm fine with that.

Updated, see the new vscode/README.md

Febbe · 2025-09-22T13:59:21Z

Honestly, the whole .vscode folder belongs into the .gitignore. It's completely up to the user, how he wants to configure his clone.

GitMensch · 2026-03-03T16:26:40Z

@jonnysoe your documentation seems good; can you please rebase and do the agreed changes and move the documentation parts into the doc folder (the rest like extensions to be used in this repo will be ignored already)?

jonnysoe · 2026-03-05T05:22:51Z

@GitMensch , my apologies for leaving this hanging, I totally lost track of this ever since I left my last job...
I'll check that branch out to rebase it, gimme some time to follow through the conversations and new commits

jonnysoe · 2026-03-19T06:29:49Z

@GitMensch ,
I've read through some of the comments by you guys, ignoring .vscode is essentially defeating the purpose of this PR, it was supposed to introduce convenience to ease contributors for an easy start, the extensions.json doesn't force anything upon the end user either - it simply floats the recommended extensions for this code base to the top in the extensions tab, I understand if contributors accidentally merged unnecessary changes to the launch.json and I have no good way to prevent it - either add a generator script without committing the launch.json file or a git hook to prevent changes to it (thats how vscodium code base prevents contributors from adding anything to extensionsGallery.
I'm leaning towards a generator (such as copy during first build); the git hook method is less reliable to enforce because it requires additional git commands to be functional - which we can also add a script during build but its easy to bypass when the contributor don't build at all. Let me know whats your preference.

GitMensch · 2026-03-19T07:25:48Z

@jonnysoe Sorry, I didn't understand your question.

Please do the doc adjustments - I think the point was to move some things around and to resolve the conflicts - then restate your question.

... and possibly make it more explicit what this PR is about:

adjusting winflexbison itself from a checkout / source snapshot in vscode
documenting how to use that in vscode with a project that uses bison/flex

... or both? If that is the case then the second part should be split into a separate PR which we likely can merge easily and then also have a smaller scope here.

... seems I'm confused.

jonnysoe · 2026-03-19T08:18:29Z

the rest like extensions to be used in this repo will be ignored already

I understand the doc changes requested - move the images around, I was referring to this statement that doesn't make sense to me, the point is to add support for vscode (basically the extensions.json and launch.json introduced), the docs are basically guide to end users on how to use vscode to debug bison/flex.

Which is this

documenting how to use that in vscode with a project that uses bison/flex

I don't understand this following statement

adjusting winflexbison itself from a checkout / source snapshot in vscode

- Restore README.md - Changed extensions.json recommendations to fully open source - Changed launch.json to fully open source - Moved vscode documentation to its subdirectory

jonnysoe · 2026-03-21T10:47:31Z

@GitMensch ,
Please continue with the review. Thanks!

GitMensch

Thanks for the iteration and the explanations up front.

I think adding .vscode itself does make sense and the documentation is also good - mostly wondering about the recommended extensions now...

GitMensch · 2026-03-21T11:08:31Z

+    "recommendations": [
+        "ms-vscode.cmake-tools",                    // CMake for Debugging C/C++
+        "vs-code-extensions.vscode-clangd",         // Optional intellisense-like features with LLVM/clangd
+        "daohong-emilio.yash",                      // For flex/bison source files


This one is not available in open-vsx; I've searched and found a full-fledged new extension https://github.com/theodevelop/bison-flex-lang - should we recommend that?

This is fresh out of the oven for a week, just tested it feels a bit rough, very active development, looks good, so the name is theodevelop.bison-flex-lang on both repository, I'll update it
https://marketplace.visualstudio.com/items?itemName=theodevelop.bison-flex-lang
https://open-vsx.org/extension/theodevelop/bison-flex-lang

GitMensch · 2026-03-21T11:09:27Z

+    // List of extensions which should be recommended for users of this workspace.
+    "recommendations": [
+        "ms-vscode.cmake-tools",                    // CMake for Debugging C/C++
+        "vs-code-extensions.vscode-clangd",         // Optional intellisense-like features with LLVM/clangd


Why not the original llvm-vs-code-extensions.vscode-clangd?

Not sure how did I screw up the copy, I'll update it

GitMensch · 2026-03-21T11:13:18Z

Why do we want to ignore a folder we directly add in the same commit?

As a deterrant, changes to this directory will have warnings, and developers will need to force add new files

GitMensch · 2026-03-21T11:14:20Z

+You may:
+- use `win_flex` and `win_bison` directly on the command line
+- [use them via CustomBuildRules in VisualStudio](custom_build_rules/README.md).
+- use them via [CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) in [Visual Studio Code](vscode/README.md).


It seems to me that those would also be useful with the bison/flex extension noted above.

I'm not getting this statement, mind elaborating more?

@GitMensch
Just rereading this, I believe you mean naming the flex/bison extension here, however the extension does not contribute to this HowTo (build/debug), this extension is purely convenience for the developer (goto definition, syntax highlighting, etc. basically things that makes code navigation a pleasant experience)
I don't think we should name it as required (hence its a recommended extension that appears in the extensions list), basically optional like telling ppl "you should use git for this code base", something that we don't need to spell out, it will work regardless.
Lemme know if you still wanna add it here, I can do that, its just a simple "and" statement.

GitMensch · 2026-03-21T11:17:34Z

+You may:
+- use `win_flex` and `win_bison` directly on the command line
+- [use them via CustomBuildRules in VisualStudio](custom_build_rules/README.md).
+- use them via [CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) in [Visual Studio Code](vscode/README.md).


you may actually use them in vscode compatible environments (like an open build as VSCodium [used also as vscode in arch] or even Eclipse Thea) - I'd personally prefer replacing the product name of the MS binaries to just "vscode"...

I agree, there is some form of genericization, how does "vscode-like editor" sound?

GitMensch · 2026-03-21T11:21:11Z

@@ -0,0 +1,48 @@
+
+Alternatively, VS Code is available for debugging, here is a simple guide (based on the [MS documentation](https://code.visualstudio.com/docs/cpp/cmake-linux)):


A file starting with "Alternatively" seems bad.
If this file is only about how to debug winflexbison (which is fine and seems to be the case), we can just drop most of the first sentence and instead use a header like # Debugging WinFlexBison in vscode.

Thanks, this is part of the vestige from original cut/paste, I've tried to update most of the things here, missed this 1

GitMensch · 2026-03-21T11:23:29Z

+You may:
+- use `win_flex` and `win_bison` directly on the command line
+- [use them via CustomBuildRules in VisualStudio](custom_build_rules/README.md).
+- use them via [CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) in [Visual Studio Code](vscode/README.md).


The referenced file is not about how to use it in vscode, so we may drop the link altogether (and/or add another leading to # How To Use WinFlexBison and # How To Compile/Debug WinFlexBison where we reference the build scripts and the new vscode readme.

This falls under How to Debug, and implicitly Compile, how do you want to split this actually? Under the 2 headers you mentioned?

GitMensch requested changes Mar 12, 2023

View reviewed changes

Croydon mentioned this pull request Nov 26, 2025

Cleanup CMake even more #99

Open

jonnysoe added 2 commits March 21, 2026 16:13

Add support for vscode

3971b96

Apply PR changes

b14a01b

- Restore README.md - Changed extensions.json recommendations to fully open source - Changed launch.json to fully open source - Moved vscode documentation to its subdirectory

jonnysoe force-pushed the vscode branch from b79c50f to b14a01b Compare March 21, 2026 10:37

jonnysoe added 2 commits March 21, 2026 18:38

Disable Incremental Build in MSVC

6eb0f92

Drop VS Debugger in lanch.json

a15d121

GitMensch requested changes Mar 21, 2026

View reviewed changes

jonnysoe added 2 commits March 21, 2026 23:05

Update PR changes

9a92950

Reaarange README HowTo and Remove launch.json artifacts

947585c

		@@ -25,10 +25,37 @@ The release page includes the full Changelog but you may also see the [changelog

		## Build requirements
		* Visual Studio 2017 or newer

		@@ -0,0 +1,48 @@

		Alternatively, VS Code is available for debugging, here is a simple guide (based on the [MS documentation](https://code.visualstudio.com/docs/cpp/cmake-linux)):

Conversation

jonnysoe commented Mar 11, 2023

Uh oh!

GitMensch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitMensch Mar 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonnysoe Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Febbe Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Febbe commented Sep 22, 2025

Uh oh!

GitMensch commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitMensch Mar 15, 2023 •

edited

Loading

jonnysoe Mar 19, 2026 •

edited

Loading

Febbe Mar 19, 2026 •

edited

Loading

GitMensch commented Mar 3, 2026 •

edited

Loading