From b085469602ce5da990ac6d76e6c73d2d63ed45a6 Mon Sep 17 00:00:00 2001 From: Anton-4 <17049058+Anton-4@users.noreply.github.com> Date: Mon, 14 Dec 2020 16:09:16 +0100 Subject: [PATCH] Replaced large_enum_variant explanation with link to issue #800 --- compiler/build/src/lib.rs | 11 +---------- compiler/builtins/src/lib.rs | 11 +---------- compiler/can/src/def.rs | 1 + compiler/can/src/lib.rs | 11 +---------- compiler/collections/src/lib.rs | 11 +---------- compiler/constrain/src/lib.rs | 11 +---------- compiler/fmt/src/lib.rs | 11 +---------- compiler/gen/src/lib.rs | 11 +---------- compiler/gen_dev/src/lib.rs | 11 +---------- compiler/load/src/lib.rs | 11 +---------- compiler/module/src/lib.rs | 11 +---------- compiler/mono/src/lib.rs | 11 +---------- compiler/parse/src/lib.rs | 11 +---------- compiler/problem/src/lib.rs | 11 +---------- compiler/region/src/lib.rs | 11 +---------- compiler/reporting/src/lib.rs | 11 +---------- compiler/solve/src/lib.rs | 11 +---------- compiler/types/src/lib.rs | 11 +---------- compiler/unify/src/lib.rs | 11 +---------- compiler/uniq/src/lib.rs | 11 +---------- editor/src/lib.rs | 11 +---------- 21 files changed, 21 insertions(+), 200 deletions(-) diff --git a/compiler/build/src/lib.rs b/compiler/build/src/lib.rs index 896bcc6c21..e2abf50874 100644 --- a/compiler/build/src/lib.rs +++ b/compiler/build/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod link; pub mod program; diff --git a/compiler/builtins/src/lib.rs b/compiler/builtins/src/lib.rs index 63a936ce39..ba07aa6f8c 100644 --- a/compiler/builtins/src/lib.rs +++ b/compiler/builtins/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod bitcode; pub mod std; diff --git a/compiler/can/src/def.rs b/compiler/can/src/def.rs index 95864ad67d..e58cb21df1 100644 --- a/compiler/can/src/def.rs +++ b/compiler/can/src/def.rs @@ -83,6 +83,7 @@ enum PendingDef<'a> { InvalidAlias, } +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #[derive(Clone, Debug, PartialEq)] #[allow(clippy::large_enum_variant)] pub enum Declaration { diff --git a/compiler/can/src/lib.rs b/compiler/can/src/lib.rs index 44c7bf3faa..158426477e 100644 --- a/compiler/can/src/lib.rs +++ b/compiler/can/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod annotation; pub mod builtins; diff --git a/compiler/collections/src/lib.rs b/compiler/collections/src/lib.rs index 79c906ee0c..5f54b3f3a1 100644 --- a/compiler/collections/src/lib.rs +++ b/compiler/collections/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod all; diff --git a/compiler/constrain/src/lib.rs b/compiler/constrain/src/lib.rs index d75e00643f..0e30c75a9c 100644 --- a/compiler/constrain/src/lib.rs +++ b/compiler/constrain/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod builtins; pub mod expr; diff --git a/compiler/fmt/src/lib.rs b/compiler/fmt/src/lib.rs index c03633bddf..db3530b0aa 100644 --- a/compiler/fmt/src/lib.rs +++ b/compiler/fmt/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod annotation; pub mod def; diff --git a/compiler/gen/src/lib.rs b/compiler/gen/src/lib.rs index c86b32f6a5..79649fe3fd 100644 --- a/compiler/gen/src/lib.rs +++ b/compiler/gen/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod llvm; diff --git a/compiler/gen_dev/src/lib.rs b/compiler/gen_dev/src/lib.rs index d91bb8f59a..3417941a82 100644 --- a/compiler/gen_dev/src/lib.rs +++ b/compiler/gen_dev/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] use bumpalo::{collections::Vec, Bump}; diff --git a/compiler/load/src/lib.rs b/compiler/load/src/lib.rs index 52a7a2b7f8..977b57afef 100644 --- a/compiler/load/src/lib.rs +++ b/compiler/load/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod docs; pub mod effect_module; diff --git a/compiler/module/src/lib.rs b/compiler/module/src/lib.rs index 4c837c4275..50d5d356a4 100644 --- a/compiler/module/src/lib.rs +++ b/compiler/module/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod ident; diff --git a/compiler/mono/src/lib.rs b/compiler/mono/src/lib.rs index e44b3d7fae..188e856c93 100644 --- a/compiler/mono/src/lib.rs +++ b/compiler/mono/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod borrow; diff --git a/compiler/parse/src/lib.rs b/compiler/parse/src/lib.rs index 858070e101..adb36adf78 100644 --- a/compiler/parse/src/lib.rs +++ b/compiler/parse/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] #[macro_use] diff --git a/compiler/problem/src/lib.rs b/compiler/problem/src/lib.rs index 11610b6314..333c9990a8 100644 --- a/compiler/problem/src/lib.rs +++ b/compiler/problem/src/lib.rs @@ -1,13 +1,4 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod can; diff --git a/compiler/region/src/lib.rs b/compiler/region/src/lib.rs index 79c906ee0c..5f54b3f3a1 100644 --- a/compiler/region/src/lib.rs +++ b/compiler/region/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod all; diff --git a/compiler/reporting/src/lib.rs b/compiler/reporting/src/lib.rs index 12ef1d2a39..c8550d9966 100644 --- a/compiler/reporting/src/lib.rs +++ b/compiler/reporting/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod error; diff --git a/compiler/solve/src/lib.rs b/compiler/solve/src/lib.rs index 9718a929a9..3d093e2c1e 100644 --- a/compiler/solve/src/lib.rs +++ b/compiler/solve/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod module; diff --git a/compiler/types/src/lib.rs b/compiler/types/src/lib.rs index b98f1f9944..0ec67509c7 100644 --- a/compiler/types/src/lib.rs +++ b/compiler/types/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod boolean_algebra; pub mod builtin_aliases; diff --git a/compiler/unify/src/lib.rs b/compiler/unify/src/lib.rs index 2bb083f4bc..39437895b0 100644 --- a/compiler/unify/src/lib.rs +++ b/compiler/unify/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub mod unify; diff --git a/compiler/uniq/src/lib.rs b/compiler/uniq/src/lib.rs index 4838333e89..cb790d59e6 100644 --- a/compiler/uniq/src/lib.rs +++ b/compiler/uniq/src/lib.rs @@ -1,14 +1,5 @@ #![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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] pub use roc_can::expr::Expr::*; diff --git a/editor/src/lib.rs b/editor/src/lib.rs index caff5bf525..fe8de3aa7b 100644 --- a/editor/src/lib.rs +++ b/editor/src/lib.rs @@ -1,14 +1,5 @@ #![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 structure 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. +// See github.com/rtfeldman/roc/issues/800 for discussion of the large_enum_variant check. #![allow(clippy::large_enum_variant)] // Inspired by: