This PR fixes an issue where method lints (particularly unwrap_or_default) were not respecting per-item MSRV attributes. The fix ensures that when a function or module is annotated with #[clippy::msrv = "1.15"], method lints will properly respect that MSRV version.

Previously, method lints like `unwrap_or_default` would suggest using `unwrap_or_default()` even when the MSRV was set below 1.16 (when this method was stabilized). This happened because the `extract_msrv_attr!` macro was not being used in the `Methods` lint pass, so per-item MSRV attributes were not being respected.

Added `extract_msrv_attr!();` to the `check_expr` method in the `Methods` lint pass implementation. This ensures that all method lints properly extract and respect per-item MSRV attributes.

Added a new test case in `tests/ui/msrv_unwrap_or_default.rs` that verifies:
- A function annotated with `#[clippy::msrv = "1.15"]` using `unwrap_or(vec![])` does not trigger the `unwrap_or_default` lint
- The test passes with only the expected unused variable warning

This change affects all method lints that check for MSRV-dependent features. The fix ensures that these lints properly respect per-item MSRV attributes, making them more accurate and useful for codebases that need to maintain compatibility with older Rust versions.

Fixes #[issue number] (if there is an open issue for this)

- [x] Added test case
- [x] Test passes
- [x] No regression in other lints
- [x] Documentation is up to date

Author: poglesbyg

.cursor/rules/data-flow-patterns.mdc

@@ -0,0 +1,50 @@
+---
+description: Documents data flow patterns for static analysis and linting rules in Rust code.
+globs: **/src/**/*.rs,**/clippy_lints/**/*.rs,**/clippy_config/**/*.rs
+alwaysApply: false
+---
+
+
+# data-flow-patterns
+
+The data flow in this linting system follows these core patterns:
+
+1. Lint Registration Flow
+- Lints are registered through `RegistrationGroups` in lib.rs
+- Groups are organized by category (Correctness, Style, Complexity, etc.)
+- Each lint registration contains metadata like name, description, level
+- Registration maps to specific analysis implementations
+
+2. Lint Analysis Flow
+- Source code is parsed into AST/MIR representations
+- Lint implementations analyze specific patterns in the code
+- Results are collected into a centralized reporting system
+- Early vs Late pass analysis controls when lints are applied
+
+3. Configuration Processing Flow
+- Configuration is loaded from clippy.toml and environment
+- Rules are validated and normalized through conf.rs
+- Configuration flows to individual lint implementations
+- Default configurations are merged with user overrides
+
+4. Data Model Validation Flow 
+- Type-based validation rules check compatibility
+- Memory safety requirements are enforced through ownership analysis
+- Reference validity is tracked across code paths
+- Custom type constraints are applied based on lint requirements
+
+5. Suggestion Generation Flow
+- Issues detected by lints generate suggestion spans
+- Suggestions include code replacements and rationale
+- Multiple suggestions may be generated per issue
+- Suggestions preserve original code formatting
+
+Key Files:
+- clippy_lints/src/lib.rs - Core registration system
+- clippy_config/src/conf.rs - Configuration processing
+- clippy_lints/src/declared_lints.rs - Lint definitions
+- clippy_lints/src/non_copy_const.rs - Data validation
+
+The system implements an extensible pipeline for static code analysis with strict separation between registration, analysis, and reporting phases.
+
+$END$

.cursor/rules/lint-analysis-algorithms.mdc

