You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I handled this by adding the relevant outlives relationships to all points. But, looking at the outlives.facts I saw that these relations account for a LOT of noise. Of the ~500K tuples in that file, about half are due to this. =) Moreover, these tuples will mess up any optimizations like #20. It's clear we need a better approach, but I'm not sure what.
That said, manually removing those tuples and re-running the analysis shows that they only have a small effect on overall performance (from ~40s to ~35s).
The text was updated successfully, but these errors were encountered:
In my branch nll-alias-analysis-no-loc-call, I take a different approach that removes Location::All. However, I suspect it will have some "not obviously desirable" effects.
In particular, if you "reassign" a variable that has a type annotation, you get "fresh regions":
fnfoo(mutx:&'staticu32){let y = 22;
x = &y;// OK// ... here, `x` is not considered `'static` ..}
This falls out from trying to be smart about examples like:
letmut p = &x;let q = p;
p = &y;
I'm inclined to think we should run with it for now, but we'll have to revisit this issue prior to stabilization.
As part of the nll-facts borrowck work, I added the idea of outlives relation that occur at all points. I did my best to explain it here:
https://github.com/rust-lang/rust/blob/0cd465087d800f6e1183ed3e8a71262039245902/src/librustc_mir/borrow_check/nll/type_check/mod.rs#L627-L657
I handled this by adding the relevant outlives relationships to all points. But, looking at the
outlives.facts
I saw that these relations account for a LOT of noise. Of the ~500K tuples in that file, about half are due to this. =) Moreover, these tuples will mess up any optimizations like #20. It's clear we need a better approach, but I'm not sure what.That said, manually removing those tuples and re-running the analysis shows that they only have a small effect on overall performance (from ~40s to ~35s).
The text was updated successfully, but these errors were encountered: