Skip to content
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

Explicitly export exception types. #2999

Merged
merged 9 commits into from
May 27, 2021

Conversation

oraluben
Copy link
Contributor

@oraluben oraluben commented May 11, 2021

Description

closes #2847 by setting visibility of exceptions to default. cc @XZiar
closes #3016

Suggested changelog entry:

``pybind11::builtin_exception`` is now explicitly exported, which means the types included/defined in different modules are identical, and exceptions raised in different modules can be caught correctly. The documentation was updated to explain that custom exceptions that are used across module boundaries need to be explicitly exported as well.

@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from 27e301e to 14368b7 Compare May 11, 2021 10:01
@rwgk
Copy link
Collaborator

rwgk commented May 21, 2021

The CI looks good.
My only concern is that we don't have a new test that failed before but works with this PR, so that we don't accidentally undo your fix in the future. How much trouble would it be to add?

Co-authored-by: XZiar <czktc2007@gmail.com>
@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from 14368b7 to 42b01fb Compare May 22, 2021 00:43
@oraluben
Copy link
Contributor Author

Hi @rwgk , the idea sounds good. Currently, I'm only aware of the test_<test>.{py,cpp} mechanism, but this test requires a custom build/include logic, what's the proper way to do this?

@rwgk
Copy link
Collaborator

rwgk commented May 22, 2021

Hi @rwgk , the idea sounds good. Currently, I'm only aware of the test_<test>.{py,cpp} mechanism, but this test requires a custom build/include logic, what's the proper way to do this?

I'm not very familiar with the exception handling code in pybind11 myself, but at first sight there is hope it could be straightforward adding to existing tests:

Do those look like a useful starting point?
What makes your situation a little more tricky is that you need to test interactions between two modules IIUC, but hopefully you can just add to those files above without having to go into the cmake files.

JIC you haven't seen this already, this includes instructions for running the tests: https://github.com/pybind/pybind11/blob/master/.github/CONTRIBUTING.md

@oraluben oraluben mentioned this pull request May 23, 2021
@oraluben
Copy link
Contributor Author

Hi @rwgk, I've added a test and updated some docs, does that look good to you? (I'll refine some word/name, e.g. tmp_e.)

@rwgk
Copy link
Collaborator

rwgk commented May 24, 2021

Hi @oraluben, the macos PyPy tests are failing. Did you see that already?
Note that we already skip several tests in the PyPy tests, in case there is no obvious or reasonable fix. But making it work is best.

@oraluben
Copy link
Contributor Author

I take a look at it but can't understand at all. I haven't used Pypy, but I doubt that Pypy has special library handling/importing behaviour, because after setting the visibility of exceptions to default, the hashcodes of thrown/caught exceptions are still different, which cause the catch statement to malfunction.

I'll just skip the test when pypy+libc++ for now and see if I can find more later.

@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from 4fda9b1 to a07fc60 Compare May 25, 2021 11:19
@rwgk
Copy link
Collaborator

rwgk commented May 25, 2021

Almost! :-)
Just Format failing now.
I always blindly run pre-commit run --all-files before git commit (see .github/CONTRIBUTING.md).

@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from a07fc60 to 2b3315d Compare May 26, 2021 01:14
@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from 2b3315d to 97773db Compare May 26, 2021 02:12
@oraluben
Copy link
Contributor Author

oraluben commented May 26, 2021

format fixed and passed pre-commit run --all-files now, thanks!

@oraluben
Copy link
Contributor Author

Found related #1272, trying to remove unused workaround code.

@oraluben
Copy link
Contributor Author

The latest commit removes some old workaround for this issue, which passed tests locally. If there's any failure in the CI (most likely in PyPy) I'll revert it.

@rwgk
Copy link
Collaborator

rwgk commented May 26, 2021

The latest commit removes some old workaround for this issue, which passed tests locally. If there's any failure in the CI (most likely in PyPy) I'll revert it.

Yep, PyPy failing again.

BTW: I still need to find time to verify that the new test fails without the core change, and run this PR through our Google-internal testing (no issues expected, but standard practice). Hopefully later today.

@oraluben oraluben force-pushed the fix-libcxx-exception-visibility branch from a913af8 to 1defec9 Compare May 26, 2021 15:08
@oraluben
Copy link
Contributor Author

