-
Notifications
You must be signed in to change notification settings - Fork 49
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
Proc-macro pipeline (issue #113) #127
Conversation
@andylokandy this is ready for review - only failing test across whole workspace is the test for issue #141. As things stand now the legacy tests for the legacy code all pass. Further work is likely just going to identify existing bugs, e.g. issue #141, so this needs to land before further progress. |
@taqtiqa-mark Thanks so much for your work! I'm just back from vacation so I'll review it in short. With just a glance, I notice you've committed the whole |
AFAIK, that is the Embassy use pattern - there is no crate, as yet. Also issue #131 gives some context. |
case
|
@andylokandy I'm in the middle of something else, but Q that comes to mind, is if that is this:
If so and its a blocker a workaround could be to start a |
Generally LGTM. I have two questions left:
|
I'd prefer to leave them in place until the related issues are resolved one way or another. For a couple of reasons:
Hmm, it did at one point. But this relates to the above question. Again a couple to reasons to prefer leaving it where it is: Hopefully some of the lowering logic can be finessed, likely into the analysis stage - we'll see. But even if we could get all stages to be as clean/simple as generate is now, I'd still argue the pipeline structure communicates immediately what is happening (ack lowering is still an exception to that). I'll take another look tomorrow and push up anything that results - likely mostly clean up and comments I outlined above. |
@zhongzc PTAL |
@taqtiqa-mark Very much appreciate your work. I'd be happy to merge it once the CI is satisfied, and @zhongzc has no objection. |
OK, I'll ping @andylokandy and @zhongzc when the CI is green. |
Github action says "step cannot have both the |
Yeah, I had to take a break. Embassy is nearly in place but the CI build may need a rethink, unless going back to deal with the root cause (throwing --all-features and --all-tagets everywhere) doesn't simplify things. |
I suspect that adding minicov to the build stack could be required. |
@taqtiqa-mark Looks good to me, let's take a try. |
Apologies for the misunderstanding. I thought this comment meant someone else was going to look into this: let's -> let us. I may have some time in the next few weeks, but my instinct is to try remove the embassy changes and leave embedded out of scope - unless I can recall why it is needed. Which I can't right now. |
Close issue tikv#113. Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
ac74956
to
04ae4a4
Compare
@andylokandy this should be ready for a fresh set of eyes. I'm going to nurse it through the CI guards, but that shouldn't block a code review of the substantive changes. On my machine If this all lands we can start moving some of the integration tests and the helper scripts. For now it is sufficient. |
Close issue tikv#113. Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
I believe this is expected:
|
Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
Pull Request Test Coverage Report for Build 6168403705
💛 - Coveralls |
Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
Signed-off-by: Mark Van de Vyver <mark@taqtiqa.com>
@andylokandy I think if you re-trigger the coveralls action you'll find the coverage has not deteriorated - even with the suspension of the additional tests that are awaiting the merge of this PR. As far as I can tell I can't move the CI build actions so may need yourself or someone similarly situated to help get these all green. |
@taqtiqa-mark I mis-opened the browser tab and commented in a wrong place. lol I found that most of the code changes were about moving |
No worries, gave me time to try and recall the reasons - its been near 18 months... I believe the reason is #143 . I don't recall the fine detail, but I'd say to be able to have feature flags passed to the minitrace-tests crate. Or some such reason. |
I have reviewed the majority of the files, which is a time-consuming process due to their volume. Before we proceed and merge the PR, there are several issues that need addressing:
(a) From minitrace 0.5 onwards, the (b) There are numerous unused options such as Consequently, I propose merging the 'macro-test' portion of this PR first as it's straightforward and independent. Although initially centered around macros. If you agree, I would like to directly edit this PR. |
Sure, but later I'll try persuade you of an easier approach. If I understand correctly the challenge will be keeping track of what came from where, so I think you're proposing this kind of workflow:
This would preserve the record of my effort. If so, then I'm happy with that approach and will help as and where I can. Nonetheless, I suggest a less painful approach might be: Create a
True this reorg may be unnecessary. That is, maybe core team should have closed the related cargo issue? Would be good if we have evidence it is no longer an issue. To test this easily you can just re-point 4-5 cargo references to the
True. However the current test suite passes. So a cleaner, and less effort, approach is to merge the PR and then add tests that should pass but fail. Then alter the code until they pass. This PR is not a release proposal and there is not reason anyone would expect master to be pristine.
Some of this may also be moot. Several of these were proposed near 18 months ago. #135 has been closed. Similarly #138 was also closed. Again here the most efficient way to address this is to write tests and remove/add code to make these green. Ack this is a chicken and egg problem - the test infrastructure wasn't there previously so it was hard to do. Any way, so we avoid the miscommunication we had earlier. Please confirm you are now taking up this PR to the point it is rejected or merged? |
Correct. And here is my reminder, to avoid miscommunication:
|
Thanks for the patience, ping me if you have any questions - hopefully I can remember what I was thinking :) |
@andylokandy is there anything I can do here? I don't recall seeing all these merge conflicts when I updated the PR. Let me know. |
Sorry for the delay. I've being working on merging this pr but there are some reasons why I haven't push the update here. 1. since 0.5.0, the proc macro has been significantly simplified (no more lifetime related things), therefore the pipeline seems too heavy for it. 2. The macro ui changes are either unimplemented or identifying problems that has been resloved in other way since 0.5.0. 3. The ui tests cases are already merged by your former PRs. I'm very sorry, based on the current situation, this PR can not be merged. |
No worries. Thanks for the update. |
Implement Validate stage.See issue Feature: Alltrace
attribute arguments are named/keyword arguments #142tests/spans
to mintrace-tests:tests/expand
to mintrace-tests:tests/expand
to mintrace-tests #137proc-macro-error
usage, per @yandros comment