-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Documentation for Custom Assertion Handler #1873
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
db73dc0
to
5136fc3
Compare
The custom assertion handler mechanism allows applications to set their own assertion handling functions. This proposal | ||
is modeled on the assertion handler API that existed in TBB and is semantically similar to the standard library's | ||
OneTBB provides `internal assertion checking | ||
<https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/configuration/enabling_debugging_features>`_ |
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 suggest referring to specific version of the oneAPI spec so that this link does not become invalid some day.
<https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/configuration/enabling_debugging_features>`_ | |
<https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.4-rev-1/elements/onetbb/source/configuration/enabling_debugging_features>`_ |
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.
Changed in both places.
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.
@aleksei-fedotov do you suggest to update the link each time a new spec version is released (or maybe as its full support is implemented)?
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 suggest keeping links valid as long as possible.
By referring to a certain version of the document, we are sure that both descriptions are relevant. Once the spec is updated, we are again sure that the documentation remains valid. Once the implementation is updated, it is the trigger to update corresponding sections in the documentation, thus reconsidering the links and possibly updating them to refer to a new (but not the latest) version of the page they are referring to.
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.
FYI, here is the use of "latest" in the docs: https://github.com/search?q=repo%3Auxlfoundation%2FoneTBB+latest+path%3A%2F%5Edoc%5C%2F%2F&type=code
And here is the (absent) use of "v1": https://github.com/search?q=repo%3Auxlfoundation%2FoneTBB+v1+path%3A%2F%5Edoc%5C%2F%2F&type=code
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 believe it looks good!
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 good to me.
Description
Add a comprehensive description of proposed changes
Fixes # - issue number(s) if exists
Type of change
Choose one or multiple, leave empty if none of the other choices apply
Add a respective label(s) to PR if you have permissions
Tests
Documentation
Breaks backward compatibility
Notify the following users
List users with
@
to send notificationsOther information