Large compile times with repetitive trait bound

[Farkal]

I am using wundergraph that generate lot of macro code and it seems rustc have hard time resolving code here and here

I tried this code:
https://github.com/Farkal/test-wundergraph

I expected to see this happen:
Less than 40sc of compilation on each change

Instead, this happened:
40sc or more of compilation

Meta

rustc --version --verbose:
rustc 1.41.0 (5e1a799 2020-01-27)
binary: rustc
commit-hash: 5e1a799
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

[estebank]

CC #65510 #42596 #40353

[weiznich]

I'm not sure if that's really something that could be minimized to mcve. I've run cargo expand on the provided example crate and uploaded the result here. As github struggles with large files, I cannot directly link to the relevant lines, but there are large repetitive trait bounds from line 20180 to 21671, from 21746 to 23227, from 23311 to 24792, from 31619 to 32710, from 32786 to 33877 and from 33961 to 35052.

My blind guess is that there is no single bound that takes time, but that there are just that many bounds that rustc struggles with them.

[Mark-Simulacrum]

A MCVE in this case could still be a very large file, but would ideally not have any dependencies beyond libcore.

See https://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ for some techniques on that.

[weiznich]

I've run rustc with the self profiler enabled on an incremental build:

+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| Item                                          | Self time | % of total time | Time     | Item count | Cache hits | Blocked time | Incremental load time |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| typeck_tables_of                              | 27.83s    | 28.444          | 28.93s   | 3          | 0          | 0.00ns       | 773.96µs              |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| LLVM_module_codegen_emit_obj                  | 23.45s    | 23.964          | 23.45s   | 49         | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| LLVM_passes                                   | 12.88s    | 13.161          | 12.88s   | 1          | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| codegen_module                                | 8.68s     | 8.872           | 12.81s   | 48         | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| run_linker                                    | 8.35s     | 8.530           | 8.35s    | 1          | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| normalize_projection_ty                       | 4.75s     | 4.851           | 5.04s    | 5025       | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| codegen_fulfill_obligation                    | 2.98s     | 3.049           | 3.26s    | 785        | 0          | 0.00ns       | 35.71ms               |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| evaluate_obligation                           | 1.90s     | 1.938           | 1.93s    | 26070      | 0          | 0.00ns       | 0.00ns                |
+-----------------------------------------------+-----------+-----------------+----------+------------+------------+--------------+-----------------------+
| type_op_prove_predicate                       | 1.53s     | 1.567           | 1.53s    | 124        | 0          | 0.00ns       | 0.00ns                |
...

A MCVE in this case could still be a very large file, but would ideally not have any dependencies beyond libcore.

See https://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ for some techniques on that.

I do not see how it would be possible to practical reduce this to something that only depends on core, without investing weeks of work. Diesel, wundergraph and juniper a quite big complicated codebases that have a lot of dependencies on their own. Additionally this example uses a lot of functionality from all of this crates, so there is no simple way to discard larger junks of code. I concatenating all of those crates into one file will not help, right?