Change:
let location_table = &LocationTable::new(&body); let mut errors_buffer = Vec::new(); <del> let (move_data, move_errors): (MoveData<'tcx>, Option<Vec<(Place<'tcx>, MoveError<'tcx>)>>) = </del> <ins> let (move_data, move_errors): (MoveData<'tcx>, Vec<(Place<'tcx>, MoveError<'tcx>)>) = </ins> match MoveData::gather_moves(&body, tcx, param_env) { <del> Ok(move_data) => (move_data, None), Err((move_data, move_errors)) => (move_data, Some(move_errors)), </del> <ins> Ok(move_data) => (move_data, Vec::new()), Err((move_data, move_errors)) => (move_data, move_errors), </ins> }; <ins> let promoted_errors = promoted .iter_enumerated() .map(|(idx, body)| (idx, MoveData::gather_moves(&body, tcx, param_env))); </ins> let mdpe = MoveDataParamEnv { move_data, param_env };

Discussion:
I get an ICE when I try to build : I tried stable, beta and nightly. All ended with an ICE.
Important detail: Only happens on the branch, not
(bisecting)
It happens with master branch as well if I do before building. Without it, it fails due to nalgebra issue before it even gets to evolvim-lib.
Ah, I see
regression in nightly-2019-08-17
great :). Unsure if you're bisecting this further, anyway pinging cleanup crew in case you are not doing it further and also to see if someone is able to get an mcve. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
There don't seem to be any prebuilt artifacts for that commit range, so I've stopped there.
Assigning meanwhile we don't have an mcve as .
() Errors: modify labels to -E-needs-mcve
The reduced example regresses at nightly-2019-09-29 (..). Edit2: For me, evolvim (develop branch) regresses on that nightly, too. <br<br<details<summary<del<ttgit log</tt<iafter bisection</i</del</summary</detailsEdit3: Damn it, recompiling didn’t make realize that the code had to be recompiled and I didn’t really notice that it had just skipped compilation entirely all the time.
Even smaller: () Errors: <details</details
regression in commit (part of ) cc modify labels: -E-needs-bisection
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Now that we have an -- thanks -- let's prioritize again
prioritize -- just testing the command
Error: This issue has already been requested for prioritization. Please let know if you're having trouble with this bot.

prioritize -- just testing the command
Looks like this compiles but it shouldn't: Dumping the MIR for this you get: Presumably, what should happen here is: The occurs here: cc
This issue is already prioritized as removing label.
I guess we need to track down where [S; 1] is emitted and make that code also look at the MIR of promoteds. We can't avoid that code from getting promoted without getting into an unfun game of whack-a-mole in the promotion code.
The error is constructed here: which is called here: and here:
hmmm... not sure what borrowck does to promoteds. I mean we basically declared all lifetimes to be static, but the same is true for the body of constants which we do run borrowck on. So... let's try to just run borrowck on promoteds and see how it goes.
alternatively we just run the logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.