feat: Remove comptime and warn upon usage

[jfecher]

Description

Problem

Resolves #2040
Resolves #280
Resolves #1188
Resolves #793
Resolves #1035 - the failure to unroll the for loop is now an error instead of a panic

Summary

This PR removes comptime from the language. The comptime keyword and syntax are currently still kept and parsed for backwards compatibility, but are now deprecated and will issue a warning when used. comptime has been removed because it is no longer needed for accessing arrays. However, since for loops still must be known at compile-time I've taken the liberty of adding an error message for this which also solves some past panics that the comptime tracking did not catch.

Example error message for a loop whose length is not known at compile-time:

error: 
   ┌─ /.../noir/short/src/main.nr:28:22
   │
28 │         for _i in 0..self.count {
   │                      ---------- Could not determine loop bound at compile-time

The error message will always correctly point to only the part of the range that is unknown (start or end). If both are unknown, only the start range error is issued since we halt on the first error.

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.
    • All references to comptime can be removed. We should still mention that the bounds of a for loop need to be known at compile-time. Since the compiler inlines every function, function parameters are still okay for use as for loop bounds.
    • We should also remove the RepeatedValue example. It has been broken in Noir for a while.

Additional Context

I'd like some discussion on this PR. Removing comptime simplifies the system and removes the confusing subtle differences between comptime and rust's const, but also means it may be more difficult for users to track why a for loop's bounds may or may not be known. Instead of being able to follow comptime annotations in the program, they will only get an error on the for loop itself and would have to work backward to figure out why the bounds are not compile-time known.

PR Checklist*

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

[TomAFrench]

comptime has been removed because it is no longer needed for accessing arrays.

It's still cheaper to perform comptime array accesses, no?

[jfecher]

It's still cheaper to perform comptime array accesses, no?

It is cheaper, but this was determined by how many optimizations the ssa could do rather than whether it was classified as such by the type checker. So the runtime is unchanged but it may be more difficult for users to track whether something is comptime in complex cases.

[jfecher]

@phated this should not be a breaking change, comptime is still in the language but is ignored and issues a warning when used now.

[phated]

The PR title should indicate that then. I'll update.

[jfecher]

@phated it's more than just warning though since comptime is removed from the compiler internally. Perhaps Deprecate comptime? It is removed from the language itself, it is just that we keep parser support for it to issue deprecation warnings

[phated]

That's a tough one, I think I'd call it breaking then since it changes programs. "feat!: Remove comptime and warn upon usage"

[jfecher]

This shouldn't break any existing programs and the circuits generated should be unchanged as well since comptime in the type system never affected codegen

[Savio-Sou]

cc @critesjosh @signorecello in case if you have any thoughts from external devs' perspectives on the PR.

[kevaundray]

LGTM - some small nits