Replaced large_enum_variant explanation with link to issue #800

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;

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;

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 {

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;

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;

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;

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;

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;

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};

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;

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;

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;

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]

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;

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;

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;

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;

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;

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;

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::*;

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: