Skip to content
This repository has been archived by the owner on Dec 16, 2020. It is now read-only.

Porting to build Rust wasm test datas with Bazel #613

Merged
merged 22 commits into from
Aug 25, 2020

Conversation

Shikugawa
Copy link
Member

Signed-off-by: Shikugawa [email protected]

Commit Message: Port to enable building Rust wasm test datas with Bazel with some of cargo-raze supporting scripts.
Additional Description:
Risk Level: Low
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
code = TestEnvironment::readFileToStringForTest(TestEnvironment::substitute(
absl::StrCat("{{ test_rundir }}/", kWasmRustDir, vm_configuration + "_rust.wasm")));
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did you move all those test files out of their current location? It seems like an unnecessary change that requires extra switches.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is because of the limitation of cargo-raze. We should generate build dependencies per Rust projects. But it will cause more complexity.

Copy link
Contributor

Choose a reason for hiding this comment

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

What's the issue? All those examples have the same dependencies, so cargo raze should always generate the same //cargo. Also, cargo raze is not executed as part of the build process, so it shouldn't really influence the location of checked-in *.rs and *.wasm files.

Having said that, this is me being pedantic, and if upstream doesn't mind and won't complain about this in the upstream PR, then we can merge this. cc @htuch

Copy link
Member Author

@Shikugawa Shikugawa Aug 13, 2020

Choose a reason for hiding this comment

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

In this case, processing artifacts from cargo raze is pretty complex. That is because these should be placed on envoy specific paths. So I'd like to automate these processes. If we do that when Rust test data are scattered and required special library for new Rust test data in the future, it will be difficult to automate them.

Copy link
Member

Choose a reason for hiding this comment

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

Is the issue that we're not putting the test .rs in the same directory as the test itself? It seems desirable to do this IMHO, otherwise Rust/Wasm is some strange outlier.

Copy link
Member

Choose a reason for hiding this comment

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

Also, please don't manually construct paths like you do here, if you want runtime files, use https://github.com/envoyproxy/envoy/blob/466245b50e6d475be841e1c8d5f254dd6ea41272/test/test_common/environment.h#L114

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure. But with desirable approach, we should manually edit cargo-raze generated scripts. IMHO it might have to be tech debt...., because we can't this process automatically.

@jplevyak jplevyak requested a review from PiotrSikora August 10, 2020 20:27
@jplevyak
Copy link
Contributor

Do we want this as part of the current upstream PR?

@jplevyak
Copy link
Contributor

Looks like @htuch wants this in the upstream PR. @PiotrSikora @Shikugawa

@@ -0,0 +1,46 @@
"""
Copy link
Member

Choose a reason for hiding this comment

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

Is the plan to check all of this into the main Envoy repo? Seems kind of terrifying from a maintenance perspective, even if automatically generated.

Copy link
Member Author

Choose a reason for hiding this comment

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

Exactly. But maintaining these automatically generated is not inevitable. I think that we should force to use this. And warn to use this script by DO NOT EDIT comment by inserting that "We must use tools/cargo-raze.sh".

Copy link
Member Author

Choose a reason for hiding this comment

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

or, automatically generate with cargo-raze.sh from pre-push script by checking the Cargo.toml had staged or not.

Copy link
Member

Choose a reason for hiding this comment

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

Meanwhile, yes, eventually I think it can made into rules_rust to generate WORKSPACE rule, just like rules_python's pip3_import.

Copy link
Member

Choose a reason for hiding this comment

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

Definitely want a tracking issue for this one, since this is a lot of boilerplate that we should be able to minimize. But I'd be willing to take it as MVP.

Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Copy link
Contributor

@PiotrSikora PiotrSikora left a comment

Choose a reason for hiding this comment

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

Mostly LGTM, with one seemingly unnecessary change.

@@ -10,9 +10,16 @@ proxy-wasm = "0.1"
log = "0.4"

[lib]
crate-type = ["cdylib"]
path = "src/*.rs"
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think you need this change? (here and in all other files).

Copy link
Member Author

Choose a reason for hiding this comment

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

Cargo.toml is only to trigger to generate bazel definition. So no need to take care.

Copy link
Contributor

Choose a reason for hiding this comment

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

I actually meant that the path = "src/*.rs" is not necessary, but my fault for not being clear about this.

Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Copy link
Contributor

@PiotrSikora PiotrSikora left a comment

Choose a reason for hiding this comment

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

LGTM, will defer to htuch@ to comment if you need any other changes to make this upstreamable.

Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Generally LGTM, a few remaining comments.

_new_http_archive(
name = "raze__hashbrown__0_7_2",
url = "https://crates-io.s3-us-west-1.amazonaws.com/crates/hashbrown/hashbrown-0.7.2.crate",
type = "tar.gz",
Copy link
Member

Choose a reason for hiding this comment

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

These are all very similar, can you create a _rust_crate(..) macro that factors out all the boilerplate? it should be possible to have just _rust_crate(name="hashbrown", version="0.7.2") and it can fill the rest I think.

Copy link
Contributor

Choose a reason for hiding this comment

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

Those are all automatically generated by cargo raze tool, using macros here would turn this into manual work.

@@ -0,0 +1,46 @@
"""
Copy link
Member

Choose a reason for hiding this comment

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

Definitely want a tracking issue for this one, since this is a lot of boilerplate that we should be able to minimize. But I'd be willing to take it as MVP.

wasm_rust_binary(
name = "shared_queue_rust.wasm",
srcs = ["shared_queue_rust/src/lib.rs"],
rustc_flags = ["-Clink-arg=-zstack-size=32768"],
Copy link
Member

Choose a reason for hiding this comment

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

Why do we have this stack size boiler plate?

Copy link
Contributor

Choose a reason for hiding this comment

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

There is one test that verifies linear memory size for test_rust.rs, but it can be removed from other tests... and test_rust.rs can be probably completely removed now that we have tests written using Proxy-Wasm Rust SDK.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just deleted unused stack size specification right now. I'm not sure if the test_rust.rs is required so missing it.

Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
Signed-off-by: Shikugawa <[email protected]>
@PiotrSikora PiotrSikora merged commit 057ab1f into envoyproxy:master Aug 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants