stackable-odbc-core/Cargo.toml at main · stackabletech/stackable-odbc-core · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
[package]
name = "stackable-odbc-core"
version = "0.1.0"
edition = "2024"
rust-version = "1.95.0"
authors = ["Stackable GmbH <info@stackable.tech>"]
license = "Apache-2.0"

# Publishing is switched off at the manifest, not only in `release.toml`.
# `cargo publish` refuses outright while this is false, so neither a stray
# `cargo release --execute` nor a hand-run publish can push this crate to
# crates.io by accident.
publish = false
repository = "https://github.com/stackabletech/stackable-odbc-core"
homepage = "https://github.com/stackabletech/stackable-odbc-core"
documentation = "https://docs.rs/stackable-odbc-core"
description = "Database-independent framework for building ODBC drivers in Rust. Implement two traits, get a conformant ODBC 3.80 driver."
readme = "README.md"
keywords = ["odbc", "database", "driver", "ffi", "sql"]
categories = ["database", "external-ffi-bindings", "api-bindings"]

# What does NOT go in the published tarball.
#
# `rust-toolchain.toml` is the important one: shipped, it pins *consumers* to
# 1.95.0, because rustup honours the file it finds in a vendored or unpacked
# dependency. That is a known docs.rs and vendoring failure mode, and the pin is
# a contributor convenience with no business travelling with the crate.
exclude = [
    "rust-toolchain.toml",
    ".github/",
    "release/",
    "release.toml",
    "fuzz/",
    "bench/",
    "AGENTS.md",
    "CLAUDE.md",
    "clippy.toml",
    "deny.toml",
    "rustfmt.toml",
    ".pre-commit-config.yaml",
    ".markdownlint.yaml",
    # Saved `proptest` failure seeds. Test-only data, and the tests that read it
    # are not compiled from the published tarball.
    "proptest-regressions/",
]

# docs.rs builds for a single target by default, which would leave `ConfigDSNW`
# and the seven other `#[cfg(windows)]` items undocumented, exactly the parts
# a Windows driver author needs. Build the docs on Windows, and turn on the
# `test-support` feature so the `conformance` module a driver's test suite uses
# is documented too.
[package.metadata.docs.rs]
default-target = "x86_64-pc-windows-msvc"
targets = ["x86_64-pc-windows-msvc", "x86_64-unknown-linux-gnu"]
features = ["test-support"]

[features]
# Test support for driver crates and for `fuzz/`. Two things:
#
# - the `conformance` module, which drives `SQLGetInfoW` through the real C ABI
#   to check an info type's return shape;
# - `test_support::parse_attributes_summary_w`, which lets the `parse_attributes`
#   fuzz target reach a `pub(crate)` raw-pointer parser from a separate crate.
#
# Default-off because it is test code. Compiled unconditionally it lands in
# every driver's production binary, and it reaches an `unreachable!()` through a
# public `unsafe fn` taking a caller-supplied `u16` — a panic path a shipped
# driver has no reason to carry. Driver test suites enable it under
# `[dev-dependencies]`; `fuzz/Cargo.toml` enables it on its path dependency.
test-support = []

[dependencies]
odbc-sys = "0.31"
snafu = "0.9"
tracing = "0.1"
tracing-appender = "0.2"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

[dev-dependencies]
proptest = "1"
# For `tests/logging.rs`, which installs a competing global subscriber before
# calling `init_logging`. That has to run in its own process, so it cannot be a
# unit test, and an integration test reaches only the public API plus these.
tracing-subscriber = "0.3"

# Exhaustive interleaving checker for the handle lock discipline. The models
# themselves live in `src/handles/registry.rs`'s
# `#[cfg(all(test, loom))] mod loom_tests`, and `src/sync.rs`'s type aliases
# are gated the same way, so `loom` is only ever resolved inside a test build
# with `--cfg loom` set. That keeps it a dev-dependency: it never appears in a
# downstream consumer's resolved dependency graph.
[target.'cfg(loom)'.dev-dependencies]
loom = "0.7"

[lints.rust]
# `loom` is a custom cfg (see `src/sync.rs`), set via `RUSTFLAGS="--cfg loom"`
# rather than a Cargo feature, so rustc does not know its name is legitimate
# without this declaration.
unexpected_cfgs = { level = "warn", check-cfg = ["cfg(loom)"] }

[lints.clippy]
expect_used = "deny"
unwrap_in_result = "deny"
unwrap_used = "deny"
panic = "deny"