finsihed ch14.1 and more than halfway through ch14.2

.gitea/workflows/testing.yaml

@@ -8,6 +8,8 @@ name: Test Gitea Actions
 # other examples: [push] and [pull_request, push]
 on: [push]
 
+env:
+  CARGO_TERM_COLOR: always
 
 # each workflow must have at least one job.
 # jobs run in parallel by default (we can change that).
@@ -34,4 +36,92 @@ jobs:
       # another step.
       # this step runs a bash (Ubuntu's default shell) command
       - name: list files
-        run: ls
+        run: ls
+  
+  # name of the job
+  check-code:
+    # the platform or OS that the workflow will run on.
+    runs-on: ubuntu-latest
+ 
+    # series of steps to finish the job.
+    steps:
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+
+    - name: move to minigrep
+      run: cd minigrep/
+    
+    # another step.
+    # Step 1: Run cargo check and fail if it fails
+    - name: Check
+      run: cargo check --verbose
+
+  # name of the job
+  test:
+    
+    # the platform or OS that the workflow will run on.
+    runs-on: ubuntu-latest
+    
+    # Ensures this job runs only if check-code succeeds
+    needs: check-code  
+ 
+    # series of steps to finish the job.
+    steps:
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+    
+    - name: move to minigrep
+      run: cd minigrep/
+
+    # Step 2: Run unit and integration tests (excluding documentation tests)
+    - name: Run Tests
+      run: cargo test --tests --verbose
+
+  # name of the job
+  documentation-check:
+    
+    # the platform or OS that the workflow will run on.
+    runs-on: ubuntu-latest
+    
+    # Ensures this job runs only if check-code succeeds
+    needs: check-code 
+
+    # series of steps to finish the job.
+    steps:
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+
+    - name: move to minigrep
+      run: cd minigrep/
+    
+    # Step 3: Check if documentation tests were run
+    - name: Check for Documentation Tests
+      run: |
+        DOC_TESTS=$(cargo test --doc --verbose)
+        if [[ ! "$DOC_TESTS" =~ "running" ]]; then
+          echo "No documentation tests were run!" && exit 1
+        fi

.github/workflows/rust.yml

@@ -1,5 +1,11 @@
-name: Rust
+# name of the workflow.
+# this is optional.
+name: Rust Checking and Testing
 
+# events that will trigger this workflow.
+# here, we only have "pull_request", so the workflow will run
+# whenever we create a pull request.
+# other examples: [push] and [pull_request, push]
 on:
   # push:
   #   branches: [ "master" ]
@@ -9,14 +15,85 @@ on:
 env:
   CARGO_TERM_COLOR: always
 
+# each workflow must have at least one job.
+# jobs run in parallel by default (we can change that).
+# each job groups together a series of steps to accomplish a purpose.
 jobs:
-  build:
-
+  # name of the job
+  check-code:
+    # the platform or OS that the workflow will run on.
     runs-on: ubuntu-latest
-
+ 
+    # series of steps to finish the job.
     steps:
-    - uses: actions/checkout@v4
-    - name: Build
-      run: cargo build --verbose
-    - name: Run tests
-      run: cargo test --verbose
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+    
+    # another step.
+    # Step 1: Run cargo check and fail if it fails
+    - name: Check
+      run: cargo check --verbose
+
+  # name of the job
+  test:
+    
+    # the platform or OS that the workflow will run on.
+    runs-on: ubuntu-latest
+    
+    # Ensures this job runs only if check-code succeeds
+    needs: check-code  
+ 
+    # series of steps to finish the job.
+    steps:
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+
+    # Step 2: Run unit and integration tests (excluding documentation tests)
+    - name: Run Tests
+      run: cargo test --tests --verbose
+
+  # name of the job
+  documentation-check:
+    
+    # the platform or OS that the workflow will run on.
+    runs-on: ubuntu-latest
+    
+    # Ensures this job runs only if check-code succeeds
+    needs: check-code 
+
+    # series of steps to finish the job.
+    steps:
+    # name of the step.
+    # steps run sequentially.
+    # this is optionale
+    - name: checkout
+      # each step can either have "uses" or "run".
+      # "uses" run an action written somewhere other than this workflow .
+      # usually from the community.
+      # this action checks out the repo code to the runner (instance)
+      # running the action
+      uses: actions/checkout@v4
+    
+    # Step 3: Check if documentation tests were run
+    - name: Check for Documentation Tests
+      run: |
+        DOC_TESTS=$(cargo test --doc --verbose)
+        if [[ ! "$DOC_TESTS" =~ "running" ]]; then
+          echo "No documentation tests were run!" && exit 1
+        fi

