From 8ef2ae3de71ef08956df8e911b200953a2708302 Mon Sep 17 00:00:00 2001 From: Richard Feldman Date: Thu, 5 Mar 2020 23:03:29 -0500 Subject: [PATCH] clippy clip clip --- compiler/can/src/lib.rs | 12 ++++++++++++ compiler/module/src/lib.rs | 13 +++++++++++++ compiler/parse/src/lib.rs | 13 +++++++++++++ compiler/region/src/lib.rs | 13 +++++++++++++ compiler/types/src/lib.rs | 12 ++++++++++++ 5 files changed, 63 insertions(+) diff --git a/compiler/can/src/lib.rs b/compiler/can/src/lib.rs index 2c38c6b3d7..0e6f32fcfc 100644 --- a/compiler/can/src/lib.rs +++ b/compiler/can/src/lib.rs @@ -1,3 +1,15 @@ +#![warn(clippy::all, clippy::dbg_macro)] +// I'm skeptical that clippy:large_enum_variant is a good lint to have globally enabled. +// +// It warns about a performance problem where the only quick remediation is +// to allocate more on the heap, which has lots of tradeoffs - including making it +// long-term unclear which allocations *need* to happen for compilation's sake +// (e.g. recursive structures) versus those which were only added to appease clippy. +// +// Effectively optimizing data struture memory layout isn't a quick fix, +// and encouraging shortcuts here creates bad incentives. I would rather temporarily +// re-enable this when working on performance optimizations than have it block PRs. +#![allow(clippy::large_enum_variant)] pub mod annotation; pub mod constraint; pub mod def; diff --git a/compiler/module/src/lib.rs b/compiler/module/src/lib.rs index a1a0f7fa91..78777141ce 100644 --- a/compiler/module/src/lib.rs +++ b/compiler/module/src/lib.rs @@ -1,3 +1,16 @@ +#![warn(clippy::all, clippy::dbg_macro)] +// I'm skeptical that clippy:large_enum_variant is a good lint to have globally enabled. +// +// It warns about a performance problem where the only quick remediation is +// to allocate more on the heap, which has lots of tradeoffs - including making it +// long-term unclear which allocations *need* to happen for compilation's sake +// (e.g. recursive structures) versus those which were only added to appease clippy. +// +// Effectively optimizing data struture memory layout isn't a quick fix, +// and encouraging shortcuts here creates bad incentives. I would rather temporarily +// re-enable this when working on performance optimizations than have it block PRs. +#![allow(clippy::large_enum_variant)] + pub mod ident; pub mod symbol; diff --git a/compiler/parse/src/lib.rs b/compiler/parse/src/lib.rs index 9120c59c93..cb12761886 100644 --- a/compiler/parse/src/lib.rs +++ b/compiler/parse/src/lib.rs @@ -1,3 +1,16 @@ +#![warn(clippy::all, clippy::dbg_macro)] +// I'm skeptical that clippy:large_enum_variant is a good lint to have globally enabled. +// +// It warns about a performance problem where the only quick remediation is +// to allocate more on the heap, which has lots of tradeoffs - including making it +// long-term unclear which allocations *need* to happen for compilation's sake +// (e.g. recursive structures) versus those which were only added to appease clippy. +// +// Effectively optimizing data struture memory layout isn't a quick fix, +// and encouraging shortcuts here creates bad incentives. I would rather temporarily +// re-enable this when working on performance optimizations than have it block PRs. +#![allow(clippy::large_enum_variant)] + #[macro_use] pub mod parser; pub mod ast; diff --git a/compiler/region/src/lib.rs b/compiler/region/src/lib.rs index 6dc1d959b5..79c906ee0c 100644 --- a/compiler/region/src/lib.rs +++ b/compiler/region/src/lib.rs @@ -1 +1,14 @@ +#![warn(clippy::all, clippy::dbg_macro)] +// I'm skeptical that clippy:large_enum_variant is a good lint to have globally enabled. +// +// It warns about a performance problem where the only quick remediation is +// to allocate more on the heap, which has lots of tradeoffs - including making it +// long-term unclear which allocations *need* to happen for compilation's sake +// (e.g. recursive structures) versus those which were only added to appease clippy. +// +// Effectively optimizing data struture memory layout isn't a quick fix, +// and encouraging shortcuts here creates bad incentives. I would rather temporarily +// re-enable this when working on performance optimizations than have it block PRs. +#![allow(clippy::large_enum_variant)] + pub mod all; diff --git a/compiler/types/src/lib.rs b/compiler/types/src/lib.rs index bbe1c47d3d..86db916369 100644 --- a/compiler/types/src/lib.rs +++ b/compiler/types/src/lib.rs @@ -1,3 +1,15 @@ +#![warn(clippy::all, clippy::dbg_macro)] +// I'm skeptical that clippy:large_enum_variant is a good lint to have globally enabled. +// +// It warns about a performance problem where the only quick remediation is +// to allocate more on the heap, which has lots of tradeoffs - including making it +// long-term unclear which allocations *need* to happen for compilation's sake +// (e.g. recursive structures) versus those which were only added to appease clippy. +// +// Effectively optimizing data struture memory layout isn't a quick fix, +// and encouraging shortcuts here creates bad incentives. I would rather temporarily +// re-enable this when working on performance optimizations than have it block PRs. +#![allow(clippy::large_enum_variant)] pub mod boolean_algebra; pub mod subs; pub mod types;