chore: Remove the concept of CrateType

[phated]

Description

Problem*

Towards #1838

Summary*

This removes the concept of a CrateType as it doesn't really matter except for adding dependencies and doing a "full" compilation (with backend, etc). In the cases where we need to know if something is a "binary crate" we can just check to see if it has a main function.

Documentation

• This PR requires documentation updates when merged.

  • I will submit a noir-lang/docs PR.
  • I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[kevaundray]

I don't understand the reason to remove this; since a binary crate and something having a main function are not the same thing.

Also curious as to how this plays out with workspaces

[TomAFrench]

A library (lib.nr) with a main function would be treated as a binary crate here.

[phated]

I think that is fine though; although, in rust, the extra main would be ignored and clippy would give a warning that it is unused. I could see us doing that, wdyt?

[kevaundray]

This still has the concept of a crate-type in the frontend, its just that it is implicit by having a main function IIUC. I think its better to be explicit about the crate-type

[phated]

Clippy !== frontend in rust. Clippy is a linting tool that runs some phases of the compiler and then gives you feedback. The cargo abstraction defines what a lib or bin actually is, including specifying custom paths (you can specify src/lib.rs as the path for a [[bin]] iirc).

[phated]

I don't understand the reason to remove this; since a binary crate and something having a main function are not the same thing.

From the compiler perspective, anything through the check phase doesn't care about this at all. The only thing that cares about this is dependency resolution and the final step of "compile_main". And it could be argued that it is not something that dependency resolution should care about (e.g. cargo allows a lib.rs with a main function and clippy warns you it is unused). Additionally, the only heuristic for determining this difference was the name lib.rs vs main.rs which gets really clunky when we start allowing custom paths (such as how cargo allows it).

Also curious as to how this plays out with workspaces

I'm not exactly sure how you view workspaces, as I view anything with a Nargo.toml as a workspace because it is a grouping of files; however, if there is additional logic needed inside nargo (which is the "workspace tool") then it should happen inside nargo, instead deep in the frontend which should just be compiling source code.

[kevaundray]

I'm not exactly sure how you view workspaces, as I view anything with a Nargo.toml as a workspace because it is a grouping of files; however, if there is additional logic needed inside nargo (which is the "workspace tool") then it should happen inside nargo, instead deep in the frontend which should just be compiling source code.

I was using the same definition as cargo workspaces : https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

From the compiler perspective, anything through the check phase doesn't care about this at all. The only thing that cares about this is dependency resolution and the final step of "compile_main". And it could be argued that it is not something that dependency resolution should care about (e.g. cargo allows a lib.rs with a main function and clippy warns you it is unused). Additionally, the only heuristic for determining this difference was the name lib.rs vs main.rs which gets really clunky when we start allowing custom paths (such as how cargo allows it).

That makes sense, but I think we want to be explicit in defining a crate to be a library or a binary, then if there is a main function in a library crate, "clippy" can give a warning. Instead of it being inferred via the main function

[phated]

That makes sense, but I think we want to be explicit in defining a crate to be a library or a binary, then if there is a main function in a library crate, "clippy" can give a warning. Instead of it being inferred via the main function

If you want to give a clippy-style warning, this should just be a "nargo thing" not a "noirc thing" (or "frontend thing"). The frontend should have no concept of the crate type

[TomAFrench]

Looks like this has been blocked by #1913. We'll need to revert/rework some of the changes in this PR to be able to progress on this.

[phated]

Converting to draft, as my rebase removes some of the premature-merge workspace logic

[phated]

This is being replaced by #2134