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.
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
builder: use cc enum in CcompilerOptions, fix cc detection, enable cc guessing without prod flag #21370
builder: use cc enum in CcompilerOptions, fix cc detection, enable cc guessing without prod flag #21370
Changes from 8 commits
7a96149
a8e62e3
9b58466
1047fd6
9e8b7cb
4279761
1a16b50
e771063
863af9b
bce3165
ed619f8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 is_prod check is there for a reason. Restore it.
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.
I do not like how you are doing refactorings (the replacement of the strings and several bool fields -> a single enum is good), mixed with functional changes in behavior (which is questionable) :-| .
Please do keep such PRs separate. One can be merged, and the other closed. Now, you have to do more work to separate them, and I to review it.
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.
But there is no performance regression with the update. Instead there is a benefit of several fixes.
Please read:
It fixes the compiler being detected. E.g. on macos in general. This was stated in the issue description:
screenshot macos
So before opening the PR I just enabled guessing outside prod on macos. After opening it, it revealed that there are similar scenarios on other platforms. I classified that detecting a compiler is of priority - even if there would be a performance regression:
screenshot freestanding
screenshot vsl/vtl test
screenshot freebsd
Another fix that was made, unrelated to enabling guessing without prod:
screenshot g++
So it is mainly a fix, not a refactor.
I know there is a lot of descriptions in the PR, I try to keep them simple and down to what is important to simplify reviewing. But doesn't seem like anyone was read before writing the review comments. The changes pointed out in the reviews were also pointed out in the descriptions / open discussions where joining on would allow to address them better. I see your point but on some code it's hard sometimes impossible to keep changes very simple or would take a lot of time and PRs so I try to find a middlegroud.
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.
As stated above it's more of a fix than a refactor. Using an enum had to be exclusive. And in the first stage a panic was added if the compiler is unknown. If the panic is kept was up for discussion. It helped to detect where a compiler is not known during the work on the fix.
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.
All of those are panics, that I do insist should not be there at all.
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 portability of V to new platforms and OSes, will be limited by having a panic for no good reason at all.
The failures that you claim to be fixed, are self inflicted, by the very panics that I do insist should not be there. The check for -prod is also related - without it, the restrictions to
cc
are practically non existent, and that facilitates bootstrapping on new platforms, where it can be anything.Again, V requires a C99 compiler, not a specific named one, and that should continue to be so. It should not panic when it can not decide what the compiler is, it should just not add compiler specific flags.
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.
Yes we don't need to dwell down so much on the panics. I made the experience often enough that it's good to turn something into an error that should be a notice or warning in the result, just to be able to better work with it during development.
I would update the panic like stated here: #21370 (comment). Would that make the PR a merge candidate?
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.
Even an error is not appropriate imho, since it should not prevent the compilation and bootstrapping on a new system.
At best, it can be a notice.
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.
Yes, looks like we agree. It would be just a print to stderr to make note of using an undetected compiler (as it's done with other notices in the
builder/cc.v
), things would continue as usual.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.
Updated. As - with the PRs changes - we didn't panicked with all our currently tested options, the notice should only become visible when there is an unknown compiler.
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.
Thought you were going to have an
other
type?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.
That's why the commit message
I forced pushed, but the message was the same.
It helps to work with the errors for now instead of silencing them.
Thought of adding an
unknown
field rather thanother
then as it still can be agcc
orclang
just not detected.other
implies it is something else. Also an error message but not a panic when it's an unknown compiler.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.
Looks like we can pass now without panicking when keeping the panic. Keeping it would make it immediately clear when there is an unknown compiler and potentially prevent regressions and unknown behaviour. Also increase the likelihood of making us aware through reports when we can add a not yet supported compiler. If keeping the panic is not an option I'd follow through with what was stated in the comment above.
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 likelyhood is imho that people experimenting with such compilers will just not report anything and skip V.
The only requirement that we do have, is that the C compiler should support C99. Not that it is named in a particular "supported" way. That is good, and it should stay that way.