[{"data":1,"prerenderedAt":1739},["ShallowReactive",2],{"page-\u002Frust\u002F02-hello-world-and-cargo":3},{"id":4,"title":5,"body":6,"description":1693,"extension":1733,"meta":1734,"navigation":39,"path":1735,"seo":1736,"stem":1737,"__hash__":1738},"content\u002Frust\u002F02-hello-world-and-cargo.md","02 — Hello World & Cargo",{"type":7,"value":8,"toc":1692},"minimark",[9,13,139,230,316,388,480,561,649,751,852,915,988,1070,1168,1241,1306,1376,1467,1557,1631],[10,11,5],"h1",{"id":12},"_02-hello-world-cargo",[14,15,16,26,81],"question-wrapper",{},[17,18,20,21,25],"h3",{"id":19},"q1-what-does-cargo-new-my_app-create-by-default","Q1. What does ",[22,23,24],"code",{},"cargo new my_app"," create by default?",[27,28,31,46,59,72],"ul",{"className":29},[30],"contains-task-list",[32,33,36,41,42,45],"li",{"className":34},[35],"task-list-item",[37,38],"input",{"disabled":39,"type":40},true,"checkbox"," Only a ",[22,43,44],{},"Cargo.toml"," file with no source directory",[32,47,49,51,52,55,56,58],{"className":48},[35],[37,50],{"disabled":39,"type":40}," A ",[22,53,54],{},"src\u002Fmain.rs"," binary crate, a ",[22,57,44],{},", and a git repository (if not already inside one)",[32,60,62,51,64,67,68,71],{"className":61},[35],[37,63],{"disabled":39,"type":40},[22,65,66],{},"src\u002Flib.rs"," library crate and a ",[22,69,70],{},"Cargo.lock"," only",[32,73,75,77,78],{"className":74},[35],[37,76],{"disabled":39,"type":40}," An empty directory that must be populated manually with ",[22,79,80],{},"cargo init --full",[82,83,84,88,100],"details",{},[85,86,87],"summary",{},"Show Answer",[89,90,91,95,96,55,98,58],"p",{},[92,93,94],"strong",{},"Answer:"," B — A ",[22,97,54],{},[22,99,44],{},[89,101,102,105,106,109,110,112,113,116,117,119,120,123,124,127,128,131,132,135,136,138],{},[92,103,104],{},"Explanation:"," ",[22,107,108],{},"cargo new"," scaffolds a binary crate by default (",[22,111,54],{}," with a ",[22,114,115],{},"Hello, world!"," program), generates ",[22,118,44],{},", and also runs ",[22,121,122],{},"git init"," plus a ",[22,125,126],{},".gitignore"," unless one already exists in a parent directory or ",[22,129,130],{},"--vcs none"," is passed. Use ",[22,133,134],{},"cargo new --lib"," to get a ",[22,137,66],{}," library crate instead (C describes the wrong default).",[14,140,141,153,198],{},[17,142,144,145,148,149,152],{"id":143},"q2-what-is-the-key-functional-difference-between-cargo-build-and-cargo-check","Q2. What is the key functional difference between ",[22,146,147],{},"cargo build"," and ",[22,150,151],{},"cargo check","?",[27,154,156,167,178,189],{"className":155},[30],[32,157,159,105,161,163,164,166],{"className":158},[35],[37,160],{"disabled":39,"type":40},[22,162,151],{}," only validates ",[22,165,44],{}," syntax; it does not touch source files",[32,168,170,105,172,174,175,177],{"className":169},[35],[37,171],{"disabled":39,"type":40},[22,173,151],{}," runs the full borrow checker and type checker like ",[22,176,147],{},", but skips code generation\u002Flinking, making it much faster for catching compile errors",[32,179,181,105,183,185,186,188],{"className":180},[35],[37,182],{"disabled":39,"type":40},[22,184,147],{}," is faster because it skips borrow checking, which only ",[22,187,151],{}," performs",[32,190,192,194,195,197],{"className":191},[35],[37,193],{"disabled":39,"type":40}," They are functionally identical; ",[22,196,151],{}," is simply a deprecated alias",[82,199,200,202,211],{},[85,201,87],{},[89,203,204,206,207,174,209,177],{},[92,205,94],{}," B — ",[22,208,151],{},[22,210,147],{},[89,212,213,215,216,218,219,221,222,225,226,229],{},[92,214,104],{}," Both commands run the same front-end analysis (type checking, borrow checking, trait resolution), so ",[22,217,151],{}," catches the same compile errors as ",[22,220,147],{},". The difference is that ",[22,223,224],{},"check"," stops before LLVM codegen and linking, which are the most time-consuming stages, so it's dramatically faster for a tight edit-check loop. Option C inverts this — borrow checking is not something ",[22,227,228],{},"build"," skips.",[14,231,232,240,279],{},[17,233,235,236,148,238,152],{"id":234},"q3-what-is-the-correct-relationship-between-cargotoml-and-cargolock","Q3. What is the correct relationship between ",[22,237,44],{},[22,239,70],{},[27,241,243,254,265,271],{"className":242},[30],[32,244,246,105,248,250,251,253],{"className":245},[35],[37,247],{"disabled":39,"type":40},[22,249,44],{}," is auto-generated from ",[22,252,70],{}," on every build",[32,255,257,105,259,261,262,264],{"className":256},[35],[37,258],{"disabled":39,"type":40},[22,260,44],{}," declares dependency requirements (often with version ranges); ",[22,263,70],{}," records the exact resolved versions actually used, ensuring reproducible builds",[32,266,268,270],{"className":267},[35],[37,269],{"disabled":39,"type":40}," They serve the same purpose and either one alone is sufficient",[32,272,274,105,276,278],{"className":273},[35],[37,275],{"disabled":39,"type":40},[22,277,70],{}," is only created for library crates, never for binaries",[82,280,281,283,291],{},[85,282,87],{},[89,284,285,206,287,261,289,264],{},[92,286,94],{},[22,288,44],{},[22,290,70],{},[89,292,293,105,295,297,298,301,302,304,305,307,308,310,311,315],{},[92,294,104],{},[22,296,44],{}," is the human-edited manifest expressing acceptable version ranges (e.g. ",[22,299,300],{},"serde = \"1.0\"","); ",[22,303,70],{}," is generated\u002Fupdated by Cargo and pins the exact versions (and their transitive dependency graph) that were actually resolved, so a second ",[22,306,147],{}," on another machine reproduces the identical dependency tree rather than re-resolving to potentially newer semver-compatible versions. Both binaries and libraries get a ",[22,309,70],{}," when built, though it's typically only ",[312,313,314],"em",{},"committed to version control"," for binaries (option D is wrong on both the \"only libraries\" claim and the general practice).",[14,317,318,322,358],{},[17,319,321],{"id":320},"q4-what-command-compiles-and-immediately-runs-a-binary-crate-in-one-step-during-development","Q4. What command compiles and immediately runs a binary crate in one step during development?",[27,323,325,334,342,350],{"className":324},[30],[32,326,328,105,330,333],{"className":327},[35],[37,329],{"disabled":39,"type":40},[22,331,332],{},"cargo build && .\u002Ftarget\u002Fdebug\u002Fapp"," is the only way; there is no shortcut",[32,335,337,105,339],{"className":336},[35],[37,338],{"disabled":39,"type":40},[22,340,341],{},"cargo run",[32,343,345,105,347],{"className":344},[35],[37,346],{"disabled":39,"type":40},[22,348,349],{},"cargo exec",[32,351,353,105,355],{"className":352},[35],[37,354],{"disabled":39,"type":40},[22,356,357],{},"cargo start",[82,359,360,362,368],{},[85,361,87],{},[89,363,364,206,366],{},[92,365,94],{},[22,367,341],{},[89,369,370,105,372,374,375,378,379,148,381,383,384,387],{},[92,371,104],{},[22,373,341],{}," builds the binary (if needed — it skips rebuilding when nothing changed) and then executes it, forwarding any arguments after ",[22,376,377],{},"--",". ",[22,380,349],{},[22,382,357],{}," (C, D) are not real Cargo subcommands — plausible-sounding distractors modeled after other ecosystems' tooling (e.g. ",[22,385,386],{},"npm start",").",[14,389,390,405,457],{},[17,391,393,394,396,397,400,401,404],{"id":392},"q5-a-repository-has-a-root-cargotoml-containing-a-workspace-table-with-members-core-cli-what-does-this-achieve","Q5. A repository has a root ",[22,395,44],{}," containing a ",[22,398,399],{},"[workspace]"," table with ",[22,402,403],{},"members = [\"core\", \"cli\"]",". What does this achieve?",[27,406,408,421,436,446],{"className":407},[30],[32,409,411,413,414,148,417,420],{"className":410},[35],[37,412],{"disabled":39,"type":40}," It merges ",[22,415,416],{},"core",[22,418,419],{},"cli"," into a single crate at build time",[32,422,424,426,427,148,429,432,433,435],{"className":423},[35],[37,425],{"disabled":39,"type":40}," It groups multiple crates so they share a single ",[22,428,70],{},[22,430,431],{},"target\u002F"," directory, and can be built\u002Ftested together with one ",[22,434,147],{}," from the workspace root",[32,437,439,441,442,445],{"className":438},[35],[37,440],{"disabled":39,"type":40}," It has no build effect; ",[22,443,444],{},"members"," is purely documentation",[32,447,449,451,452,148,454,456],{"className":448},[35],[37,450],{"disabled":39,"type":40}," It forces ",[22,453,416],{},[22,455,419],{}," to be published together as one package to crates.io",[82,458,459,461,472],{},[85,460,87],{},[89,462,463,465,466,148,468,432,470,435],{},[92,464,94],{}," B — It groups multiple crates so they share a single ",[22,467,70],{},[22,469,431],{},[22,471,147],{},[89,473,474,476,477,479],{},[92,475,104],{}," A Cargo workspace lets related crates share dependency resolution (one ",[22,478,70],{},") and a build output directory, avoiding duplicate compilation of shared dependencies across crates. Each member remains its own independently publishable crate (contradicting D) — the workspace is an organizational\u002Fbuild-sharing construct, not a merge (contradicting A).",[14,481,482,489,524],{},[17,483,485,486,488],{"id":484},"q6-where-does-cargo-build-default-profile-place-the-compiled-binary","Q6. Where does ",[22,487,147],{}," (default profile) place the compiled binary?",[27,490,492,500,508,516],{"className":491},[30],[32,493,495,105,497],{"className":494},[35],[37,496],{"disabled":39,"type":40},[22,498,499],{},".\u002Fbin\u002F",[32,501,503,105,505],{"className":502},[35],[37,504],{"disabled":39,"type":40},[22,506,507],{},".\u002Ftarget\u002Fdebug\u002F",[32,509,511,105,513],{"className":510},[35],[37,512],{"disabled":39,"type":40},[22,514,515],{},".\u002Ftarget\u002Frelease\u002F",[32,517,519,521,522],{"className":518},[35],[37,520],{"disabled":39,"type":40}," Directly in the project root alongside ",[22,523,44],{},[82,525,526,528,534],{},[85,527,87],{},[89,529,530,206,532],{},[92,531,94],{},[22,533,507],{},[89,535,536,538,539,541,542,545,546,549,550,553,554,557,558,560],{},[92,537,104],{}," The default ",[22,540,147],{}," uses the ",[22,543,544],{},"dev"," profile, which outputs to ",[22,547,548],{},"target\u002Fdebug\u002F",". Only ",[22,551,552],{},"cargo build --release"," outputs to ",[22,555,556],{},"target\u002Frelease\u002F"," (C is the release path, a common mix-up). Cargo never places build artifacts in the project root (D) — ",[22,559,431],{}," is the dedicated, gitignored build directory.",[14,562,563,573,606],{},[17,564,566,567,570,571,152],{"id":565},"q7-what-is-the-purpose-of-the-dependencies-section-in-cargotoml","Q7. What is the purpose of the ",[22,568,569],{},"[dependencies]"," section in ",[22,572,44],{},[27,574,576,588,594,600],{"className":575},[30],[32,577,579,581,582,148,585],{"className":578},[35],[37,580],{"disabled":39,"type":40}," It lists development-only tools like ",[22,583,584],{},"rustfmt",[22,586,587],{},"clippy",[32,589,591,593],{"className":590},[35],[37,592],{"disabled":39,"type":40}," It declares external crates the package needs at compile\u002Fruntime, with version requirements",[32,595,597,599],{"className":596},[35],[37,598],{"disabled":39,"type":40}," It lists the Rust toolchain version required to build the project",[32,601,603,605],{"className":602},[35],[37,604],{"disabled":39,"type":40}," It configures which target platforms the binary can run on",[82,607,608,610,615],{},[85,609,87],{},[89,611,612,614],{},[92,613,94],{}," B — It declares external crates the package needs at compile\u002Fruntime, with version requirements",[89,616,617,105,619,621,622,625,626,629,630,633,634,637,638,641,642,645,646,648],{},[92,618,104],{},[22,620,569],{}," is where crates like ",[22,623,624],{},"serde"," or ",[22,627,628],{},"tokio"," are declared with semver-style version requirements that Cargo resolves against crates.io (or another registry\u002Fpath\u002Fgit source). Dev-only tooling dependencies belong in ",[22,631,632],{},"[dev-dependencies]"," (A describes a different section), toolchain version pinning belongs in ",[22,635,636],{},"rust-toolchain.toml"," (C), and target platforms are handled via ",[22,639,640],{},"--target"," flags or ",[22,643,644],{},"[target.'cfg(...)']"," sections, not ",[22,647,569],{}," (D).",[14,650,651,665,719],{},[17,652,654,655,657,658,660,661,664],{"id":653},"q8-a-developer-deletes-cargolock-from-a-binary-project-and-runs-cargo-build-the-project-depends-on-rand-08-what-happens","Q8. A developer deletes ",[22,656,70],{}," from a binary project and runs ",[22,659,147],{},". The project depends on ",[22,662,663],{},"rand = \"0.8\"",". What happens?",[27,666,668,679,689,709],{"className":667},[30],[32,669,671,105,673,675,676,678],{"className":670},[35],[37,672],{"disabled":39,"type":40},[22,674,147],{}," fails immediately because ",[22,677,70],{}," is required to exist",[32,680,682,684,685,688],{"className":681},[35],[37,683],{"disabled":39,"type":40}," Cargo silently reuses cached resolution from ",[22,686,687],{},"~\u002F.cargo"," with no re-resolution",[32,690,692,694,695,697,698,700,701,704,705,708],{"className":691},[35],[37,693],{"disabled":39,"type":40}," Cargo re-resolves dependency versions from scratch (honoring the semver ranges in ",[22,696,44],{},") and regenerates a new ",[22,699,70],{},", which may pick up newer compatible versions than before (e.g. ",[22,702,703],{},"0.8.5"," instead of a previously pinned ",[22,706,707],{},"0.8.3",")",[32,710,712,714,715,718],{"className":711},[35],[37,713],{"disabled":39,"type":40}," The build always fails because ",[22,716,717],{},"rand","'s exact version can no longer be determined",[82,720,721,723,733],{},[85,722,87],{},[89,724,725,727,728,697,730,732],{},[92,726,94],{}," C — Cargo re-resolves dependency versions from scratch (honoring the semver ranges in ",[22,729,44],{},[22,731,70],{},", which may pick up newer compatible versions than before",[89,734,735,105,737,739,740,742,743,746,747,750],{},[92,736,104],{},[22,738,70],{}," is not required for the build to succeed — Cargo can always regenerate it by resolving ",[22,741,44],{},"'s version requirements against the registry. ",[92,744,745],{},"Debug:"," this is exactly why deleting a committed lock file for a ",[312,748,749],{},"binary"," project is risky in production contexts — a newer semver-compatible dependency version could introduce a regression or subtle behavior change that wasn't present when the lock was last committed, even though no application code changed.",[14,752,753,764,813],{},[17,754,756,757,759,760,763],{"id":755},"q9-in-a-fresh-clone-of-a-workspace-with-members-core-cli-running-cargo-build-p-cli-from-the-workspace-root-does-what","Q9. In a fresh clone of a workspace with ",[22,758,403],{},", running ",[22,761,762],{},"cargo build -p cli"," from the workspace root does what?",[27,765,767,777,786,801],{"className":766},[30],[32,768,770,772,773,776],{"className":769},[35],[37,771],{"disabled":39,"type":40}," Builds every member of the workspace regardless of the ",[22,774,775],{},"-p"," flag",[32,778,780,782,783,785],{"className":779},[35],[37,781],{"disabled":39,"type":40}," Fails, because ",[22,784,775],{}," is not a valid flag for workspaces",[32,787,789,791,792,794,795,797,798,800],{"className":788},[35],[37,790],{"disabled":39,"type":40}," Builds only the ",[22,793,419],{}," package (and its path\u002Fworkspace dependencies like ",[22,796,416],{},", if ",[22,799,419],{}," depends on it), skipping unrelated workspace members",[32,802,804,806,807,809,810,812],{"className":803},[35],[37,805],{"disabled":39,"type":40}," Builds only ",[22,808,416],{},", since ",[22,811,775],{}," selects dependencies rather than the named package",[82,814,815,817,828],{},[85,816,87],{},[89,818,819,821,822,794,824,797,826,800],{},[92,820,94],{}," C — Builds only the ",[22,823,419],{},[22,825,416],{},[22,827,419],{},[89,829,830,105,832,834,835,838,839,841,842,844,845,847,848,851],{},[92,831,104],{},[22,833,775],{},"\u002F",[22,836,837],{},"--package"," scopes a workspace command to one member (plus whatever that member transitively needs), which is useful in large workspaces to avoid rebuilding unrelated crates. Without ",[22,840,775],{},", ",[22,843,147],{}," at the workspace root builds all members by default — that's the \"build everything\" behavior in option A, but it only applies when ",[22,846,775],{}," is ",[312,849,850],{},"omitted",".",[14,853,854,871,901],{},[17,855,857,858,860,861,864,865,867,868,870],{"id":856},"q10-a-projects-cargotoml-has-edition-2021-but-the-committed-cargolock-was-generated-by-an-older-cargo-that-used-lockfile-format-version-3-a-contributor-with-a-very-new-cargo-runs-cargo-build-what-typically-happens","Q10. A project's ",[22,859,44],{}," has ",[22,862,863],{},"edition = \"2021\""," but the committed ",[22,866,70],{}," was generated by an older Cargo that used lockfile format version 3. A contributor with a very new Cargo runs ",[22,869,147],{},". What typically happens?",[27,872,874,880,886,892],{"className":873},[30],[32,875,877,879],{"className":876},[35],[37,878],{"disabled":39,"type":40}," The build always fails outright with an incompatible lockfile error",[32,881,883,885],{"className":882},[35],[37,884],{"disabled":39,"type":40}," Cargo silently deletes and ignores the old lock file every time",[32,887,889,891],{"className":888},[35],[37,890],{"disabled":39,"type":40}," Newer Cargo versions can read and work with older lockfile format versions (and may upgrade the format in place on next resolution), so the build generally proceeds without manual intervention",[32,893,895,897,898,900],{"className":894},[35],[37,896],{"disabled":39,"type":40}," The project must be re-initialized with ",[22,899,108],{}," to fix the format mismatch",[82,902,903,905,910],{},[85,904,87],{},[89,906,907,909],{},[92,908,94],{}," C — Newer Cargo versions can read and work with older lockfile format versions (and may upgrade the format in place on next resolution), so the build generally proceeds without manual intervention",[89,911,912,914],{},[92,913,104],{}," Cargo maintains backward compatibility for reading older lock file formats; it's forward compatibility (an old Cargo reading a lock file produced by a much newer Cargo using a newer format) that can actually cause problems. Options A and D describe unnecessarily destructive\u002Fdrastic reactions to what is normally a non-issue.",[14,916,917,924,960],{},[17,918,920,921,923],{"id":919},"q11-what-happens-when-cargo-run-is-invoked-in-a-crate-whose-source-has-zero-changes-since-the-last-successful-build","Q11. What happens when ",[22,922,341],{}," is invoked in a crate whose source has zero changes since the last successful build?",[27,925,927,933,942,951],{"className":926},[30],[32,928,930,932],{"className":929},[35],[37,931],{"disabled":39,"type":40}," It always recompiles from scratch as a safety measure",[32,934,936,938,939,941],{"className":935},[35],[37,937],{"disabled":39,"type":40}," It skips recompilation (relying on cached fingerprint\u002Ftimestamp checks in ",[22,940,431],{},") and directly executes the existing binary",[32,943,945,947,948,950],{"className":944},[35],[37,946],{"disabled":39,"type":40}," It fails, requiring an explicit ",[22,949,147],{}," first",[32,952,954,956,957,959],{"className":953},[35],[37,955],{"disabled":39,"type":40}," It recompiles only ",[22,958,44],{}," changes, ignoring source files entirely",[82,961,962,964,971],{},[85,963,87],{},[89,965,966,968,969,941],{},[92,967,94],{}," B — It skips recompilation (relying on cached fingerprint\u002Ftimestamp checks in ",[22,970,431],{},[89,972,973,975,976,978,979,981,982,984,985,987],{},[92,974,104],{}," Cargo tracks fingerprints (mtimes, flags, dependency versions) in ",[22,977,431],{}," to detect whether a rebuild is actually necessary; if nothing relevant changed, ",[22,980,341],{}," just executes the already-built artifact, making repeated ",[22,983,341],{}," calls during development fast. This incremental behavior is why ",[22,986,341],{}," is safe to invoke frequently rather than something to avoid for fear of unnecessary rebuilds (contradicting A).",[14,989,990,999,1038],{},[17,991,993,994,996,997,152],{"id":992},"q12-an-empty-srcmainrs-file-0-bytes-exists-in-an-otherwise-valid-cargo-project-what-happens-on-cargo-build","Q12. An empty ",[22,995,54],{}," file (0 bytes) exists in an otherwise valid Cargo project. What happens on ",[22,998,147],{},[27,1000,1002,1008,1018,1028],{"className":1001},[30],[32,1003,1005,1007],{"className":1004},[35],[37,1006],{"disabled":39,"type":40}," It compiles successfully, producing a binary that does nothing when run",[32,1009,1011,1013,1014,1017],{"className":1010},[35],[37,1012],{"disabled":39,"type":40}," Compile error: a binary crate root must contain a ",[22,1015,1016],{},"fn main()"," entry point",[32,1019,1021,1023,1024,1027],{"className":1020},[35],[37,1022],{"disabled":39,"type":40}," It's treated as a library crate automatically since there's no ",[22,1025,1026],{},"main"," function",[32,1029,1031,1033,1034,1037],{"className":1030},[35],[37,1032],{"disabled":39,"type":40}," Cargo auto-generates a default ",[22,1035,1036],{},"fn main() {}"," to fill the gap",[82,1039,1040,1042,1049],{},[85,1041,87],{},[89,1043,1044,1046,1047,1017],{},[92,1045,94],{}," B — Compile error: a binary crate root must contain a ",[22,1048,1016],{},[89,1050,1051,1053,1054,1056,1057,1060,1061,1063,1064,1066,1067,1069],{},[92,1052,104],{}," For a binary target, Rust requires a ",[22,1055,1026],{}," function as the entry point (",[22,1058,1059],{},"error[E0601]: main function not found","); an empty file has no such function, so it fails to compile rather than silently producing a no-op executable (A) or being reinterpreted as a library (C — target type is determined by ",[22,1062,44],{},"\u002Fdirectory layout, e.g. ",[22,1065,54],{}," vs ",[22,1068,66],{},", not by file contents).",[14,1071,1072,1090,1128],{},[17,1073,1075,1076,1079,1080,148,1083,1079,1086,1089],{"id":1074},"q13-in-a-workspace-corecargotoml-depends-on-serde-10150-and-clicargotoml-depends-on-serde-10190-what-does-cargo-do-when-resolving-the-workspace","Q13. In a workspace, ",[22,1077,1078],{},"core\u002FCargo.toml"," depends on ",[22,1081,1082],{},"serde = \"1.0.150\"",[22,1084,1085],{},"cli\u002FCargo.toml",[22,1087,1088],{},"serde = \"1.0.190\"",". What does Cargo do when resolving the workspace?",[27,1091,1093,1099,1105,1122],{"className":1092},[30],[32,1094,1096,1098],{"className":1095},[35],[37,1097],{"disabled":39,"type":40}," The build fails because two members request different versions",[32,1100,1102,1104],{"className":1101},[35],[37,1103],{"disabled":39,"type":40}," Both versions are compiled and linked into the final binary as separate copies unconditionally",[32,1106,1108,1110,1111,1113,1114,1117,1118,1121],{"className":1107},[35],[37,1109],{"disabled":39,"type":40}," Cargo's resolver picks a single version of ",[22,1112,624],{}," satisfying both semver ranges (here, ",[22,1115,1116],{},"1.0.190"," or newer within ",[22,1119,1120],{},"1.x",") to share across the workspace where possible, avoiding duplicate compilation",[32,1123,1125,1127],{"className":1124},[35],[37,1126],{"disabled":39,"type":40}," Only the workspace root's own direct dependency version is used, and member-level requirements are ignored",[82,1129,1130,1132,1140],{},[85,1131,87],{},[89,1133,1134,1136,1137,1139],{},[92,1135,94],{}," C — Cargo's resolver picks a single version of ",[22,1138,624],{}," satisfying both semver ranges to share across the workspace where possible, avoiding duplicate compilation",[89,1141,1142,1144,1145,148,1148,1150,1151,1154,1155,1157,1158,1161,1162,1066,1164,1167],{},[92,1143,104],{}," Because both ",[22,1146,1147],{},"1.0.150",[22,1149,1116],{}," are compatible under Cargo's caret (",[22,1152,1153],{},"^",") semver default, the resolver unifies them to one shared version (the highest that satisfies all constraints) recorded once in ",[22,1156,70],{},", rather than building duplicate copies (which only happens when version ",[312,1159,1160],{},"ranges"," are genuinely incompatible, e.g. ",[22,1163,1120],{},[22,1165,1166],{},"2.x",", producing two separate dependency instances rather than a hard failure).",[14,1169,1170,1187,1219],{},[17,1171,1173,1174,1176,1177,1179,1180,1183,1184,1186],{"id":1172},"q14-a-gitignore-generated-by-cargo-new-includes-target-a-teammate-accidentally-force-adds-and-commits-the-target-directory-anyway-what-is-the-main-practical-problem","Q14. A ",[22,1175,126],{}," generated by ",[22,1178,108],{}," includes ",[22,1181,1182],{},"\u002Ftarget",". A teammate accidentally force-adds and commits the ",[22,1185,431],{}," directory anyway. What is the main practical problem?",[27,1188,1190,1196,1202,1211],{"className":1189},[30],[32,1191,1193,1195],{"className":1192},[35],[37,1194],{"disabled":39,"type":40}," None — committing build artifacts has no downsides since they're just cached output",[32,1197,1199,1201],{"className":1198},[35],[37,1200],{"disabled":39,"type":40}," It bloats the repository with large, machine\u002Fplatform-specific compiled artifacts that don't belong in version control and can go stale relative to source",[32,1203,1205,1207,1208,1210],{"className":1204},[35],[37,1206],{"disabled":39,"type":40}," It will cause ",[22,1209,147],{}," to fail on other machines due to a directory name conflict",[32,1212,1214,1216,1217],{"className":1213},[35],[37,1215],{"disabled":39,"type":40}," It automatically overrides everyone's local ",[22,1218,70],{},[82,1220,1221,1223,1228],{},[85,1222,87],{},[89,1224,1225,1227],{},[92,1226,94],{}," B — It bloats the repository with large, machine\u002Fplatform-specific compiled artifacts that don't belong in version control and can go stale relative to source",[89,1229,1230,105,1232,1234,1235,1237,1238,1240],{},[92,1231,104],{},[22,1233,431],{}," contains derived build output (often gigabytes for large projects) that is regenerable, platform-specific, and irrelevant to other contributors — committing it bloats repo size\u002Fclone time and can cause confusing stale-artifact issues, which is exactly why ",[22,1236,108],{}," gitignores it by default. It doesn't break other machines' builds outright (C) since ",[22,1239,147],{}," will simply overwrite\u002Fregenerate what it needs, but it is still bad practice.",[14,1242,1243,1254,1286],{},[17,1244,1246,1247,1249,1250,1253],{"id":1245},"q15-what-is-the-idiomatic-reason-to-commit-cargolock-for-a-binary-application-but-often-not-commit-it-for-a-pure-library-crate-published-to-cratesio","Q15. What is the idiomatic reason to commit ",[22,1248,70],{}," for a binary application but often ",[312,1251,1252],{},"not"," commit it for a pure library crate published to crates.io?",[27,1255,1257,1265,1271,1277],{"className":1256},[30],[32,1258,1260,105,1262,1264],{"className":1259},[35],[37,1261],{"disabled":39,"type":40},[22,1263,70],{}," is required for compilation for binaries but forbidden by crates.io for libraries",[32,1266,1268,1270],{"className":1267},[35],[37,1269],{"disabled":39,"type":40}," Applications benefit from pinned, reproducible dependency versions across environments (dev\u002FCI\u002Fprod), while libraries should generally let downstream consumers resolve dependency versions themselves against their own constraints, so committing a library's lock file provides little benefit and can be misleading",[32,1272,1274,1276],{"className":1273},[35],[37,1275],{"disabled":39,"type":40}," There is no difference; the convention is arbitrary tooling trivia with no technical rationale",[32,1278,1280,1282,1283,1285],{"className":1279},[35],[37,1281],{"disabled":39,"type":40}," Libraries never have a ",[22,1284,70],{}," generated in the first place",[82,1287,1288,1290,1295],{},[85,1289,87],{},[89,1291,1292,1294],{},[92,1293,94],{}," B — Applications benefit from pinned, reproducible dependency versions across environments, while libraries should let downstream consumers resolve dependency versions themselves",[89,1296,1297,1299,1300,1302,1303,1305],{},[92,1298,104],{}," A binary's ",[22,1301,70],{}," is the actual deployed artifact's dependency snapshot, so pinning it avoids \"works on my machine\" drift. A library's ",[22,1304,70],{}," is not used when the library is pulled in as a dependency elsewhere (the consuming binary's own lock file governs resolution), so committing it mainly matters for the library's own CI\u002Ftests, not for downstream consumers — Cargo does still generate one locally either way (ruling out D).",[14,1307,1308,1312,1347],{},[17,1309,1311],{"id":1310},"q16-during-active-development-a-programmer-wants-the-fastest-feedback-loop-for-catching-type-errors-without-waiting-for-full-binary-generation-on-every-edit-what-is-the-best-practice-command-to-run-repeatedly","Q16. During active development, a programmer wants the fastest feedback loop for catching type errors without waiting for full binary generation on every edit. What is the best-practice command to run repeatedly?",[27,1313,1315,1323,1330,1338],{"className":1314},[30],[32,1316,1318,105,1320,1322],{"className":1317},[35],[37,1319],{"disabled":39,"type":40},[22,1321,552],{},", since release mode catches more errors",[32,1324,1326,105,1328],{"className":1325},[35],[37,1327],{"disabled":39,"type":40},[22,1329,151],{},[32,1331,1333,105,1335,1337],{"className":1332},[35],[37,1334],{"disabled":39,"type":40},[22,1336,341],{},", since it always recompiles fully every time",[32,1339,1341,105,1343,1346],{"className":1340},[35],[37,1342],{"disabled":39,"type":40},[22,1344,1345],{},"rustc src\u002Fmain.rs"," directly, bypassing Cargo for speed",[82,1348,1349,1351,1357],{},[85,1350,87],{},[89,1352,1353,206,1355],{},[92,1354,94],{},[22,1356,151],{},[89,1358,1359,1361,1362,1364,1365,1367,1368,1371,1372,1375],{},[92,1360,104],{}," As established in Q2, ",[22,1363,151],{}," performs the same error-catching analysis as ",[22,1366,147],{}," while skipping the slow codegen\u002Flink stages, making it the standard fast-loop command (many editors\u002FIDEs run it automatically on save via ",[22,1369,1370],{},"rust-analyzer","). ",[22,1373,1374],{},"--release"," (A) is slower, not faster, due to heavier optimization passes — the opposite of what's wanted here, and it doesn't catch a superset of errors that debug builds miss.",[14,1377,1378,1384,1436],{},[17,1379,1381,1382,152],{"id":1380},"q17-what-is-the-recommended-way-to-add-a-new-dependency-to-a-project-versus-manually-typing-a-version-guess-into-cargotoml","Q17. What is the recommended way to add a new dependency to a project, versus manually typing a version guess into ",[22,1383,44],{},[27,1385,1387,1400,1415,1427],{"className":1386},[30],[32,1388,1390,1392,1393,1395,1396,1399],{"className":1389},[35],[37,1391],{"disabled":39,"type":40}," Manually edit ",[22,1394,44],{}," with a version pulled from memory, since ",[22,1397,1398],{},"cargo add"," doesn't verify anything",[32,1401,1403,1405,1406,1409,1410,1412,1413],{"className":1402},[35],[37,1404],{"disabled":39,"type":40}," Use ",[22,1407,1408],{},"cargo add \u003Ccrate>",", which fetches the current appropriate version from the registry and writes a correct ",[22,1411,44],{}," entry automatically, then run a build to update ",[22,1414,70],{},[32,1416,1418,1420,1421,1423,1424,1426],{"className":1417},[35],[37,1419],{"disabled":39,"type":40}," Directly edit ",[22,1422,70],{}," by hand since ",[22,1425,44],{}," is regenerated from it",[32,1428,1430,1432,1433,1435],{"className":1429},[35],[37,1431],{"disabled":39,"type":40}," Copy an entry from an unrelated project's ",[22,1434,44],{}," verbatim, regardless of version compatibility",[82,1437,1438,1440,1451],{},[85,1439,87],{},[89,1441,1442,1444,1445,1409,1447,1412,1449],{},[92,1443,94],{}," B — Use ",[22,1446,1408],{},[22,1448,44],{},[22,1450,70],{},[89,1452,1453,105,1455,1457,1458,1460,1461,105,1464,1466],{},[92,1454,104],{},[22,1456,1398],{}," (built into modern Cargo) queries the registry for the latest suitable version and writes a properly formatted dependency entry, reducing typos and stale-version guesses versus hand-editing (A). ",[22,1459,70],{}," is derived ",[312,1462,1463],{},"from",[22,1465,44],{},", never the reverse (C inverts the real relationship established in Q3).",[14,1468,1469,1479,1521],{},[17,1470,1472,1473,1475,1476,1478],{"id":1471},"q18-a-team-wants-ci-to-fail-if-cargolock-would-change-ie-to-catch-cases-where-cargotoml-allows-a-new-version-that-hasnt-been-vettedcommitted-what-is-the-idiomatic-flag-to-use","Q18. A team wants CI to fail if ",[22,1474,70],{}," would change (i.e., to catch cases where ",[22,1477,44],{}," allows a new version that hasn't been vetted\u002Fcommitted). What is the idiomatic flag to use?",[27,1480,1482,1494,1503,1512],{"className":1481},[30],[32,1483,1485,105,1487,625,1490,1493],{"className":1484},[35],[37,1486],{"disabled":39,"type":40},[22,1488,1489],{},"cargo build --frozen",[22,1491,1492],{},"cargo build --locked",", which error out instead of silently updating the lock file if it's out of date",[32,1495,1497,105,1499,1502],{"className":1496},[35],[37,1498],{"disabled":39,"type":40},[22,1500,1501],{},"cargo build --no-lock",", which disables lock file usage entirely",[32,1504,1506,1508,1509,1511],{"className":1505},[35],[37,1507],{"disabled":39,"type":40}," There is no such mechanism; this must be checked manually by diffing ",[22,1510,70],{}," after every CI run",[32,1513,1515,105,1517,1520],{"className":1514},[35],[37,1516],{"disabled":39,"type":40},[22,1518,1519],{},"cargo build --offline",", which is unrelated to lock file freshness but is commonly confused with it",[82,1522,1523,1525,1534],{},[85,1524,87],{},[89,1526,1527,1529,1530,625,1532,1493],{},[92,1528,94],{}," A — ",[22,1531,1489],{},[22,1533,1492],{},[89,1535,1536,105,1538,1541,1542,1544,1545,1548,1549,148,1551,378,1554,1556],{},[92,1537,104],{},[22,1539,1540],{},"--locked"," requires ",[22,1543,70],{}," to be up to date and errors otherwise; ",[22,1546,1547],{},"--frozen"," additionally forbids any network access, combining ",[22,1550,1540],{},[22,1552,1553],{},"--offline",[22,1555,1553],{}," alone (D) only controls network access and does not by itself enforce lock file freshness — a common point of confusion since the two flags are often used together but solve different problems.",[14,1558,1559,1563,1606],{},[17,1560,1562],{"id":1561},"q19-what-is-the-idiomatic-way-to-organize-a-project-that-has-both-a-reusable-library-and-a-thin-cli-binary-that-uses-it","Q19. What is the idiomatic way to organize a project that has both a reusable library and a thin CLI binary that uses it?",[27,1564,1566,1575,1590,1600],{"className":1565},[30],[32,1567,1569,1571,1572,1574],{"className":1568},[35],[37,1570],{"disabled":39,"type":40}," Put all logic in ",[22,1573,54],{}," as one large file; splitting is unnecessary in Rust",[32,1576,1578,1405,1580,1582,1583,1585,1586,1589],{"className":1577},[35],[37,1579],{"disabled":39,"type":40},[22,1581,66],{}," for the core reusable logic and a thin ",[22,1584,54],{}," (or ",[22,1587,1588],{},"src\u002Fbin\u002F*.rs",") that depends on the library crate, enabling the logic to be unit-tested and reused independent of the CLI entry point",[32,1591,1593,1595,1596,1599],{"className":1592},[35],[37,1594],{"disabled":39,"type":40}," Duplicate the logic in both ",[22,1597,1598],{},"main.rs"," and a separate crate to avoid coupling",[32,1601,1603,1605],{"className":1602},[35],[37,1604],{"disabled":39,"type":40}," Always split into a full Cargo workspace, even for small single-purpose projects, since workspaces are required for any crate with more than one file",[82,1607,1608,1610,1619],{},[85,1609,87],{},[89,1611,1612,1444,1614,1582,1616,1618],{},[92,1613,94],{},[22,1615,66],{},[22,1617,54],{}," that depends on the library crate, enabling the logic to be unit-tested and reused independent of the CLI entry point",[89,1620,1621,1623,1624,1626,1627,1630],{},[92,1622,104],{}," The \"thin binary, fat library\" pattern is a widely recommended Rust idiom: a single package can contain both a library target (",[22,1625,66],{},") and one or more binary targets that consume it, giving you testable, reusable logic without needing a full multi-crate workspace (D overstates when workspaces are actually necessary — they matter for multiple ",[312,1628,1629],{},"separately versioned\u002Fpublished"," crates, not merely for having more than one file).",[14,1632,1633,1637,1670],{},[17,1634,1636],{"id":1635},"q20-before-committing-a-developer-wants-to-be-sure-their-code-both-compiles-cleanly-and-follows-the-projects-formattinglint-conventions-with-minimal-manual-effort-what-sequence-of-commands-best-reflects-idiomatic-practice","Q20. Before committing, a developer wants to be sure their code both compiles cleanly and follows the project's formatting\u002Flint conventions with minimal manual effort. What sequence of commands best reflects idiomatic practice?",[27,1638,1640,1648,1656,1662],{"className":1639},[30],[32,1641,1643,105,1645,1647],{"className":1642},[35],[37,1644],{"disabled":39,"type":40},[22,1646,341],{}," only — if it runs without crashing, the code is ready to commit",[32,1649,1651,105,1653],{"className":1650},[35],[37,1652],{"disabled":39,"type":40},[22,1654,1655],{},"cargo fmt && cargo clippy -- -D warnings && cargo test",[32,1657,1659,1661],{"className":1658},[35],[37,1660],{"disabled":39,"type":40}," Skip all tooling and rely on code review to catch formatting and lint issues",[32,1663,1665,105,1667,1669],{"className":1664},[35],[37,1666],{"disabled":39,"type":40},[22,1668,552],{}," alone, since release mode implies all checks passed",[82,1671,1672,1674,1680],{},[85,1673,87],{},[89,1675,1676,206,1678],{},[92,1677,94],{},[22,1679,1655],{},[89,1681,1682,1684,1685,1688,1689,1691],{},[92,1683,104],{}," This sequence formats code consistently, runs Clippy with warnings promoted to errors (",[22,1686,1687],{},"-D warnings",") to enforce a clean lint baseline, and runs the test suite — a standard pre-commit\u002FCI gate in professional Rust projects. Running successfully (A) says nothing about style, lint hygiene, or correctness beyond the one code path exercised; ",[22,1690,1374],{}," (D) says nothing about lints or tests at all, and optimized builds can even mask certain debug-only assertions (like overflow checks), making it a poor substitute for an actual verification pipeline.",{"title":1693,"searchDepth":1694,"depth":1694,"links":1695},"",2,[1696,1699,1701,1703,1704,1706,1708,1710,1712,1714,1716,1718,1720,1722,1724,1726,1727,1729,1731,1732],{"id":19,"depth":1697,"text":1698},3,"Q1. What does cargo new my_app create by default?",{"id":143,"depth":1697,"text":1700},"Q2. What is the key functional difference between cargo build and cargo check?",{"id":234,"depth":1697,"text":1702},"Q3. What is the correct relationship between Cargo.toml and Cargo.lock?",{"id":320,"depth":1697,"text":321},{"id":392,"depth":1697,"text":1705},"Q5. A repository has a root Cargo.toml containing a [workspace] table with members = [\"core\", \"cli\"]. What does this achieve?",{"id":484,"depth":1697,"text":1707},"Q6. Where does cargo build (default profile) place the compiled binary?",{"id":565,"depth":1697,"text":1709},"Q7. What is the purpose of the [dependencies] section in Cargo.toml?",{"id":653,"depth":1697,"text":1711},"Q8. A developer deletes Cargo.lock from a binary project and runs cargo build. The project depends on rand = \"0.8\". What happens?",{"id":755,"depth":1697,"text":1713},"Q9. In a fresh clone of a workspace with members = [\"core\", \"cli\"], running cargo build -p cli from the workspace root does what?",{"id":856,"depth":1697,"text":1715},"Q10. A project's Cargo.toml has edition = \"2021\" but the committed Cargo.lock was generated by an older Cargo that used lockfile format version 3. A contributor with a very new Cargo runs cargo build. What typically happens?",{"id":919,"depth":1697,"text":1717},"Q11. What happens when cargo run is invoked in a crate whose source has zero changes since the last successful build?",{"id":992,"depth":1697,"text":1719},"Q12. An empty src\u002Fmain.rs file (0 bytes) exists in an otherwise valid Cargo project. What happens on cargo build?",{"id":1074,"depth":1697,"text":1721},"Q13. In a workspace, core\u002FCargo.toml depends on serde = \"1.0.150\" and cli\u002FCargo.toml depends on serde = \"1.0.190\". What does Cargo do when resolving the workspace?",{"id":1172,"depth":1697,"text":1723},"Q14. A .gitignore generated by cargo new includes \u002Ftarget. A teammate accidentally force-adds and commits the target\u002F directory anyway. What is the main practical problem?",{"id":1245,"depth":1697,"text":1725},"Q15. What is the idiomatic reason to commit Cargo.lock for a binary application but often not commit it for a pure library crate published to crates.io?",{"id":1310,"depth":1697,"text":1311},{"id":1380,"depth":1697,"text":1728},"Q17. What is the recommended way to add a new dependency to a project, versus manually typing a version guess into Cargo.toml?",{"id":1471,"depth":1697,"text":1730},"Q18. A team wants CI to fail if Cargo.lock would change (i.e., to catch cases where Cargo.toml allows a new version that hasn't been vetted\u002Fcommitted). What is the idiomatic flag to use?",{"id":1561,"depth":1697,"text":1562},{"id":1635,"depth":1697,"text":1636},"md",{},"\u002Frust\u002F02-hello-world-and-cargo",{"title":5,"description":1693},"rust\u002F02-hello-world-and-cargo","L6cAeoEeljHZh8ncQfOCB0ivNuLACiwNQmwFi4-ytbw",1787335398344]