FuelLabs/sway

Consider making `CompileResult` members private.

Open

#2,475 opened on Aug 8, 2022

View on GitHub
 (0 comments) (1 reaction) (0 assignees)Rust (61,702 stars) (5,421 forks)batch import
P: mediumcode qualitycompiler: frontendenhancementgood first issueteam:compiler

Description

When reviewing #2472 I noticed it's possible to accidentally make an invalid CompileResult, where the author intended to return an 'ok' but set value to None.

We should make it mandatory to use CompileResult::ok() and CompileResult::err() to avoid this sort of thing. It would also required making a bunch of access methods for pulling the value or errors and/or warnings out which may turn out to be quite a pervasive change.

Contributor guide

Tech stack
rust
Domain
developer experience
Issue type
refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
RustUnderstanding of CompileResult
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Locate the definition of `CompileResult` in the Sway codebase, likely in a compiler crate. Make its fields private and add public accessor methods like `ok()`, `err()`, `value()`, `warnings()`, etc. Then update all existing usages across the codebase to use the new API. Refer to PR #2472 for context on the issue.