Yep, PyPy failing again.

reverted & doc updated.

BTW: I still need to find time to verify that the new test fails without the core change, and run this PR through our Google-internal testing (no issues expected, but standard practice). Hopefully later today.

test-only version can be found at #3016, failed as expected.

@rwgk
Copy link
Collaborator

rwgk commented May 26, 2021

test-only version can be found at #3016, failed as expected.

Awesome, thanks! Verified by triggering the CI.

Copy link
Collaborator

@rwgk rwgk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, just some minor suggestions.

docs/advanced/exceptions.rst Outdated Show resolved Hide resolved
tests/test_exceptions.py Outdated Show resolved Hide resolved
tests/test_exceptions.py Outdated Show resolved Hide resolved
@rwgk
Copy link
Collaborator

rwgk commented May 27, 2021

The Google-internal global testing came back successful, too. We're ready to merge this PR, but could you please review the "Suggested changelog entry" I added to the PR description? Please modify as needed. I'll merge this PR after you confirm the Description and Suggested change log entry are final.

@oraluben oraluben changed the title Set visibility of exceptions to default. Explicitly export exception types. May 27, 2021
@oraluben
Copy link
Contributor Author

Thanks for your help! "setting visibility" is not concrete on the second thought, since the statement is Linux-only but this PR actually affects MSVC (see failed Windows CIs in #3016). I've updated the title and some parts of the Suggested changelog entry, the rest looks perfect! The messages are final if they look good to you.

@rwgk rwgk merged commit 3ac690b into pybind:master May 27, 2021
@github-actions github-actions bot added the needs changelog Possibly needs a changelog entry label May 27, 2021
@oraluben oraluben deleted the fix-libcxx-exception-visibility branch June 7, 2021 00:10
@henryiii henryiii removed the needs changelog Possibly needs a changelog entry label Jul 13, 2021
rwgk pushed a commit to rwgk/pybind11 that referenced this pull request Oct 25, 2022
rwgk pushed a commit to rwgk/pybind11 that referenced this pull request Oct 31, 2022
Background: pybind#2999, pybind#4105, pybind#4283, pybind#4284

In a nutshell:

* Only macOS actually needs `PYBIND11_EXPORT_EXCEPTION` (pybind#4284).

* Evidently (pybind#4283), under macOS `PYBIND11_EXPORT_EXCEPTION` does not run the risk of introducing ODR violations,

* but evidently (pybind#4283) under Linux it does, in the presumably rare/unusual situation that `RTLD_GLOBAL` is used.

* Windows does no have the equivalent of `RTLD_GLOBAL`, therefore `PYBIND11_EXPORT_EXCEPTION` has no practical benefit, on the contrary, noisy warning suppression pragmas are needed, therefore it is best left empty.
henryiii pushed a commit that referenced this pull request Oct 31, 2022
…#4298)

Background: #2999, #4105, #4283, #4284

In a nutshell:

* Only macOS actually needs `PYBIND11_EXPORT_EXCEPTION` (#4284).

* Evidently (#4283), under macOS `PYBIND11_EXPORT_EXCEPTION` does not run the risk of introducing ODR violations,

* but evidently (#4283) under Linux it does, in the presumably rare/unusual situation that `RTLD_GLOBAL` is used.

* Windows does no have the equivalent of `RTLD_GLOBAL`, therefore `PYBIND11_EXPORT_EXCEPTION` has no practical benefit, on the contrary, noisy warning suppression pragmas are needed, therefore it is best left empty.
rwgk pushed a commit that referenced this pull request Nov 18, 2022
…#4298)

Background: #2999, #4105, #4283, #4284

In a nutshell:

* Only macOS actually needs `PYBIND11_EXPORT_EXCEPTION` (#4284).

* Evidently (#4283), under macOS `PYBIND11_EXPORT_EXCEPTION` does not run the risk of introducing ODR violations,

* but evidently (#4283) under Linux it does, in the presumably rare/unusual situation that `RTLD_GLOBAL` is used.

* Windows does no have the equivalent of `RTLD_GLOBAL`, therefore `PYBIND11_EXPORT_EXCEPTION` has no practical benefit, on the contrary, noisy warning suppression pragmas are needed, therefore it is best left empty.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] register_exception_translator have different behaviour when building with different STL.
3 participants