Skip to content

Conversation

@integraledelebesgue
Copy link
Member

@integraledelebesgue integraledelebesgue commented Jul 11, 2025

Warning

This lint is not going to work until software-mansion/cairols#647 is solved

Closes #81

@integraledelebesgue integraledelebesgue force-pushed the feature/assertions_on_constants branch 5 times, most recently from 2f1794d to 8d75341 Compare July 14, 2025 09:40
@Draggu Draggu self-requested a review July 14, 2025 13:18
let asserts = get_all_inline_macro_calls(db, item)
.into_iter()
.filter(|call| {
let Some(path) = call.path(db).segments(db).elements(db).last() else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note that last() is not best choice when new macro syntax will be available, but it would also require us to check use statements if assert was not overwritten (idk if this is what compiler would do in this case)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we can use the resolver to check if the path refers to builtin assert macro?

Comment on lines 96 to 98
if let Some(ResolvedConcreteItem::Constant(const_id)) = resolved_item
&& let ConstValue::Enum(variant, _) = db.lookup_intern_const_value(const_id)
&& variant.concrete_enum_id == core_bool_enum(db)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: In linter, in such cases, we tend to use if_chain! macro to make those kind of conditions more readable. Please use it here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DIsagree that it makes it more readable, if_chain was used because rust didn't support patterns in other place than strictly after if. Now we can get rid of if_chain (No formatting issues - main benefit, slightly faster compilation).

Comment on lines 4 to 30
fn assert_on_bool_literal() {
test_lint_diagnostics!(r"
fn foo() {
assert!(true);
}
", @r"
Plugin diagnostic: Unnecessary assert on a const value detected.
--> lib.cairo:3:17
assert!(true);
^^^^
")
}

#[test]
fn assert_on_bool_const() {
test_lint_diagnostics!(r"
const C: bool = false;
fn foo() {
assert!(C);
}
", @r"
Plugin diagnostic: Unnecessary assert on a const value detected.
--> lib.cairo:4:17
assert!(C);
^
")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: check out other tests. It's better to define the code snippets as const, as in the future, the same code might be used to test the fixer for the same lint.

@integraledelebesgue integraledelebesgue force-pushed the feature/assertions_on_constants branch 3 times, most recently from 2a4a305 to db515f3 Compare July 15, 2025 10:51
@integraledelebesgue integraledelebesgue force-pushed the feature/assertions_on_constants branch from db515f3 to 7cd820a Compare July 18, 2025 09:47
@integraledelebesgue integraledelebesgue marked this pull request as draft July 18, 2025 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BLOCKED BY MACRO_RULES SEMANTICS] Add assertions_on_constants

4 participants