fix/ebpf #5026

[AkarshSahlot]

Description
It fixes eBPF backend which was incorrectly skipping emit statements inside if blocks.
I made changes in ebpfDeparser.cpp and ebpfDeparser.h ,after I used grep command for tracking emit and if
what have I Changed
I modified DeparserBodyTranslator to track it statement context.
Preserved emit calls inside conditional blocks.
added a new method for if statement, and verified with emit-bug.p4
tell me what more to add or change
fixes #5026

[jafingerhut]

I do not feel qualified to comment on the C++ code changes themselves, but wanted to mention to you that there are 3 failing CI tests. I'd recommend looking at the failure logs that you can find in the CI logs linked from the issue #5227 in the "Some checks were not successful" section near the bottom of that page. It can also be nice in diagnosing the root cause of such failures if you can figure out how to run the tests locally on your own system.

[AkarshSahlot]

I do not feel qualified to comment on the C++ code changes themselves, but wanted to mention to you that there are 3 failing CI tests. I'd recommend looking at the failure logs that you can find in the CI logs linked from the issue #5227 in the "Some checks were not successful" section near the bottom of that page. It can also be nice in diagnosing the root cause of such failures if you can figure out how to run the tests locally on your own system.

It was just an indentation issue,I solved it and pushed the code

[jafingerhut]

After your commit on 2025-Apr-10, there is still a p4c-lint failure, but there is also a failure of the CI test named "[test-p4c-debian / test-ubuntu22 (Unity ON, GTest ON)". I would be surprised if that second one is only due to whitespace.

[AkarshSahlot]

After your commit on 2025-Apr-10, there is still a p4c-lint failure, but there is also a failure of the CI test named "[test-p4c-debian / test-ubuntu22 (Unity ON, GTest ON)". I would be surprised if that second one is only due to whitespace.

yes u were right about it , I fixed it

[jafingerhut]

In general, the creator of a PR should try to make changes to it until it passes all CI tests. If you need help to determine why some particular tests are failing, please ask specific questions about specific tests failing, after trying to think about it for at least a little while, and ideally trying to reproduce the failing test case on your local system, if you know how.

If you want a review of your code, or ask questions of whether your approach is generally in the right direction, even though there are failing test cases, then please ask that in a comment. Otherwise, people are usually working on their own issues or PRs, and will wait until all tests pass before giving much attention to someone else's PR (because if there are failing tests, it will almost never be considered for approval and merging in that state).