Skip to content

Investigate why contracts don't use resolve_fn_path #4057

@carolynzech

Description

@carolynzech

parse_stubs uses resolve_fn_path to resolve the target of the stub:

fn parse_stubs(tcx: TyCtxt, harness: DefId, attributes: &[&Attribute]) -> Vec<Stub> {
let current_module = tcx.parent_module_from_def_id(harness.expect_local());
let check_resolve = |attr: &Attribute, path: &TypePath| {
let result = resolve_fn_path(tcx, current_module.to_local_def_id(), path);

while interpret_for_contract_attribute calls resolve_mod,

pub(crate) fn interpret_for_contract_attribute(&self) -> Option<(Symbol, DefId, Span)> {
self.expect_maybe_one(KaniAttributeKind::ProofForContract).and_then(|target| {
let name = expect_key_string_value(self.tcx.sess, target).ok()?;
self.resolve_from_mod(name.as_str())

which calls resolve_fn instead

fn resolve_from_mod(&self, path_str: &str) -> Result<DefId, ResolveError<'tcx>> {
resolve_fn(
self.tcx,
self.tcx.parent_module_from_def_id(self.item.expect_local()).to_local_def_id(),
path_str,
)

Investigate why this discrepancy exists and if alleviating it would let users write contracts for more kinds of functions. (See #4051 for context on this issue).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Z-ContractsIssue related to code contracts[E] User ExperienceAn UX enhancement for an existing feature. Including deprecation of an existing one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions