Walkthrough

The literal crate is relocated from the compiler directory to the crates directory. Workspace member declarations and dependency path references in Cargo.toml are updated to reflect this new location.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

• Configuration-only change affecting a single manifest file
• Straightforward path updates with no logic modifications or new features

Poem

🐰 The literal crate hops along,
From compiler to crates it belongs,
A simple move, clean and bright,
Paths updated, all feels right! ✨

Pre-merge checks and finishing touches

• Create PR with unit tests
• Post copyable unit tests in a comment

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Reviewing files that changed from the base of the PR and between 609d99f and d92303b.

• Cargo.toml (1 hunks)

Cargo.toml (2)

121-139: Workspace glob pattern correctly includes the relocated crate.

The glob pattern "crates/*" successfully matches crates/literal and will automatically discover it as a workspace member, consistent with how crates/doc is handled. The workspace configuration is correct.

---

157-157: Migration of compiler/literal → crates/literal verified as complete.

The workspace dependency path at line 157 has been correctly updated to { path = "crates/literal", version = "0.4.0" }. Verification confirms:

• ✓ crates/literal directory exists with valid Cargo.toml
• ✓ Workspace glob pattern "crates/*" automatically includes the new crate
• ✓ No stale references to the old compiler/literal path remain
• ✓ Follows existing project conventions for crates in the crates/ directory

No further action needed.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

• X
• Mastodon
• Reddit
• LinkedIn

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai review

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

the PR auto-format is reporting issue although everything passes. I ain't so sure what's the added value of it.

the PR auto-format is reporting issue although everything passes. I ain't so sure what's the added value of it.

One of the tests on Windows was failing, so I re-ran it. Ideally, the auto-format check should run first (before all the other checks even get a chance to run), so that's something for @YashSuthar983 to keep in mind.

the PR auto-format is reporting issue although everything passes. I ain't so sure what's the added value of it.

One of the tests on Windows was failing, so I re-ran it.

TY:)
I was wondering how it's marked as OK now. I don't have permissions to re-run a single workflow:/

Ideally, the auto-format check should run first (before all the other checks even get a chance to run), so that's something for @YashSuthar983 to keep in mind.

What's the added value of formatting things via the CI? why not enforce it like we did it until now?

@fanninpm as I discussed with @youknowone ,we decided that auto formatting should run after all checks passes as if we do before we would have a auto format commit with skip ci and there will be some extra commits too if ci fails after auto format.

So in current implementation auto format waits for all CI to pass and there is timeout , there it every 30 checks if ci passes or not .

we decided that auto formatting should run after all checks passes

Ideally formatting before CI will be better. Because CI passes after formatting is more complete. If no choice, this is better than nothing

why not enforce it like we did it until now?

Auto-formatting is a higher level policy than enforce by policy. User always must format code, which is automatic task run by a command. Then why it shouldn't be automatic? That's one of the major purpose of programming and software.

Please leave more discussion to #6204

we decided that auto formatting should run after all checks passes

Ideally formatting before CI will be better. Because CI passes after formatting is more complete. If no choice, this is better than nothing

Agree

why not enforce it like we did it until now?

Auto-formatting is a higher level policy than enforce by policy. User always must format code, which is automatic task run by a command. Then why it shouldn't be automatic? That's one of the major purpose of programming and software.

In some way I agree, but I think it makes things more complicated than it needs to be. IMO CI needs to validate things. There's pre-commit hooks to make it easier for developers