[feature] Infinite loop error/warning

[evanwporter]

Is your feature request related to the C++ slang project or the pyslang Python bindings?
C++ slang

Is your feature request related to a problem? Please describe.
Currently when I have code like the following:

module Test(input logic clk);
  logic [7:0] test_array;

  always_ff @(posedge clk) begin
    for (logic [2:0] i = 0; i < 8; i++) begin
      test_array[i] <= 1'b0;
    end
  end
endmodule

I'd expect to get a warning or an error that i is not big enough and that that this will result in an infinite loop. However, slang server does not give this.

Describe the solution you'd like
An error would be nice.

Describe alternatives you've considered
Double check loops, I guess?

Additional context
I am using slang-server as my lsp.

This feature is very much nice-to-have, but it shouldn't be a priority; it's more of an edge case error than anything.

[evanwporter]

Hey Mike, I doubted you've started work on this issue, but if you haven't, I'd like to take a stab at it at some point in the future.

Loops have an exit condition (please don't contradict me with an obscure edge case XD). Whether that condition is ever reached is the end user's problem.

So, I think the first step to adding this warning is for Slang to more rigorously check the operands' width in comparison expressions.

For example, slang-server doesn't have any issues with the following:

module test (
    input logic clk
);

  logic [3:0] a = 7;
  logic [7:0] b = 10;

  wire c = (a == b);  // Problem 1

  always_comb begin
    if (c < 10'd10) begin  // Problem 2
      // something something something
    end
  end

  logic [2:0] x;

  always_ff @(posedge clk) begin
    x <= 4'd0;  // Problem 3
    if (x == 3'd3) begin
      // something something something
    end
  end

endmodule

Anyways when I do get around to this, I'll probably start by adding the check to slang-tidy, since it has a defined way of adding checks.

[evanwporter]

Also the following could/should be a warning. I didn't want to open another issue for it though.

logic a;
assign a = a + 1

wire [4:0] sprite_height = regs.LCDC[2] ? 5'd16 : 4'd8;

[MikePopoloski]

A bunch of these are what I would call "tautological" warnings, captured in #533.

clang has these ones, for example:

-Wtautological-bitwise-compare
-Wtautological-compare
-Wtautological-constant-compare
-Wtautological-constant-in-range-compare
-Wtautological-constant-out-of-range-compare
-Wtautological-negation-compare
-Wtautological-overlap-compare
-Wtautological-type-limit-compare
-Wtautological-unsigned-zero-compare
-Wtautological-value-range-compare

I will probably get to these during this release cycle.

Some of your other cases are different; I don't see the problem with these:

wire c = (a == b);  // Problem 1
x <= 4'd0;  // Problem 3
wire [4:0] sprite_height = regs.LCDC[2] ? 5'd16 : 4'd8;

I guess with the latter two you want the integer literals to have a matching bit width even though it doesn't affect their values?

[evanwporter]

Problem 1: My thinking was that a can never equal b due to the difference in widths, so this deserves a warning.

Problem 3: You’re right that this isn’t explicitly a problem, since 4'd0 will be truncated automatically. That said, I’d argue that a warning would be useful, as truncation may be unintended behavior.

wire [4:0] sprite_height = regs.LCDC[2] ? 5'd16 : 4'd8;

I added this example to my message last night and intended to revise it today. As you said, it has the same issue as Problem 3; but I included it here as reminder of another case worth flagging.

[MikePopoloski]

For problem 1, that's not true. If they're both set to the same value that fits within the smaller one's width they'll compare equal.

[evanwporter]

Ah yes, you are absolutely right. My thinking was that if the value with the larger width was set to something greater than what the smaller value could hold then you'd have an impossible condition to fulfill. But it wouldn't be impossible, since in practice the upper bits of the larger condition would be truncated. By this same logic, Problem 2, wouldn't be a problem.

…

On Mon, Jan 19, 2026 at 12:28 PM Michael Popoloski ***@***.***> wrote: *MikePopoloski* left a comment (MikePopoloski/slang#1638) <#1638 (comment)> For problem 1, that's not true. If they're both set to the same value that fits within the smaller one's width they'll compare equal. — Reply to this email directly, view it on GitHub <#1638 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3QHV6ILEZWLNBT3PGZUHHT4HU45JAVCNFSM6AAAAACRUPA322VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONZQGAYTMOBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>