File: .lake/packages/lean4/src/lean/Lean/Elab/SyntheticMVars.lean

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.resumeElabTerm
code: /-- Auxiliary function used to implement `synthesizeSyntheticMVars`. -/
private def resumeElabTerm (stx : Syntax) (expectedType? : Option Expr) (errToSorry := true) : TermElabM Expr 
goal: Lean.Elab.TermElabM Lean.Expr

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.resumePostponed
code: /--
  Try to elaborate `stx` that was postponed by an elaboration method using `Expection.postpone`.
  It returns `true` if it succeeded, and `false` otherwise.
  It is used to implement `synthesizeSyntheticMVars`. -/
private def resumePostponed (savedContext : SavedContext) (stx : Syntax) (mvarId : MVarId) (postponeOnError : Bool) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizePendingInstMVar
code: /--
  Similar to `synthesizeInstMVarCore`, but makes sure that `instMVar` local context and instances
  are used. It also logs any error message produced. -/
private def synthesizePendingInstMVar (instMVar : MVarId) (extraErrorMsg? : Option MessageData := none): TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizePendingInstMVar'
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizePending
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizeUsingInstances
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM (List Lean.MVarId)

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizeUsingDefault
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizeUsingDefaultInstance
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizeSomeUsingDefault?
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM (Option (List Lean.MVarId))

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultPrio.synthesizeUsingInstancesStep
code: /--
  Try to synthesize `mvarId` by starting using a default instance with the give privority.
  This method succeeds only if the metavariable of fully synthesized.

  Remark: In the past, we would return a list of pending TC problems, but this was problematic since
  a default instance may create subproblems that cannot be solved.

  Remark: The new approach also has limitations because other pending metavariables are not taken into account
  while backtraking. That is, we fail to synthesize `mvarId` because we reach subproblems that are stuck,
  but we could "unstuck" them if we tried to solve other pending metavariables. Considering all pending metavariables
  into a single backtracking search seems to be too expensive, and potentially generate incomprehensible error messages.
  This is particularly true if we consider pending metavariables for "postponed" elaboration steps.
  Here is an example that demonstrate this issue. The example considers we are using the old `binrel%` elaborator which was
  disconnected from `binop%`.
  ```
  example (a : Int) (b c : Nat) : a = ↑b - ↑c := sorry
  ```
  We have two pending coercions for the `↑` and `HSub ?m.220 ?m.221 ?m.222`.
  When we did not use a backtracking search here, then the homogenous default instance for `HSub`.
  ```
  instance [Sub α] : HSub α α α where
  ```
  would be applied first, and would propagate the expected type `Int` to the pending coercions which would now be unblocked.

  Instead of performing a backtracking search that considers all pending metavariables, we improved the `binrel%` elaborator.
