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

Fix/remove fallthrough #13084

Closed

Conversation

thomaswatters
Copy link

@thomaswatters thomaswatters commented Oct 3, 2019

Describe problem solved by the proposed pull request
While browsing source I saw mc_pos_control had a compiler flag with a TODO to modify to remove it. Was an easy enough change

Test data / coverage
Can't find unit tests that cover flight stack modules

Describe your preferred solution
Extract the switch fallthrough statements into function flows

Describe possible alternatives
Countless

@dagar dagar requested a review from MaEtUgR October 3, 2019 02:42
class Takeoff::StateHandler
{
public:
static void handleDisarmed(const StateParams& params);
Copy link
Author

Choose a reason for hiding this comment

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

maybe these should be inlined, then we are closer to the switch fallthrough implementation

@thomaswatters
Copy link
Author

Should probably be noted this is just a refactor, there is no external change to the module

if (!armed) {
_takeoff_state = TakeoffState::disarmed;
else
{
Copy link
Author

Choose a reason for hiding this comment

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

remove new line before brace


default:
break;
if (!armed) {
Copy link
Author

Choose a reason for hiding this comment

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

spacing

Copy link
Author

Choose a reason for hiding this comment

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

apply clang-tidy format to file

Copy link
Member

Choose a reason for hiding this comment

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

We use astyle. To format your code locally before uploading just run make format and it will automatically be corrected.

@thomaswatters
Copy link
Author

whats the target c++ standard for the project? C++17 added a [[fallthrough]] attribute, that might be a better solution

@thomaswatters
Copy link
Author

whats the target c++ standard for the project? C++17 added a [[fallthrough]] attribute, that might be a better solution

Nevermind found my own answer, the root CMakeList sets c++11 to be required standard, therefore the attribute shouldn't be considered an option

@MaEtUgR
Copy link
Member

MaEtUgR commented Oct 7, 2019

@thomaswatters I really appreciate that you took the time to look into the TODO you found in the code. I'm assuming you are missing some context on why it is there. The code is not broken and the compiler flag could theoretically just be removed like I tested in #13104 BUT it's there because a certain ccache version that is still shipped with Ubuntu 16.04 has a bug and when doing incremental builds based on the ccache cache (all happening in the background even when doing make clean every time) the compiler hangs at the explicit // FALLTHROUGH messages probably because they are considered comments and hence not cached. See:

This ccache bug was fixed a long time ago but we are still supporting vanilla Ubuntu 16.04 because there are certain ROS computer vision applications only running on 16.04. The future way will like you already suggested be to switch to C++17 and use the [[fallthrough]]; statement for these cases. See also #12825 (comment), #13104 (comment). Currently it's not working because of one board that we support and needs a certain compiler.

Your proposed solution with the StateHandler looks perfectly correct but being honest it is in my opinion harder to read than the original implementation with fallthroughs. What do you think after getting the context?

@MaEtUgR
Copy link
Member

MaEtUgR commented Oct 9, 2019

@thomaswatters I wrote another comment summarizing all the findings in the original issue: #12813 (comment)

Would you agree if we close this pr?

@thomaswatters
Copy link
Author

@thomaswatters I wrote another comment summarizing all the findings in the original issue: #12813 (comment)

Would you agree if we close this pr?

certainly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants