How to specify platform-specific clangd arguments like `--malloc-trim`?

[emmenlau]

I have my clangd arguments in the vscode workspace settings MyProject.code-workspace. This helps so that all developers benefit from a good setup directly after cloning the project.

On Linux we urgently require the argument --malloc-trim to avoid frequent machine crashes due to out-of-memory. With this option, the RAM usage drops by 50-80%.

However, this option does not exist on Windows. Windows developers get a clangd startup error about the unsupported option.

Is there any way to set this option platform-specific? Or some workaround, to get this going?

[HighCommander4]

Is there any way to set this option platform-specific?

Looks like this is a missing feature in vscode: microsoft/vscode#5595

Or some workaround, to get this going?

Maybe with an extension like https://marketplace.visualstudio.com/items?itemName=runarsf.platform-settings.

[emmenlau]

Ok, I see, there is nothing that can be done of the side of this extension? Since clangd is more platform specific than many other extensions, I was hoping that there may be sufficient need to implement specific support for this. The above linked issues have been unaddressed since years, so I'm not keeping my hopes up for them...

[HighCommander4]

there is nothing that can be done of the side of this extension?

I suppose vscode-clangd could have a setting like "clangd.extraLinuxArguments", which are appended to "clangd.arguments" on Linux only.

@JVApen what do you think about that approach?

[JVApen]

I'm using the platform-settings extension as well. It does come with some disadvantages:

• it copies the setting from workspace to user settings
• it completely overrides the value of the setting
• there seems to be a delay when you make changes to the values

I think adding extraArguments is a possible way that solves this. Given we explicitly set other options on Windows as well (crash dump related) I would have Linux/Mac/Windows similar to how this is available for tasks.

I also use the platform extension for the launch script to choose between a CMD and SH file. (Path) So having a possibility to have that platform specific would be handy. Looking through the options, this might also be relevant for fallbackflags.

Given that these 2 options don't really have an extend (include paths different, defines might be different), I'd more be inclined to say we add: clangd.<platform>.<setting> for the 3 platforms and settings and when provided for the platform, it overrules clangd.<setting>
For the exact names of <platform>, it's best to check the names used in tasks.

This could than be a small extension to https://github.com/clangd/vscode-clangd/blob/master/src/config.ts method(s) get (and update?) where it either detects if we registered that variant. Or it provides a boolean to enable the behavior on querying.

What do you think?

[HighCommander4]

What do you think?

I appreciate the potential utility and forward-looking nature of making the mechanism more general (i.e. allowing platform-specific customization of all settings, not just clangd.arguments).

A couple of potential downsides I can think of are:

• As you say, needing to have "override" semantics vs. "extend" semantics because the latter don't naturally apply to all settings.
  • "override" semantics might be less convenient for clangd.arguments (probably not a big deal though)
  • We already have "override" semantics in Workspace Settings overriding User Settings, now we'd have a lattice: which of "clangd.windows.arguments in User Settings" vs. "clangd.arguments in Workspace Settings" should take precedence?
• As usual, implementation complexity

[JVApen]

Workspace wins over remote settings over user settings.
Checking all these levels in-between seems more complex. Also here you have override semantics. So I'd a platform specific setting at any level wins over the generic one.

I think we can keep the complexity contained in the getter for the settings + a bool (with default value) + the package file that has all settings described

[HighCommander4]

Workspace wins over remote settings over user settings. Checking all these levels in-between seems more complex. Also here you have override semantics. So I'd a platform specific setting at any level wins over the generic one.

I think we can keep the complexity contained in the getter for the settings + a bool (with default value) + the package file that has all settings described

Sounds reasonable.

I'm unlikely to have the bandwidth to work on this in the near future, but I'm happy to review a patch.

[emmenlau]

I just wanted to chime in: Would be awesome if this is worked on! For me it has a very high impact, as --malloc-trim is basically the only way how I can use clangd on the laptop.

[JVApen]

I can't promise spending time on this, though I also got involved due to an issue that was blocking. It's quite easy (on Linux) to get started. There is already a good starting point described about.