-/
private partial def synthesizeUsingDefaultPrio (mvarId : MVarId) (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM (List Lean.MVarId)

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeSomeUsingDefaultPrio
code: /-- Used to implement `synthesizeUsingDefault`. This method only consider default instances with the given priority. -/
private def synthesizeSomeUsingDefaultPrio (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeSomeUsingDefaultPrio.visit
code: /-- Used to implement `synthesizeUsingDefault`. This method only consider default instances with the given priority. -/
private def synthesizeSomeUsingDefaultPrio (prio : Nat) : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefault
code: /--
  Apply default value to any pending synthetic metavariable of kind `SyntheticMVarKind.withDefault`
  Return true if something was synthesized. -/
private def synthesizeUsingDefault : TermElabM Bool 
goal: Lean.Elab.TermElabM Bool

full_name: Lean.Elab.Term.reportStuckSyntheticMVar
code: /--
We use this method to report typeclass (and coercion) resolution problems that are "stuck".
That is, there is nothing else to do, and we don't have enough information to synthesize them using TC resolution.
-/
def reportStuckSyntheticMVar (mvarId : MVarId) (ignoreStuckTC := false) : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.reportStuckSyntheticMVars
code: /--
  Report an error for each synthetic metavariable that could not be resolved.
  Remark: we set `ignoreStuckTC := true` when elaborating `simp` arguments.
-/
private def reportStuckSyntheticMVars (ignoreStuckTC := false) : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.getSomeSyntheticMVarsRef
code: private def getSomeSyntheticMVarsRef : TermElabM Syntax 
goal: Lean.Elab.TermElabM Lean.Syntax

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.throwStuckAtUniverseCnstr
code: /--
  Generate an nicer error message for stuck universe constraints.
-/
private def throwStuckAtUniverseCnstr : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.processPostponedUniverseContraints
code: /--
  Try to solve postponed universe constraints, and throws an exception if there are stuck constraints.

  Remark: in previous versions, each `isDefEq u v` invocation would fail if there
  were pending universe level constraints. With this old approach, we were not able
  to process
  ```
  Functor.map Prod.fst (x s)
  ```
  because after elaborating `Prod.fst` and trying to ensure its type
  match the expected one, we would be stuck at the universe constraint:
  ```
  u =?= max u ?v
  ```
  Another benefit of using `withoutPostponingUniverseConstraints` is better error messages. Instead
  of getting a mysterious type mismatch constraint, we get a list of
  universe constraints the system is stuck at.
-/
private def processPostponedUniverseContraints : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.markAsResolved
code: /--
  Remove `mvarId` from the `syntheticMVars` table. We use this method after
  the metavariable has been synthesized.
-/
private def markAsResolved (mvarId : MVarId) : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: Lean.Elab.Term.PostponeBehavior
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Type

full_name: Lean.Elab.Term.PostponeBehavior.yes
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.instReprPostponeBehavior
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Repr Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.instInhabitedPostponeBehavior
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Inhabited Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.PostponeBehavior.partial
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.PostponeBehavior.no
code: /--
Auxiliary type for `synthesizeSyntheticMVars`. It specifies
whether pending synthetic metavariables can be postponed or not.
-/
inductive PostponeBehavior where
  /--
  Any kind of pending synthetic metavariable can be postponed.
  Universe constrains may also be postponed.
  -/
  | yes
  /--
  Pending synthetic metavariables cannot be postponed.
  -/
  | no
  /--
  Synthectic metavariables associated with type class resolution can be postponed.
  Motivation: this kind of metavariable are not synthethic opaque, and can be assigned by `isDefEq`.
  Unviverse constraints can also be postponed.
  -/
  | «partial»
  deriving Inhabited, Repr, BEq
goal: Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.instBEqPostponeBehavior
code: BEq
goal: BEq Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.PostponeBehavior.ofBool
code: def PostponeBehavior.ofBool : Bool → PostponeBehavior
  
goal: Bool → Lean.Elab.Term.PostponeBehavior

full_name: Lean.Elab.Term.synthesizeSyntheticMVarsNoPostponing
code: def synthesizeSyntheticMVarsNoPostponing (ignoreStuckTC := false) : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.synthesizeUsingDefaultLoop
code: /-- Keep invoking `synthesizeUsingDefault` until it returns false. -/
private partial def synthesizeUsingDefaultLoop : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: Lean.Elab.Term.synthesizeSyntheticMVarsUsingDefault
code: def synthesizeSyntheticMVarsUsingDefault : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.withSynthesizeImp
code: private partial def withSynthesizeImp (k : TermElabM α) (postpone : PostponeBehavior) : TermElabM α 
goal: Lean.Elab.TermElabM α

full_name: Lean.Elab.Term.withSynthesize
code: /--
  Execute `k`, and synthesize pending synthetic metavariables created while executing `k` are solved.
  If `mayPostpone == false`, then all of them must be synthesized.
  Remark: even if `mayPostpone == true`, the method still uses `synthesizeUsingDefault` -/
@[inline] def withSynthesize [MonadFunctorT TermElabM m] (k : m α) (postpone := PostponeBehavior.no) : m α 
goal: m α

full_name: _private.«.lake».packages.lean4.src.lean.Lean.Elab.SyntheticMVars.0.Lean.Elab.Term.withSynthesizeLightImp
code: private partial def withSynthesizeLightImp (k : TermElabM α) : TermElabM α 
goal: Lean.Elab.TermElabM α

full_name: Lean.Elab.Term.withSynthesizeLight
code: /-- Similar to `withSynthesize`, but uses `postpone := .true`, does not use use `synthesizeUsingDefault` -/
@[inline] def withSynthesizeLight [MonadFunctorT TermElabM m] (k : m α) : m α 
goal: m α

full_name: Lean.Elab.Term.elabTermAndSynthesize
code: /-- Elaborate `stx`, and make sure all pending synthetic metavariables created while elaborating `stx` are solved. -/
def elabTermAndSynthesize (stx : Syntax) (expectedType? : Option Expr) : TermElabM Expr 
goal: Lean.Elab.TermElabM Lean.Expr

full_name: Lean.Elab.Term.runPendingTacticsAt
code: /--
Collect unassigned metavariables at `e` that have associated tactic blocks, and then execute them using `runTactic`.
We use this method at the `match .. with` elaborator when it cannot be postponed anymore, but it is still waiting
the result of a tactic block.
-/
def runPendingTacticsAt (e : Expr) : TermElabM Unit 
goal: Lean.Elab.TermElabM Unit

full_name: Lean.Elab.Term.initFn._@..lake.packages.lean4.src.lean.Lean.Elab.SyntheticMVars._hyg.6691
code: builtin_initialize
  registerTraceClass `Elab.resume
goal: IO Unit