-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Migrate fc::static_variant to std::variant #9235
Conversation
Can we get a better description on this PR please. The standard template should be used. Specifically the check box sections are needed. |
eb36fee
to
fc545e5
Compare
This PR should be ready for review now. I am currently unsure which boxes need to be check in the description. |
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.
std::get throws different exception from fc::static_variants, please check the exception handling has been updated or added handling for that.
exception handling is my biggest concern, and not much code coverage there. It may change the error handling path and error log printing.
PR is updated. |
I'm open to suggestions as to what to call it. Or I can just call 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.
std::visit has similar issue as std::get,
fc::static_variant throws fc exception, std::visit throws std::bad_variant_access.
Also, std::get, if it is not guarded with check, please use fc::get, so when people copy the code or make change later on, std::get won't be miss-used without checking.
Can you please show me where this new exception type is going to cause problems in the system? I'm adding overhead to the use of I would much prefer to update the parts of the system that are expecting this exact fc exception message to be thrown and move them over to the std equivalent. |
Appreciate your concern on the performance impact, however, logic correctness triumphs speed before we have good test coverage. The change should not jeopardize the error handling, which seems to me noway to verify. |
I think if you eval everywhere std::variant is used and make sure exception handling does not introduce a change in behavior, then it would be really nice to complete remove dependency on anything in |
I guess you could be catching on a base type as well. |
As for tracking down all code paths, I think everyone needs to come to an agreement on what is acceptable and what the path forward should be. @larryk85 Could you please chime in on this was well. |
Could we move the exception part into another JIRA issue and push this PR in? |
Updated. |
@heifner @allenhan2 Please review again. |
throw; | ||
} catch( const fc::exception& e ) { | ||
handle_exception(e); | ||
} catch ( const std::exception& e ) { |
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.
Why was catch of std::exception added here? Do we really want all std::exceptions to be ignored? Either this is not needed OR this is a consensus change since nodes without this code will fail transaction differently.
Looking at this more, it is not necessarily a consensus change since std::variant can throw. My concern would be the use of something like std::vector::at() or some other throw of std::exception that would be handled differently now.
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.
An argument can be made that exceptions from something like std::vector::at() should be captured here as you have it. However, this could potentially be a consensus change. I'll leave it up to @b1bart to indicate if he is comfortable with this change. I have NOT reviewed all exception code paths to determine how safe this is. This comment goes for all the exception handling changes in this PR (not just here).
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.
Would it be better to catch just the specific std errors being thrown by variant and optional? I can change the std::exception
handler to std::bad_variant_access
and whatever specific std exceptions that are thrown.
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 think what you have is likely fine. I would only argue that someone does a thorough review of possible exceptions in code paths where this was added. I suspect there are not any other std exceptions we really need to worry about. So just need someone to review and give approval.
|
…od that will throw fc exception if variant does not currently hold requested type. Revived the static_variant tests.
d99f933
to
521040b
Compare
Replay was successful. Please take one last look. |
@heifner @allenhan2 I think this is ready to go. Please take another look. |
Cherry-picked from 9eaa571 (EOSIO/eos#9235) with additional fixes for later changes to 2.0.x.
Cherry-picked from 9eaa571 (EOSIO/eos#9235) with additional fixes for later changes to 2.0.x.
Change Description
This PR is to replace the use of
fc::static_variant
withstd::variant
. Based on performance metrics, std::variant is the better alternative.Jira: https://blockone.atlassian.net/browse/EPE-17
Jira issue has links to benchmarks describing performance improvement of
std::variant
overfc::static_variant
.Change Type
Select ONE
Consensus Changes
API Changes
Documentation Additions