graphql-engine/v3/crates/utils/recursion_limit_macro/Cargo.toml

[package]
name = "recursion_limit_macro"
version = "0.1.0"
edition = "2021"

[lib]
proc-macro = true
bench = false

[dependencies]
quote = "1"
syn = { version = "2", features = ["full"] }

[lints]
workspace = true
lang-graphql: limit recursion to avoid stack overflows This was a simple solution to prevent crashes from the cases that I was able to discover, refactored into a macro that can be used elsewhere; but I suspect there's a more idiomatic rust solution (entailing a big refactor?). There's also the stacker crate, and see also discussion here: https://hasurahq.slack.com/archives/C04PUMV4X16/p1707337409839869?thread_ts=1701302324.058369&cid=C04PUMV4X16 Note that the compiled binary was built and fuzzed with `--release`. Many discovered cases caused crashes when run into non-optimized binary (probably stack overflows but I did not look into it) V3_GIT_ORIGIN_REV_ID: 31acfc9e358c807be80ba6a5efa78ace78306291 2024-02-13 23:27:48 +03:00			`[package]`
			`name = "recursion_limit_macro"`
			`version = "0.1.0"`
			`edition = "2021"`

			`[lib]`
			`proc-macro = true`
All benchmarks must be Criterion benchmarks. (#498) This ensures only Criterion benchmarks get called by `cargo bench`. Previously, some tests were being loaded too. This is an issue because if we want to provide command-line arguments to Criterion, it will fail if we run a non-Criterion benchmark. We need to specify `harness = false` for each benchmark so that they don't get wrapped by Cargo, and `bench = false` for everything that doesn't contain benchmarks but _could_ (i.e. unit and integration tests). I find Cargo very strange in this regard. In addition, I fixed the validation benchmark by providing a valid SDL schema. V3_GIT_ORIGIN_REV_ID: 338ac5b1411eec7af32923863c5b6f3933c0454b 2024-04-23 15:59:38 +03:00			`bench = false`
lang-graphql: limit recursion to avoid stack overflows This was a simple solution to prevent crashes from the cases that I was able to discover, refactored into a macro that can be used elsewhere; but I suspect there's a more idiomatic rust solution (entailing a big refactor?). There's also the stacker crate, and see also discussion here: https://hasurahq.slack.com/archives/C04PUMV4X16/p1707337409839869?thread_ts=1701302324.058369&cid=C04PUMV4X16 Note that the compiled binary was built and fuzzed with `--release`. Many discovered cases caused crashes when run into non-optimized binary (probably stack overflows but I did not look into it) V3_GIT_ORIGIN_REV_ID: 31acfc9e358c807be80ba6a5efa78ace78306291 2024-02-13 23:27:48 +03:00
			`[dependencies]`
Use `syn` v2 in our own macros. (#574) This upgrades `darling` and `schemars` too, so they also use `syn` v2. V3_GIT_ORIGIN_REV_ID: 731160389115dfa079fb1e13e831204d278f5a40 2024-05-14 10:49:52 +03:00			`quote = "1"`
			`syn = { version = "2", features = ["full"] }`
use clippy settings in Cargo workspace (#441) <!-- Thank you for submitting this PR! :) --> ## Description Following the approach taken here: https://github.com/hasura/ndc-postgres/pull/402 This moves the `clippy` settings into the Cargo workspace file instead of passing them for each invocation. We enable all pedantic settings, run `cargo clippy --fix` to auto fix a few things, and then manually disable all other lints. Plenty of them are worth enabling and fixing in future IMO. --------- Co-authored-by: Samir Talwar <samir.talwar@hasura.io> V3_GIT_ORIGIN_REV_ID: aa0e6ccb8d72a7393e14b5c58b82077a67d9cb15 2024-04-08 13:13:26 +03:00
			`[lints]`
			`workspace = true`