wkt! macro for compile time checking of static WKT text

[kylebarron]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• I ran cargo fmt

---

Originally copied from the wkt-types implementation but then started copying from #112, since that looked to have nicer separation of concerns.

This is implemented on top of #135 and that should be merged first.

Closes #112 Closes #132

[kylebarron]

Should wkt! { POINT (1 2) } output a Point or a Wkt?

In geo_types::wkt! it outputs a Point and not a Geometry. Perhaps it would be best to follow that approach here, where we don't have that top-level wrapper to coerce to a Wkt?

Edit: I updated this PR to output the concrete type (e.g. Point) instead of Wkt, the thinking being that it's easier to go from concrete type to enum (e.g. via into()) than downcasting from the enum.

[kylebarron]

I think all the primitive types now work; still working through edge cases with Geometry collections. E.g. this doesn't fail to compile:

Edit: Fixed in a861c69 (#137)

[kylebarron]

I wonder if there's an easy way to write a literal that gets parsed as both rust source code and a string literal? Because then we can just use assert_eq to assert that the WKT string parser is equivalent to the macro generator

[kylebarron]

Note: This PR doesn't currently handle closing of polygons, like the geo_types wkt macro apparently does

[michaelkirk]

Should wkt! { POINT (1 2) } output a Point or a Wkt?
the thinking being that it's easier to go from concrete type to enum (e.g. via into()) than downcasting from the enum.

For the same reason, I agree!

[michaelkirk]

I wonder if there's an easy way to write a literal that gets parsed as both rust source code and a string literal? Because then we can just use assert_eq to assert that the WKT string parser is equivalent to the macro generator

Seems like it should be doable with a custom test macro that utilizes stringify!? Unless it simplifies this PR, I'd almost rather wait to incorporate it though, because there's already a lot to see here.

[kylebarron]

Note: This PR doesn't currently handle closing of polygons, like the geo_types wkt macro apparently does

Upon closer read, I don't think it's geo_types::wkt! that handles that; it's the geo_types::Polygon constructor that adds an extra coord if needed.

I wonder if there's an easy way to write a literal that gets parsed as both rust source code and a string literal? Because then we can just use assert_eq to assert that the WKT string parser is equivalent to the macro generator

Seems like it should be doable with a custom test macro that utilizes stringify!? Unless it simplifies this PR, I'd almost rather wait to incorporate it though, because there's already a lot to see here.

💯

I hadn't been aware of stringify. It still might require our literals to be defined twice once in the stringify! macro and once in the wkt! macro. Agreed we can leave it for the future. I think the current tests are good enough.

[kylebarron]

I used this branch last night in geoarrow/geoarrow-rs#1043 and it worked like a charm. See https://github.com/geoarrow/geoarrow-rs/pull/1043/files#diff-cfdac2ccc25441e1e7f36dda38525bb4468123e46129cb6c8ca5d267ff3db0c5

[kylebarron]

I updated this for the newly-fallible constructors in 4bf8048 (#135). I believe we should be able to call just unwrap() instead of unwrap_or(empty(Dimension)) because that path in the macro is only used if the macro text is not EMPTY.

[michaelkirk]

This looks great!

A couple little nits in the tests with some commented out tests - either (preferred) uncomment them, or delete them if that's complicated for some reason.

Thanks for writing all these tests!

The implementation is a little verbose, and I have some ideas for patterning out the macros, but I can do that in a followup.