distinguish recursion limit based overflow for diagnostics
also change the number of allowed fixpoint steps to be fixed instead of using the `log` of the total recursion depth.
This commit is contained in:
parent
d3d145ea1c
commit
5ec9b8d778
25 changed files with 91 additions and 125 deletions
|
@ -42,6 +42,17 @@ pub use fulfill::FulfillmentCtxt;
|
|||
pub(crate) use normalize::deeply_normalize_for_diagnostics;
|
||||
pub use normalize::{deeply_normalize, deeply_normalize_with_skipped_universes};
|
||||
|
||||
/// How many fixpoint iterations we should attempt inside of the solver before bailing
|
||||
/// with overflow.
|
||||
///
|
||||
/// We previously used `tcx.recursion_limit().0.checked_ilog2().unwrap_or(0)` for this.
|
||||
/// However, it feels unlikely that uncreasing the recursion limit by a power of two
|
||||
/// to get one more itereation is every useful or desirable. We now instead used a constant
|
||||
/// here. If there ever ends up some use-cases where a bigger number of fixpoint iterations
|
||||
/// is required, we can add a new attribute for that or revert this to be dependant on the
|
||||
/// recursion limit again. However, this feels very unlikely.
|
||||
const FIXPOINT_STEP_LIMIT: usize = 8;
|
||||
|
||||
#[derive(Debug, Clone, Copy)]
|
||||
enum SolverMode {
|
||||
/// Ordinary trait solving, using everywhere except for coherence.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue