GH-131691: fix SEH for clang-cl on Windows #131730
Conversation
chris-eibl
requested review from
a team,
AA-Turner,
ezio-melotti and
hugovk
as code owners
| and want to be able to override some ClCompile parameters, | ||
| so this must not be included erlier. | ||
| --> | ||
| <Import Project="pyproject-clangcl.props" Condition="$(PlatformToolset) == 'ClangCL' and $(__PyprojectClangCl_Props_Imported) != 'true'" /> |
There was a problem hiding this comment.
I had to move this further down. Otherwise, pyproject-clangcl.props would not be able to override ExceptionHandling.
There was a problem hiding this comment.
If we end up needing to put it earlier, then it could override ClCompile.ExceptionHandling in a Target (with an ItemGroup, rather than an ItemDefinitionGroup). Or we can probably remove the ExceptionHandling metadata from the current ItemDefinitionGroup and let it use the default.
If you prefer it this way, then let me know. This is mergeable as is.
There was a problem hiding this comment.
There are many ways to skin that cat. Before I found out, why using ExceptionHandling did not work, I used /EHa in AdditionalOptions.
I moved that down, just in case we'd like to override more in pyproject-clangcl.props in the future.
Like you mentioned, when we need to move it back further up - we'll find ways.
So let's merge? Up to your liking ...
This reverts commit bd83c14.
|
https://github.com/python/cpython/actions/runs/14067162650/job/39392473423?pr=131730#step:4:855 is green again, so removing temporary modification in tail-call.yml |
…ws (pythonGH-131730) The /EHa option for Clang-CL behaves differently than the same option for MSVC, which is why we don't use it for both compilers.
…ws (pythonGH-131730) The /EHa option for Clang-CL behaves differently than the same option for MSVC, which is why we don't use it for both compilers.
2 participants
Uh oh!
There was an error while loading. Please reload this page.