Create 2021.02.16-lazy-norm.md

Author: lcnr

meetings/2021.02.16-lazy-norm.md

@@ -0,0 +1,52 @@
+# cg meeting 2021-02-16
+
+## issue
+
+1. We must not typeck anonymous constants in some early queries, most notably `query type_of` and `query predicates_of`. Even if we were to use some hacks, there is a limit to how independent we can make this. One hard barrier is `query crate_variances`.
+2. When using the `const_generics` feature gate, anonymous constants currently have all the generic parameters of their parent, even if they are unused inside of the constant. This breaks some programs, some of which already compile on stable.
+```rust
+fn bind<const N: usize>(value: [u8; N]) -> [u8; 3 + 4] {
+    todo!()
+}
+
+fn main() {
+    let mut arr: ?0 = Default::default();
+    arr = bind(arr); //~ ERROR mismatched type
+    // ?0 = [u8; ?c2]
+    // [u8; D<[u8; ?c2]>] <: [u8; ?c2]
+    // D<[u8; ?c2]> = ?c2 
+    // --> occurs check violation
+}
+```
+and https://github.com/rust-lang/rust/issues/78369:
+```rust=
+#![feature(lazy_normalization_consts)]
+// `1 + 4` now "depends on T", preventing us from
+// being able to unsize `P` here.
+struct P<T: ?Sized>([u8; 1 + 4], T);
+
+fn main() {
+    let x: Box<P<[u8; 0]>> = Box::new(P(Default::default(), [0; 0]));
+    let _: Box<P<[u8]>> = x;
+}
+```
+## solution
+
+Eagerly filter the supplied generic params to the anonymous constant.
+
+- only depend on the predicates and parameters which can be used by the anon const based on what we know by looking at the `hir`.
+    - using a graph
+        -  build a graph with parameters being nodes and an edge between 2 parameters if the target parameter can be reached by using the source parameter.
+        -  only add the parameters which are part of the reachable subgraph containing all explicitly mentioned parameters.
+    - using relations
+        - a relation `R` which holds for all params which are part of the same predicate
+        - compute the transitive closure of `R` on the set of explicitly mentioned parameters
+- have to do all of this without looking at the parents `predicates_of` because that may contain our constant.
+- can a `U: Trait<T>` somehow "pull in" `U` if only `T` is explicitly used?
+    - let's start with "yes".
+- should we consider `T` used because of `ConcreteTy: Trait<T>`? We currently do use that predicate for `ConcreteTy::ASSOC_CONST`.
+    - probably yes.
+- would going from this approach to a more precise one be a breaking change?
+    - with a high probability not.
+- DECISION:
+    - DO IT