Your first Rust submission: pass the three checks

Return twice the input using i32 arithmetic. Keep this signature:

pub fn double(n: i32) -> i32

For example, 21 becomes 42, -3 becomes -6, and zero stays zero. The starter already computes these answers. Your task is to make it pass the style check too, by returning the final expression directly.

Three checks determine a successful submission

1. Your code compiles.
2. The result matches every test case, including hidden cases.
3. The Clippy check passes for your code, with warnings treated as errors.

Clippy runs separately from the executable tests. Passing the examples alone is not enough. A missing or unavailable Clippy check also does not count as a successful grade.

The starter ends with return n * 2;. Clippy flags this as needless_return. Rust uses a block's final expression as its value when that expression has no trailing semicolon. A function body is a block, so remove both return and the semicolon. Keep the public function name and parameter/return types.

A complete example of the same expression rule is:

fn add_one(n: i32) -> i32 {
    n + 1
}

fn main() {
    assert_eq!(add_one(4), 5);
}

return remains useful when a function needs to exit early. This lint is about an unnecessary final return, not a ban on the keyword.

What the runner compiles

The runner combines your source with a JSON helper and a problem-specific harness. Your source comes first so diagnostics attached to your lines can retain their editor line numbers. The harness supplies fn main(), reads test input, calls your function and reports the result. Do not add your own main function to this submission.

The current execution build uses Rust edition 2024 with optimization enabled, equivalent to rustc -O --edition 2024, plus output-path and diagnostic flags. It compiles a source file directly, without a Cargo project or external dependency resolution. Use the standard library for this exercise; adding an import does not install crates such as serde or tokio.

The Clippy pass uses clippy-driver -D warnings with metadata-only output. Enabled compiler warnings, such as an unused variable or unnecessary mut, can fail that check as well as Clippy lints. This does not enable every optional Clippy lint. Read the diagnostic and its suggestion before editing.

The runner filters lint diagnostics from injected code out of the learner's grade. Compilation can still fail at the harness boundary, for example when your function's name or type is wrong. In that case the runner can report a boundary error rather than expose the injected source.

Execution and saved code are different

Code executes through crackedai-connect on your computer or a linked runner you have configured. The website server does not execute submissions. This does not mean your code stays only on that machine: authenticated drafts and saved solutions are sent to and stored by the site, and linked runner jobs are relayed through it.

Arithmetic and tests use the runner's build settings

The input is an i32. Doubling values from -1073741824 through 1073741823 fits in i32. Outside that interval, the mathematical result overflows. With the runner's current optimized execution settings, this multiplication wraps in 32 bits: i32::MAX doubles to -2 and i32::MIN doubles to 0.

This is a property of the current build configuration, not a rule that all optimized Rust builds must wrap. Overflow checks and debug assertions are separate settings and can be overridden. A debug build with overflow checks enabled will panic on those overflowing multiplications.

The runner does not compile this file with --test. Ordinary #[test] functions are not its grading entry points, and #[cfg(test)] code is not enabled. The supplied harness runs the site's test cases instead.