@@ -0,0 +1,50 @@
+---
+description: Specification for analyzing and documenting lint algorithms, rules and validations in Rust static analysis tools
+globs: src/clippy_lints/**/*.rs,src/**/lint*.rs,src/**/rules/**/*.rs,src/**/check*.rs
+alwaysApply: false
+---
+
+
+# lint-analysis-algorithms
+
+The core business logic encompasses specialized static analysis algorithms for detecting code patterns and enforcing domain rules in Rust. Key components include:
+
+1. Pattern Matching Analysis
+- AST traversal for identifying specific code structures requiring linting
+- Type analysis and validation during pattern matching 
+- Context tracking for multi-block pattern validation
+- Template matching against known anti-patterns
+
+2. Reference Safety Rules
+- Borrow checker augmentation for reference analysis 
+- Lifetime validation for borrowed values
+- Mutable reference access pattern checking
+- Reference scoping and drop timing validation
+
+3. Type System Integration
+- Layout compatibility verification for transmutes
+- Generic parameter substitution tracking
+- Trait bound satisfaction checking
+- Zero-sized type special case handling
+
+4. Domain Rule Enforcement
+- Documentation style and completeness validation
+- API visibility and access pattern checks
+- Naming convention verification
+- Resource safety guarantees
+
+5. Suggestion Generation
+- Context-aware code transformation suggestions
+- Macro expansion preservation in suggestions
+- Comment and attribute retention during fixes
+- Edition-specific code recommendations
+
+The algorithms focus on static verification of Rust-specific safety requirements and coding conventions, with extensive customization points for project-specific rules.
+
+Core file paths:
+- clippy_lints/src/methods/*.rs
+- clippy_lints/src/types/*.rs 
+- clippy_lints/src/matches/*.rs
+- clippy_lints/src/attrs/*.rs
+
+$END$

.cursor/rules/lint-data-model.mdc

@@ -0,0 +1,43 @@
+---
+description: Core lint metadata models and data structures used for evaluating and tracking lint rules and their relationships with Rust's type system
+globs: clippy_lints/src/**.rs,clippy_config/src/**.rs
+alwaysApply: false
+---
+
+
+# lint-data-model
+
+## Core Lint State Model
+- Tracks lint metadata including name, description, level (deny/warn/allow)
+- Maintains contextual relationships between lints and their diagnostics
+- Special handling for edition-specific lint configurations
+- Enforces lint deprecation policies through staged transitions
+
+## Lint Category Hierarchies
+- Implements layered categorization for lints:
+  - Style (code formatting/convention violations)  
+  - Correctness (potential runtime errors)
+  - Complexity (code structure issues)
+  - Performance (inefficient patterns)
+  - Restriction (banned patterns/code constructs)
+  - Pedantic (best practice violations)
+  - Nursery (new/unstable lints)
+
+## Configuration Management  
+- Handles configuration hierarchies and inheritance
+- Implements context-aware configuration application based on file paths
+- Manages per-crate and per-module lint configurations
+- Supports nested configuration overrides with precedence rules
+
+## Diagnostic Relationship Model
+- Maps lints to compiler diagnostic codes
+- Tracks diagnostic severities and suggested fixes
+- Manages related diagnostic notes and explanations
+- Handles diagnostic suppression chains
+
+Key Files:
+- clippy_config/src/conf.rs
+- clippy_lints/src/lib.rs 
+- clippy_lints/src/declared_lints.rs
+
+$END$

.cursor/rules/type-validation-system.mdc

@@ -0,0 +1,53 @@
+---
+description: Specification for the type validation and safety system used in Clippy linting rules and checks.
+globs: clippy_lints/**/*.rs,clippy_config/**/*.rs
+alwaysApply: false
+---
+
+
+# type-validation-system
+
+The type validation system comprises several key components implementing specialized safety and validation rules:
+
+1. Cast Safety Validation:
+- Validates numeric type conversions for potential data loss
+- Enforces pointer safety rules during casting operations 
+- Contains domain rules for casting between collection types
+- Handles specialized validation for floating point casts
+
+2. Reference Type Safety:
+- Validates proper handling of references vs raw pointers
+- Implements borrowing pattern detection and safety rules
+- Contains custom validation for self-referential structs
+- Handles complex lifetime relationship validation
+
+3. Collection Type Validation:
+- Enforces collection type safety policies
+- Validates element type compatibility in collections
+- Implements specialized slice operation safety
+- Contains custom validation for generic type parameters
+
+4. Specialized Domain Rules:
+- Custom validation for mutable reference patterns
+- Zero-sized type handling and validation 
+- Orphan implementation checking
+- Associated type relationship validation
+
+Key implementations:
+- clippy_lints/src/casts/*.rs: Core casting validation
+- clippy_lints/src/types/*.rs: Type relationship checking
+- clippy_lints/src/transmute/*.rs: Memory transmutation safety
+
+The system enforces domain-specific type safety policies through static analysis, focusing on:
+- Reference and pointer safety guarantees
+- Collection type compatibility 
+- Memory layout validation
+- Generic type parameter bounds
+
+Notable validations include:
+- Transmute operation safety
+- Zero-cost abstraction validation
+- Reference lifetime analysis
+- Collection element type compatibility
+
+$END$

.cursorrules

@@ -0,0 +1,64 @@
+
+START SPECIFICATION:
+---
+description: This overview should be applied when analyzing Clippy's linting system components, particularly focusing on custom business rules, lint implementations, and domain-specific code analysis patterns.
+globs: clippy_lints/src/**,clippy_config/src/**,clippy_dev/src/**
+alwaysApply: false
+---
+
+
+# main-overview
+
+## Development Guidelines
+
+- Only modify code directly relevant to the specific request. Avoid changing unrelated functionality.
+- Never replace code with placeholders like `# ... rest of the processing ...`. Always include complete code.
+- Break problems into smaller steps. Think through each step separately before implementing.
+- Always provide a complete PLAN with REASONING based on evidence from code and logs before making changes.
+- Explain your OBSERVATIONS clearly, then provide REASONING to identify the exact issue. Add console logs when needed to gather more information.
+
+
+Clippy implements a sophisticated static analysis system for Rust code through several key components:
+
+1. Configuration Management (clippy_config/src/conf.rs)
+- Enforces validation rules for linting configuration
+- Implements custom documentation processing with code block preservation
+- Controls field visibility and access patterns
+- Validates naming conventions with configurable exceptions
+
+2. Core Linting System (clippy_lints/src/lib.rs)
+- Organizes lints into functional categories (Correctness, Style, Complexity, etc.)
+- Implements two-phase lint checking:
+  - Early pass: Syntax-level validation
+  - Late pass: Semantic analysis
+- Manages centralized lint explanations and configuration metadata
+
+3. Code Pattern Analysis (clippy_lints/src/matches/mod.rs)
+- Detects redundant match patterns and suggests simplifications
+- Validates mutex safety in pattern matching
+- Enforces pattern matching exhaustiveness
+- Handles reference types and binding modes
+
+4. Memory Safety Validation (clippy_lints/src/transmute/)
+- Validates transmute operations between types
+- Enforces pointer safety and alignment rules
+- Detects invalid collection transmutes
+- Prevents unsafe pointer casts
+
+5. Documentation Enforcement (clippy_lints/src/doc/mod.rs)
+- Enforces structured documentation requirements:
+  - Safety sections for unsafe code
+  - Error documentation for Result types
+  - Panic documentation where relevant
+- Validates documentation formatting and structure
+
+The system is organized around a plugin architecture where individual lints implement specific business rules for code analysis. Each lint can provide custom suggestions for code improvement while maintaining semantic correctness.
+
+Key policy enforcement happens through:
+- Configuration validation (clippy_config)
+- Lint registration and management (clippy_lints/src/lib.rs)
+- Custom pattern analysis (clippy_lints/src/matches)
+- Safety rule enforcement (clippy_lints/src/transmute)
+
+$END$
+END SPECIFICATION

.giga/specifications.json

@@ -0,0 +1,22 @@
+[
+  {
+    "fileName": "main-overview.mdc",
+    "description": "Complete overview of Clippy's architecture, including the lint pass system, core components, and high-level workflow of lint processing"
+  },
+  {
+    "fileName": "lint-data-model.mdc",
+    "description": "Documentation of core lint data structures, including lint attributes, levels, categories, and their relationships with the Rust compiler's internal representations"
+  },
+  {
+    "fileName": "lint-analysis-algorithms.mdc",
+    "description": "Detailed documentation of key algorithms used in lint analysis, including pattern matching, AST traversal, and type checking implementations"
+  },
+  {
+    "fileName": "data-flow-patterns.mdc",
+    "description": "Documentation of how data flows through the lint system, including lint registration, application, and suggestion generation processes"
+  },
+  {
+    "fileName": "type-validation-system.mdc",
+    "description": "Detailed documentation of the type validation system, focusing on transmute checks, casting validations, and type safety enforcement algorithms"
+  }
+]

clippy_lints/src/methods/mod.rs

@@ -4412,7 +4412,7 @@ declare_clippy_lint! {
     /// Checks for calls to `Read::bytes` on types which don't implement `BufRead`.
     ///
     /// ### Why is this bad?
-    /// The default implementation calls `read` for each byte, which can be very inefficient for data that’s not in memory, such as `File`.
+    /// The default implementation calls `read` for each byte, which can be very inefficient for data that's not in memory, such as `File`.
     ///
     /// ### Example
     /// ```no_run
@@ -4724,6 +4724,7 @@ pub fn method_call<'tcx>(recv: &'tcx Expr<'tcx>) -> Option<(Symbol, &'tcx Expr<'
 
 impl<'tcx> LateLintPass<'tcx> for Methods {
     fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
+        extract_msrv_attr!();
         if expr.span.from_expansion() {
             return;
         }
@@ -4741,7 +4742,7 @@ impl<'tcx> LateLintPass<'tcx> for Methods {
             },
             ExprKind::MethodCall(method_call, receiver, args, _) => {
                 let method_span = method_call.ident.span;
-                or_fun_call::check(cx, expr, method_span, method_call.ident.name, receiver, args);
+                or_fun_call::check(cx, expr, method_span, method_call.ident.name, receiver, args, self.msrv);
                 expect_fun_call::check(
                     cx,
                     &self.format_args,