Cargo and Cratesio.md

@@ -0,0 +1,16 @@
+# More About Cargo and Crates.io
+
+Previously Cargo has only been used to do basic features of Cargo, like build, run, and test the code.
+
+Cargo can do so much more
+
+This chapter will go over some more advanced features like:
+- [Customize your build](./Custome%20Build%20Profiles.md) through release profiles
+- [Publish libraries](./Publishing%20libraries.md) on [crates.io](https://crates.io/)
+- Organize large projects with workspaces
+- Install binaries from [crates.io](https://crates.io/)
+- Extend Cargo using custom commands
+
+Cargo can do even more than what will be covered.
+
+You can chack [the documentation](https://doc.rust-lang.org/cargo/) for a full explanation of all its features.

Custome Build Profiles.md

@@ -0,0 +1,68 @@
+# Customizing Builds with Release Profiles
+Rust has *release profiles* which are predefined and customizable profiles with different configuations that allow a programmer to have more control over various options for compiling code.
+
+Each profile is configured independently of others.
+
+Cargo has two main profiles
+- the `dev` profile, Cargo uses this when you run `cargo build`
+- the `release` profile, Cargo uses this when you run `cargo build --release`
+
+The `dev` profile is defined with good defaults for development
+
+The `release` profile has good defaults for release builds
+
+These profile names are present and fimilar from the output of builds
+```
+$ cargo build
+    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
+$ cargo build --release
+    Finished `release` profile [optimized] target(s) in 0.32s
+```
+Cargo has default seeting for each of the profiles that apply when you havent specified any `[profile.*]` sections in the project's *Cargo.toml* file
+
+By adding `[profile.*]` sections you want to customize, you override any subset of the default settings
+
+For example here are the default values for the `opt-level` setting for the `dev` and `release` profiles
+```toml
+[profile.dev]
+opt-level = 0
+
+[profile.release]
+opt-level = 3
+```
+
+The `opt-level` setting controlsthe nubmer of optimizations the Rust compiler will apply to your code
+
+This has a range of 0 - 3
+
+Applying more optimizations extends the compiling time.
+
+If you are compiling your code often and want fewer optimizations to compile even if the resulting executable runs slower.
+
+This then makes the default `opt-level` for `dev` `0` becasue you want to spend less time compiling.
+
+When you are ready to realse your code it is best to spend more time compiling.
+
+You will only optimize the compilation and spend mroe time because you will run that optimized program many times, so release mode trades longer compile time for code tha runs faster.
+
+The default `opt-level` for `release` is therefore `3` because of that fact.
+
+You can override a default seeting by adding a different value for it in *Cargo.toml*
+
+For example if we wanted to use the optimization level 1 in the `dev` profile
+
+We can add these lines to the project's *Cargo.toml* file
+```toml
+[profile.dev]
+opt-level = 1
+```
+
+This overrides the defualt setting of `0`
+
+Now when you run `cargo build` cargo will use the defaults for the `dev` profile and our customization to the `opt-level`
+
+This is because of the specifiaction we set to the `opt-level`.
+
+In this customization Cargo will apply more optimization than the default, but still not as many compaired to the release build.
+
+For the full list of config options nad defaults for each profile, see [Cargo's documentation](https://doc.rust-lang.org/cargo/reference/profiles.html).

For later baja.md

@@ -0,0 +1,68 @@
+Not happy with this
+
+Rust is a very unique language and a great guiding book.
+You can learn more [here](https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html) about Rust's Documentation for publishing packages.
+
+The goal of this is to passively train you how to produce comments and code worthy of being open source and industry level.
+
+Due to the language's interesting module seperating when creating a large program. All members will be involved in the creation of all functions and how they should be seperated.
+
+First off the file tree structure will look like this example
+```
+src/
+├── lib.rs
+├── front_of_house.rs
+└── front_of_house/
+    ├── a_different_mod.rs
+    └── other_module_linked_in_modrs.rs
+```
+These are all related functions in front of house, for small modules do not make a sub directory only large or major functions should be seperated
+
+Where *`front_of_house.rs`* is like this
+```rust
+//! Describes what front_of_house module provides
+//! All functionality in other files this serves as a connector
+//! Main functionality or run should be a sub file named appropriatly
+//! re exports go here as well
+pub mod a_different_mod;
+pub mod other_module_linked_in_modrs;
+```
+
+Also where *`other_module_linked_in_modrs.rs`* looks like this
+```rust
+/// What the function does
+/// 
+/// ### Params
+/// 
+/// - input_var - Description of what the input should be.
+/// - b - Description of the second input parameter.
+/// 
+/// ### Returns
+/// 
+/// - Description of the return value.
+/// 
+/// ### Example Usage
+/// 
+/// ```rust
+/// // how a user would use this function, replace ex_crate with actual path to use function
+/// // this is how a public but internal module would be used by an outside user (ex_crate needs to be changed)
+/// let result = crate::front_of_house::other_module_linked_in_modrs::example_funct(5, 10);
+/// assert_eq!(result, 15);
+/// ```
+/// ### Author (s)
+/// 
+/// - Name <semiperminant@exmaplemail.com>
+/// - Another Example <different@examplemail.com>
+/// semi-permanent email, do not need to respond but try to be a good alumni
+pub fn example_funct(input_var: i32, b: i32) -> i32 {
+    // example variable can be anything not just an integer
+    let var_example = 0;
+    
+    // example function does nothing significant
+    var_example + input_var + b
+}
+```
+
+One all of the main modules have been decided upon a senior member or lead will be assigned to that module will then be responsible and will break the module into sub modules with their team
+
+The team will then come other for a final time to ensure that all modules and sub modules make sense and thier ideas make sense

Iterators and Closures.md

@@ -13,7 +13,7 @@ It will cover:
 - [*Closures*](./Closures.md) - a function-like construct you can store in a variable
 - [*Iterators*](./Iterators.md) - a way of processing a series of elements
 - How to use colsure and iterators to [improve the I/O project (minigrep)](./Improving%20The%20IO%20Project.md)
-- [The preformance of closures and iterators](./The%20preformance%20Closures%20and%20Iterators.md) (Spoiler alert: they are faster than you might think!)
+- [The preformance of closures and iterators](./The%20Performance%20Closures%20and%20Iterators.md) (Spoiler alert: they are faster than you might think!)
 
 We have already covered some other Rust freatures, such as pattern matchin and enums, that are also influenced by the functional style.
 

Publishing libraries.md

@@ -0,0 +1,277 @@
+# Publishing a Crate to Crates.io
+We have used packages form [crates.io](http://crates.io) as dependencies of our pojects.
+
+You could also share your code with others by publishing your own packages.
+
+The crate regsitry at [crates.io](http://crates.io) distributes the source code of your packages, it primarily hosts code that is open source.
+
+Rust and Cargo have features that make your published package easier for people to find and use.
+
+These features will be covered later and then explaining how to publish a package
+
+## Making Useful Documentation Comments
+Accurately documenting your packages will others know how and when to use them.
+
+It is worth investing the time to write documentation
+
+In ch we said that to comment in Rust you use two slashes, `//`
+
+Rust also has a pariticualr kind of comment for documentation.
+
+This is known conveniently as a *documentation comments*, that will generate HTML documentation.
+
+The HTML diesplays the contents of documentation comments for public API items intended for programmers interested in knowing how to use your crate as opposed to how your crate is *implemented*.
+
+The documentation comments uses three slashes `///` instead of two and this supports Markdown notation for formatting the text.
+
+The placement of documentation comments just before the item they are documenting.
+
+Here is an example of documentation comments for an `add_one` function in a crate named `my_crate`.
+```rust
+/// Adds one to the number given.
+///
+/// # Examples
+///
+/// ```
+/// let arg = 5;
+/// let answer = my_crate::add_one(arg);
+///
+/// assert_eq!(6, answer);
+/// ```
+pub fn add_one(x: i32) -> i32 {
+    x + 1
+}
+```
+
+Here we first give a description of what the `add_one` function does.
+
+Then we add a section starting with the heading `Examples`, and then provide code that demonstrates how to use the `add_one` function.
+
+We can generate te HTML documentation from this documentation comment by running `cargo doc`.
+
+This command runs the `rsutdoc` tool which comes distributed with Rust and pts the generated HTML documentation in the *target/doc* directory.
+
+For convenience running `cargo doc --open` will build the HTML for your current crate's documentation as well as the documentation for all of your crate's dependencies then it will open the result in a web browser.
+
+Navigating to the `add_one` function you will see how the texxt in the documentation comments is rendered  as shown below
+<img src="https://doc.rust-lang.org/book/img/trpl14-01.png" />
+
+### Commonly Used Sections
+We previously used the `# Examples` Markdown heading to create a section in the HTML with the titl "Examples".
+
+Here are some other secions that crate author commonly use in the documentation
+- **Panics**: The scenarios in which the function being documented could panic.
+    Funtion callers who don't want thier programs to panic should make sure they dont call the function in this way/situation
+- **Errors**: If the function returns a `Result`, that describes the kinds of errors that may occur and what conditions might cause those errors to be returned. 
+    This can be helpful to caller so that they can write code to handle different kinds of errors in different ways.
+- **Safety**: If the function is inheritly `unsafe` to call, there should be a section explaing why the function is unsafe and covering the invariants that the function expects callers to uphold.
+
+Most documentation comments don't need all of these sctions but this is a good checklist ot remind you of the aspects of your code users will be interested in knowing.
+
+### Documentation Comments as Tests
+Adding example code blocks in your documentation comments can help demonstrate how to use the library.
+
+Doing so also has an addtional bonus: running `cargo test` will run the code examples in your documentation as tests
+
+This ensures that your examples will be tested to work, because that would be the worst to ship an example that doesn't work.
+
+If we run `cargo test` with the documentation for `add_one` function we would get this output
+```
+   Doc-tests my_crate
+
+running 1 test
+test src/lib.rs - add_one (line 5) ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.27s
+```
+
+Now if we change either the function or the example so the `assert_eq!` in the example panics, then we will see that the doc tests catch that the example and the code are out of sync with each other.
+
+### Commenting Contained Items
+The style of commnet `//!` adds documentation to the item that contains the comments rather than to the items following the comments.
+
+We typically use these doc comments inside the crate root file (src/lib.rs by convention) or inside a module to document the crate or the module as a whole.
+
+For example, adding documentation that describes the purpose of the `my_crate` that contains the `add_one` function
+
+We add documentation comments qith `//!` to the beginning of the *src/lib.rs* file
+
+Here is an example of this
+```rust
+//! # My Crate
+//!
+//! `my_crate` is a collection of utilities to make performing certain
+//! calculations more convenient.
+
+/// Adds one to the number given.
+// --snip--
+///
+/// # Examples
+///
+/// ```
+/// let arg = 5;
+/// let answer = my_crate::add_one(arg);
+///
+/// assert_eq!(6, answer);
+/// ```
+pub fn add_one(x: i32) -> i32 {
+    x + 1
+}
+```
+
+Notice that there isn't any code after the last line that begins with `//!`
+
+Because we started the comments with `//!` instead of `///` , this inidcates we are documenting the item that contains this comment rather than an item that follows his comment.
+
+In this case, that item is the *src/lib.rs* file which is the crate root.
+
+These comments describe the entire crate
+
+When we run `cargo doc --open`, these comments will display on the front page of the documentation for `my_crate` above the list of public items in the crate
+
+Here is what the docs would look like
+<img src="https://doc.rust-lang.org/book/img/trpl14-02.png" />
+
+Documentation comments within items are useful for describing crates and modules especially.
+
+Use them to explain the overall purpose of the container to help your users understand the crate's organization
+
+## Exporting a Convenient Public API with `pub use`
+The structure of your public API is a major consideration when publishing a crate.
+
+People who use your crate are less familiar with the structure than you.
+
+They might have difficulty finding the pieces they want to use if your crate has a large moudle hierarchy
+
+Before we covered how to make items public using the `pub` keyword and bring items into a scope iwth the `use` keyword.
+
+The structure that makes sense to you while you are developing the crate might not be very useful or convenient for your users.
+
+You might want to organize your structs in a heirary containing multiple levels.
+
+The people who want to use a type you have defined deep in the hierary might have trouble finding out that tpye exists.
+
+They might also be annoyed having to enter `use` `my_crate::some_module::another_module::UsefulType;` rather than `use` `my_crate::UsefulType;`.
+
+The good news is that if the struct isn't convenient for others to use from another library, you dont have to rearrange your interal organization.
+
+You can instead re-export items to make a public structure that is different form your private structure by using `pub use`.
+
+Re-exporting takes a public item in one location and makes it public in another location as if it we defined in the other location instead
+
+For example lets say we made a libarary named `art`
+
+Within this library there are two modules:
+- a `kinds` module containing two enums named `PrimaryColor` and `SecondaryColor`
+- a `utils` module containinga function named `mix`
+
+Here is what it would look like in *src/lib.rs*
+```rust
+//! # Art
+//!
+//! A library for modeling artistic concepts.
+
+pub mod kinds {
+    /// The primary colors according to the RYB color model.
+    pub enum PrimaryColor {
+        Red,
+        Yellow,
+        Blue,
+    }
+
+    /// The secondary colors according to the RYB color model.
+    pub enum SecondaryColor {
+        Orange,
+        Green,
+        Purple,
+    }
+}
+
+pub mod utils {
+    use crate::kinds::*;
+
+    /// Combines two primary colors in equal amounts to create
+    /// a secondary color.
+    pub fn mix(c1: PrimaryColor, c2: PrimaryColor) -> SecondaryColor {
+        // --snip--
+    }
+}
+```
+Here is what the frontpage docs generated by `cargo doc` would look like
+<img src="https://doc.rust-lang.org/book/img/trpl14-03.png" />
+
+Notice that the `PirmaryColor` and `SecondaryColor` types are't listed on the front page nor is the `mix` function.
+
+We have to navigate to `kinds` and `utils` to see them.
+
+Another crate that depends on this library would need `use` statements that bring items from `art` into scope. Specifying the module structure that is currently defined
+
+Here is an example of a crate that uses the `PrimaryColor` and `mix` items form the `art` crate
+```rust
+use art::kinds::PrimaryColor;
+use art::utils::mix;
+
+fn main() {
+    let red = PrimaryColor::Red;
+    let yellow = PrimaryColor::Yellow;
+    mix(red, yellow);
+}
+```
+The author of the code in above which uses the `art` crate had to figure out that `PrimaryColor` is in the `kinds` module and `mix` is in the `utils` module.
+
+The module struct of the `art` crate is more relevant to developers working on the `art` rate than to those using it.
+
+The internal structure doesn't contain any useful info for someone trying to understand how to use the `art` crate, but rather causes confusion becasue devs who use it have to figure out where to look and must specify the module names in the `use` statements.
+
+To remove the interal organization from the public API, we can modify the `art` crate to add `pub use` statements to re-export the items at the top level
+```rust
+//! # Art
+//!
+//! A library for modeling artistic concepts.
+
+pub use self::kinds::PrimaryColor;
+pub use self::kinds::SecondaryColor;
+pub use self::utils::mix;
+
+pub mod kinds {
+    // --snip--
+}
+
+pub mod utils {
+    // --snip--
+}
+```
+The API docs that `cargo doc` generates for this crate will now list and link re-exprots on the front page.
+
+This makes the `PrimaryColor` and `SecondaryColor` types and makes finding the `mix` function easier
+
+<img src="https://doc.rust-lang.org/book/img/trpl14-04.png" />
+
+The `art` crate users can still see the internal structure as demonstrated in the picture above.
+
+They could also use the more convenient structure like in the example below
+```rust
+use art::mix;
+use art::PrimaryColor;
+
+fn main() {
+    // --snip--
+}
+```
+
+In cases where there are many  nested modules, re-exporting the types at the top level with `pub use`.
+
+This can make a very significant difference in the experience of people who use the crate.
+
+Another common use of `pub use` is to re-export definitions of a dependency in the current crate to make that crate's definitions part of your crate's public API.
+
+Creating a useful public API structure is more of an art than a science.
+
+You can iterate to find the API that works best for your users.
+
+Choosing `pub use` gives you flexibility in how you structure your crate internally and decouples that interanl struct from what you present to your users.
+
+Look at some of the code of crates you have used previously to see if their internal struct differs from their public API.
+
+## Setting Up a Crates.io Account
+Before being able to create

guessing_game/target/.rustc_info.json

@@ -1 +1 @@
-{"rustc_fingerprint":4305361489769004817,"outputs":{"13331785392996375709":{"success":true,"status":"","code":0,"stdout":"___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/brock/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n","stderr":""},"17747080675513052775":{"success":true,"status":"","code":0,"stdout":"rustc 1.85.0 (4d91de4e4 2025-02-17)\nbinary: rustc\ncommit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688\ncommit-date: 2025-02-17\nhost: x86_64-unknown-linux-gnu\nrelease: 1.85.0\nLLVM version: 19.1.7\n","stderr":""}},"successes":{}}
+{"rustc_fingerprint":4305361489769004817,"outputs":{"17747080675513052775":{"success":true,"status":"","code":0,"stdout":"rustc 1.85.0 (4d91de4e4 2025-02-17)\nbinary: rustc\ncommit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688\ncommit-date: 2025-02-17\nhost: x86_64-unknown-linux-gnu\nrelease: 1.85.0\nLLVM version: 19.1.7\n","stderr":""},"13331785392996375709":{"success":true,"status":"","code":0,"stdout":"___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/brock/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n","stderr":""}},"successes":{}}

hello_cargo/target/.rustc_info.json

@@ -1 +1 @@
-{"rustc_fingerprint":4305361489769004817,"outputs":{"13331785392996375709":{"success":true,"status":"","code":0,"stdout":"___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/brock/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n","stderr":""},"17747080675513052775":{"success":true,"status":"","code":0,"stdout":"rustc 1.85.0 (4d91de4e4 2025-02-17)\nbinary: rustc\ncommit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688\ncommit-date: 2025-02-17\nhost: x86_64-unknown-linux-gnu\nrelease: 1.85.0\nLLVM version: 19.1.7\n","stderr":""}},"successes":{}}
+{"rustc_fingerprint":4305361489769004817,"outputs":{"17747080675513052775":{"success":true,"status":"","code":0,"stdout":"rustc 1.85.0 (4d91de4e4 2025-02-17)\nbinary: rustc\ncommit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688\ncommit-date: 2025-02-17\nhost: x86_64-unknown-linux-gnu\nrelease: 1.85.0\nLLVM version: 19.1.7\n","stderr":""},"13331785392996375709":{"success":true,"status":"","code":0,"stdout":"___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/brock/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n","stderr":""}},"successes":{}}