-
Notifications
You must be signed in to change notification settings - Fork 22
refactor: cl arguments always map to regular arguments #1004
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
Conversation
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
@alandefreitas please advice on how to test this (so that we are informed when the tools stops working on Windows) |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
3 similar comments
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
6d43aed
to
92ae4ff
Compare
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
92ae4ff
to
57011a5
Compare
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
This will be squashed I hope? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR removes MSVC emulation mode from the MrDocs compilation database handling, simplifying command line processing by always using Clang's native format instead of supporting both Clang and MSVC/clang-cl command line styles.
- Removes driver mode detection and conditional command line formatting
- Adds explicit translation of clang-cl
/std:
flags to Clang-std=
format - Updates option filtering to exclude more MSVC-specific flags
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
File | Description |
---|---|
src/lib/MrDocsCompilationDatabase.cpp | Core changes removing MSVC emulation and adding clang-cl flag translation |
src/test/lib/MrDocsCompilationDatabase.cpp | New test file validating clang-cl flag translation functionality |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
An automated preview of the documentation is available at https://1004.mrdocs.prtest2.cppalliance.org/index.html |
This is great. These ternary operators with
This title is misleading to someone who doesn't understand the problem being fixed here because it sounds like MrDocs won't recognise compilation commands in the MSVC format. What's happening is just that all commands will be converted to the same format so that we can ensure the same behaviour and so that options included by MrDocs are less prone to errors. But that's internal and transparent to the user. Also, this it's is more of a "refactor" than a "feat" because nothing is changing in terms of MrDocs expected behavior. It could also be a "fix" in the sense that (I think) it's fixing an issue with nostdinc in passing.
What I would do is upsert a test suite for MrDocsCompilationDatabase (I don't know if it already exists) and then compare the input and output. Things should remain the same when it's not MSVC mode, and things should change when it's in MSVC mode. I wouldn't touch the golden tests at all. |
opt.starts_with("/std:") || opt.starts_with("-std:"); // clang-cl options | ||
}; | ||
if (std::ranges::find_if(cmdline, is_std_option) == cmdline.end()) | ||
if (std::ranges::none_of(cmdline, is_std_option)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:)
cmdline.begin() + idx0, | ||
cmdline.begin() + idx); | ||
|
||
// Translate clang-cl /std: into clang -std= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So arg->render()
works for all kinds of arguments except -std
(not that bad, but it would be good to include a small comment)? Or does that mean arg->render()
requires custom logic for lots of kinds of arguments, but the only one for which we got custom logic is -std
(much worse)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The later, not all arguments can be automatically translated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh.... OK.
requires custom logic for lots of kinds of arguments
So what are we going to do about this? Do we know the kinds of arguments that can't be translated? Do we know what happens when there's one of them? Do we know how to handle them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whenever an argument can't be translated clang will emit an error. The argument then has to either be added to the ignore list defined inside isValidMrDocsOption
, or custom handling logic has to be added here.
continue; | ||
} | ||
|
||
// Append the translated arguments to the new command line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really nice. Clang just translates the whole thing. :)
MRDOCS_ASSERT(arg->getNumValues() == 1); | ||
|
||
std::string_view v = arg->getValue(); | ||
if (v == "c++latest" || v == "c++23preview") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is cumbersome. Since we have access to the whole Clang library, I'm sure there should be some way to know what the highest std is. Even if it's some enum of standards somewhere, we can evaluate an inline constexpr requires to check if STD_NUMBER exists in that enum.
A few ways to get the highest stardard could be:
#include "clang/Frontend/LangStandards.def"
or
clang::getLangStandardForName("c++23")
or
bool ok = clang::CompilerInvocation::CreateFromArgs(
CI,
{"-std=c++23"},
*Diags
);
there must be any other ways.
These functions only give you if one specific standard is there, but you can just iterate 23 + X * 3 until you find the highest valid number, potentially at compile time.
} | ||
}; | ||
|
||
TEST_SUITE( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your test suite is great. You had nothing to worry about.
return compilations.getCompileCommands(cc.Filename).front().CommandLine; | ||
} | ||
|
||
static bool has(std::vector<std::string> const& commandLine, std::string_view flag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have a contains
function in Algorithm.hpp
IIRC.
Oh... There's also some logic in the GenerateAction that infers the implicit include paths depending on the compiler. We have to check if this is still working correctly after we changed the first arg to "clang". |
I believe the current PR title is not appropriate. This is not a simple refactor, this is a massive functionality change on windows: we are explicitly dropping clang-cl behavior, by only ever invoking normal clang behavior. |
Yes. From your last comment it was clear it's not worth pursuing this path at all:
We can't have code that doesn't work with a subset of flags, especially when we don't know what the subset is, and we know the consequences are catastrophic. Users shouldn't have to open an issue because of random flags that failed. |
as discussed in #997