Introduce OMR_FINAL attribute for extensible classes - #7964
Merged
Conversation
Contributor
Author
|
@mstoodle @vijaysun-omr @hzongaro @jdmpapin @dsouzai @kevindean12 : FYI for any opinions |
jdmpapin
reviewed
Oct 1, 2025
jdmpapin
reviewed
Oct 1, 2025
hzongaro
reviewed
Oct 2, 2025
jdmpapin
reviewed
Oct 2, 2025
The `OMR_FINAL` attribute is used to decorate member functions of an extensible class to indicate the implementation will not be overridden by a subclass. Member functions designated `OMR_FINAL` need not be referenced with `self()`, which improves readability of the code. Signed-off-by: Daryl Maier <maier@ca.ibm.com>
jdmpapin
approved these changes
Oct 2, 2025
Contributor
|
@0xdaryl Looks good from my perspective. Thanks for the heads up! |
vijaysun-omr
approved these changes
Oct 3, 2025
Contributor
|
LGTM, thanks |
Contributor
|
Jenkins build all |
Contributor
|
The failure running I will hold off merging until @dsouzai and @mstoodle have had a chance to express an opinion. |
Contributor
|
looks ok to me |
Contributor
|
No concerns from my end. |
Contributor
Author
|
Jenkins build riscv For the record, RISC-V testing was successful for this PR. Launching it again in this PR to test the RV build pipeline for a different issue. |
Contributor
|
It did fail riscv testing |
Contributor
Author
|
@hzongaro : since we have broad consensus on this, could you merge please? Thanks. |
thallium
pushed a commit
to thallium/omr
that referenced
this pull request
Oct 7, 2025
Introduce OMR_FINAL attribute for extensible classes new jfr mem category Signed-off-by: Gengchen Tuo <gengchen.tuo@ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
This PR introduces an
OMR_FINALattribute that can be used in the compiler component to decorate member functions in C++ extensible classes to indicate they will not be overridden by a subclass. This attribute is not enforced by the compiler at build time and serves primarily as documentation. However, its intended semantics in the code can be verified using third-party linting tools, such as those built with Clang.The introduction of this attribute is motivated by the desire to improve code readability by eliminating the requirement for
self()calls when dispatching trivial member functions (such as getters and setters) in extensible classes.This PR includes a commit that demonstrates how and where
OMR_FINALcan be used in a number of extensible classes. This is not an exhaustive application ofOMR_FINAL, only a demonstrative set. Eliminating the unnecessaryself()calls will occur in future PRs in OMR and downstream projects.An alternative approach to achieve the same result is to introduce an attribute to decorate the member functions that could be extended by sub-classes in an extensible class hierarchy. This is more in line with the way C++ allows methods to be extended via virtual functions and dynamic polymorphism. However, taking such an approach would require scrutiny of every member function in an extensible class to determine which are acceptable extension points and which are not. This is a far larger undertaking than is necessary to achieve the end goal (more readable code). In addition, the number of
OMR_FINALfunctions is expected to be much less than the number of extension points allowed.