#![allow(clippy::too_long_first_doc_paragraph)] in lib.rs is ignored

[IceTDrinker]

Description

Some of our doc comments have long first paragraphs, which we explicitely opt-in to allow but we still get the clippy warnings

project where this is happening:

https://github.com/zama-ai/tfhe-rs/

RUSTFLAGS="-C target-cpu=native" cargo "+nightly-2024-11-29" clippy --all-targets \
        --features=x86_64-unix,boolean,shortint,integer,internal-keycache,zk-pok,strings \
        -p tfhe -- --no-deps -D warnings

Version

rustc 1.85.0-nightly (a2545fd6f 2024-11-28)
binary: rustc
commit-hash: a2545fd6fc66b4323f555223a860c451885d1d2b
commit-date: 2024-11-28
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4

Additional Labels

No response

[IceTDrinker]

Edit: see comment below for actual toolchain causing the issue after nightly-2024-10-03

looks like the culprit could be

edit: unclear as something else pops up, last good known toolchain was: nightly-2024-10-03-x86_64-unknown-linux-gnu

rustc 1.84.0-nightly (439284741 2024-10-21)
binary: rustc
commit-hash: 4392847410ddd67f6734dd9845f9742ff9e85c83
commit-date: 2024-10-21
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1

[IceTDrinker]

Actual toolchain exhibiting the issue nightly-2024-10-19:

rustc 1.84.0-nightly (e92993dbb 2024-10-18)
binary: rustc
commit-hash: e92993dbb43f0a5d17fe56e2d82f90435d6521c8
commit-date: 2024-10-18
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1

[DylanBulfin]

I think I found the problem. there was a PR around the time you started experiencing issues that moved this lint to the nursery category: #13551

Your project does explicitly allow the lint but immediately afterwards warns all nursery lints: https://github.com/zama-ai/tfhe-rs/blob/45717275f6918547ca6b0701dbb64b7526d47519/tfhe/src/lib.rs#L54

I'd imagine if you move the allow after that line it will work but it may be a little more complicated than that. Either way hope this helps

[IceTDrinker]

Ah I see we should warn then allow, last configuration being the one applied potentially

[IceTDrinker]

Re ordering seems to do the trick, it is logical when you think about it, but then maybe a warning/lint to warn first allow after or something about order of settings could be welcome. I'll close this

Thanks