# How Sway Handles Method Lookup and Trait Resolution: A Deep Dive into the Compiler Core > Explore how Sway handles method lookup and trait resolution. Understand Sway's compiler pipeline for efficient candidate filtering and final selection. - Repository: [Fuel Labs/sway](https://github.com/FuelLabs/sway) - Tags: deep-dive - Published: 2026-03-04 --- **Sway resolves method calls through a multi-stage pipeline that parses calls into a `MethodName` enum, type-checks arguments via `resolve_method_name`, and uses the `MethodLookup` engine to filter candidates by signature, trait bounds, and visibility before monomorphizing the final selection.** The FuelLabs/sway compiler implements a sophisticated resolution algorithm to dispatch method calls in a statically typed blockchain development environment. Understanding how Sway handles method lookup and trait resolution is essential for debugging complex generic code and optimizing smart contract compilation. This article traces the exact path from a syntactic method call to the final monomorphized function selection, referencing the actual source implementation in the `sway-core` crate. ## The Four Faces of Method Calls: Parsing into `MethodName` When the Sway parser encounters a method call, it classifies the syntax into one of four variants of the `MethodName` enum defined in [`sway-core/src/language/parsed/expression/method_name.rs`](https://github.com/FuelLabs/sway/blob/main/sway-core/src/language/parsed/expression/method_name.rs). This classification determines how the compiler will later resolve the receiver type and locate the implementation. The four variants are: - **`FromType`** – A type appears explicitly in the path, such as `a::b::C::d()`. - **`FromModule`** – No type appears in the path; the first argument determines the type, as in `obj.method()`. - **`FromTrait`** – The path points to a trait directly, such as `Trait::method(a)`. - **`FromQualifiedPathRoot`** – Fully-qualified syntax like `::method()`. ```rust // sway-core/src/language/parsed/expression/method_name.rs pub enum MethodName { FromType { call_path_binding: TypeBinding>, method_name: Ident }, FromModule { method_name: Ident }, FromTrait { call_path: CallPath }, FromQualifiedPathRoot { ty: GenericArgument, as_trait: TypeId, method_name: Ident }, } ``` ## From Syntax to Semantics: The Type-Checking Pipeline After parsing, the semantic analysis phase begins in [`sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs`](https://github.com/FuelLabs/sway/blob/main/sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs). The function `type_check_method_application` first type-checks each argument, then invokes `resolve_method_name` to map the `MethodName` variant and argument types to a concrete function declaration. ```rust // sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs let method_result = resolve_method_name( handler, ctx.by_ref(), &method_name_binding, &arguments_types, ); ``` ### Resolving the Receiver Type The `resolve_method_name` function extracts three critical pieces of information: the **type ID** of the receiver, the **module path**, and the **method identifier**. The extraction logic varies by `MethodName` variant: | Variant | Receiver Type Source | Module Path Source | |---------|---------------------|-------------------| | `FromType` | Resolved from `call_path_binding.type_check_with_type_info` | Derived from type's definition module | | `FromTrait` | First argument type (or placeholder) | Trait-relative import rules | | `FromModule` | First argument type | Current module | | `FromQualifiedPathRoot` | `ty` generic argument | Current module | With these components extracted, `resolve_method_name` delegates to `find_method_for_type` in the `MethodLookup` engine. ## The Core Resolution Engine: `find_method_for_type` Located in [`sway-core/src/semantic_analysis/method_lookup.rs`](https://github.com/FuelLabs/sway/blob/main/sway-core/src/semantic_analysis/method_lookup.rs), `find_method_for_type` serves as the heart of **trait resolution**. This function orchestrates a multi-step filtering process to select the unique method implementation from potentially ambiguous candidates. ### Candidate Collection and Numeric Defaulting The engine first applies **numeric defaulting** via `default_numeric_if_needed`. If the method call targets a numeric literal without explicit type annotation, Sway may coerce the type to `u64` or `i64` to match available implementations. Next, `collect_candidate_items` gathers all possible method sources: - Direct methods defined in `impl` blocks for the concrete type - Trait methods where the type implements the trait - Free functions in the type's module that match the method name ### Signature Matching and Trait Bound Filtering The `filter_method_candidates_by_signature` function eliminates candidates whose parameter or return types are incompatible with the call site's argument types. This includes checking type coercibility and exact matches. For generic type parameters, **trait constraint extraction** becomes critical. The `trait_constraints_from_method_name` function parses bounds like `T: SomeTrait` from the method name context. Then `filter_items_by_trait_access` removes any candidate whose trait does not satisfy these constraints. ### Disambiguation and Preference Rules After filtering, `group_by_trait_impl` clusters remaining candidates by their originating implementation block. The engine then applies **preference rules** via `prefer_non_blanket_impls`, giving priority to concrete implementations over blanket impls (those applying to generic type parameters like `impl Trait for T`). Finally, `select_method_from_grouped` attempts to pick the unique method. If multiple candidates remain, it emits a `MultipleApplicableItemsInScope` error. If none match, it returns `MethodNotFound` with a formatted signature and candidate list. ```rust // sway-core/src/semantic_analysis/method_lookup.rs pub(crate) fn find_method_for_type( &self, handler: &Handler, type_id: TypeId, method_prefix: &ModulePath, method_ident: &Ident, annotation_type: TypeId, arguments_types: &[TypeId], method_name: Option<&MethodName>, ) -> Result { self.default_numeric_if_needed(handler, type_id, method_ident)?; let matching_items = self.collect_candidate_items(...)?; let matching_method_decl_refs = self.items_to_method_refs(matching_items); let candidates = self.filter_method_candidates_by_signature(...); // Grouping, trait-bound handling, and selection... if let Some(pick) = self.select_method_from_grouped(...)? { return Ok(pick.get_method_safe_to_unify(...)); } // Error handling... } ``` ## Monomorphizing the Selected Method Once `find_method_for_type` returns a `DeclRefFunction`, the compiler must instantiate any generic parameters. The `monomorphize_method` function in [`method_application.rs`](https://github.com/FuelLabs/sway/blob/main/method_application.rs) resolves generic type arguments and const generics, applying the concrete types derived from the call site to produce the final executable function reference. ```rust // sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs let mut fn_ref = monomorphize_method( handler, ctx.by_ref(), original_decl_ref.clone(), method_name_binding.type_arguments.to_vec_mut(), const_generics, )?; ``` ## Summary - **Sway** classifies every method call into one of four `MethodName` variants during parsing, determining how the receiver type is identified. - **Type-checking** occurs in `type_check_method_application`, which delegates to `resolve_method_name` to extract the concrete type and method identifier. - **Resolution** happens in `find_method_for_type`, which collects candidates from impl blocks and traits, filters by signature and trait bounds, and applies preference rules to select the unique implementation. - **Monomorphization** instantiates generic parameters after selection, producing the final concrete function reference ready for code generation. ## Frequently Asked Questions ### How does Sway resolve ambiguous method calls when multiple traits define the same method? When multiple applicable candidates remain after signature filtering, Sway's `select_method_from_grouped` function emits a `MultipleApplicableItemsInScope` error. The compiler does not arbitrarily pick one implementation; instead, it requires explicit disambiguation using fully-qualified syntax like `::method()` to specify exactly which trait implementation to use. ### What is the difference between `FromModule` and `FromTrait` in Sway's method lookup? **`FromModule`** handles method calls where the method name appears without a type prefix, such as `obj.method()`. The compiler determines the receiver type from the first argument (`obj`) and searches the current module's impl blocks. **`FromTrait`** handles calls that explicitly reference a trait, such as `Trait::method(arg)`. Here, the compiler looks up the trait directly and resolves the implementation based on the argument type, following trait-relative import rules rather than module-local impl blocks. ### How does Sway handle trait bounds during method resolution for generic functions? When resolving a method call on a generic type parameter like `fn echo(val: T) { val.to_str() }`, Sway extracts the trait constraints using `trait_constraints_from_method_name`. This function identifies that `T` must implement `ToString`. Then, `filter_items_by_trait_access` eliminates any method candidates that do not satisfy these constraints, ensuring only valid trait implementations are considered during the final selection phase. ### Why does Sway need to monomorphize methods after lookup completes? Monomorphization converts the selected generic function declaration into a concrete implementation specific to the call site's types. After `find_method_for_type` identifies the correct method—potentially defined with generic parameters like `fn add(a: T, b: T) -> T`—the `monomorphize_method` function substitutes the concrete types (e.g., `u64`) and const generics. This process produces the final `DeclRefFunction` ready for code generation, eliminating runtime dispatch overhead in the compiled FuelVM bytecode.