variables containing `block` in the identifier can later be recognized as `block` constructs

[diegojco]

Describe the bug
Variable names containing block followed by a letter (such as blocked_vector) produce in certain situations such as assignment an expectation to get a block instead of identifying this as a variable name.

To Reproduce

module m
  implicit none

contains

  subroutine real_vector_to_blocked_vector(vector, block_size, blocked_vector)
    real, intent(in) :: vector(:)
    integer, intent(in) :: block_size
    real, intent(out) :: blocked_vector(:, :)
    integer :: max_block_index, bloc
    integer :: vindex_initial, vindex_final

    bloc = 1
    max_block_index = block_size
    vindex_initial = 1
    vindex_final = block_size

    blocked_vector(1:max_block_index, bloc) = vector(vindex_initial:vindex_final)
  end subroutine real_vector_to_blocked_vector

  integer function index_from_block_and_block_index()
    index_from_block_and_block_index = 1
  end function index_from_block_and_block_index

end module m

Used fortls --debug_filepath MWE_FORTLS_ISSUE.f90 --debug_rootpath . --debug_parser

Testing parser
================================================================================
  File = "MWE_FORTLS_ISSUE.f90"
  Config file = None
  File = "MWE_FORTLS_ISSUE.f90"
  Detected format: free

================================================================================
Parser Output
================================================================================

=== No PreProc ===

module m !!! MODULE - Ln:1
  implicit none !!! IMPLICIT - Ln:2
contains !!! CONTAINS - Ln:4
  subroutine real_vector_to_blocked_vector(vector, block_size, blocked_vector) !!! SUBROUTINE - Ln:6
    real, intent(in) :: vector(:) !!! VARIABLE - Ln:7
    integer, intent(in) :: block_size !!! VARIABLE - Ln:8
    real, intent(out) :: blocked_vector(:, :) !!! VARIABLE - Ln:9
    integer :: max_block_index, bloc !!! VARIABLE - Ln:10
    integer :: vindex_initial, vindex_final !!! VARIABLE - Ln:11
    blocked_vector(1:max_block_index, bloc) = vector(vindex_initial:vindex_final) !!! BLOCK - Ln:18
  integer function index_from_block_and_block_index() !!! FUNCTION - Ln:21
  end function index_from_block_and_block_index !!! END FUNCTION Scope - Ln:23

================================================================================
Object Tree
================================================================================

1: m
  2: m::real_vector_to_blocked_vector
    6: m::real_vector_to_blocked_vector::vector
    6: m::real_vector_to_blocked_vector::block_size
    6: m::real_vector_to_blocked_vector::blocked_vector
    6: m::real_vector_to_blocked_vector::max_block_index
    6: m::real_vector_to_blocked_vector::bloc
    6: m::real_vector_to_blocked_vector::vindex_initial
    6: m::real_vector_to_blocked_vector::vindex_final
    9: m::real_vector_to_blocked_vector::#block1
      3: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index
        6: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index::index_from_block_and_block_index
2: m::real_vector_to_blocked_vector
  6: m::real_vector_to_blocked_vector::vector
  6: m::real_vector_to_blocked_vector::block_size
  6: m::real_vector_to_blocked_vector::blocked_vector
  6: m::real_vector_to_blocked_vector::max_block_index
  6: m::real_vector_to_blocked_vector::bloc
  6: m::real_vector_to_blocked_vector::vindex_initial
  6: m::real_vector_to_blocked_vector::vindex_final
  9: m::real_vector_to_blocked_vector::#block1
    3: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index
      6: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index::index_from_block_and_block_index
9: m::real_vector_to_blocked_vector::#block1
  3: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index
    6: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index::index_from_block_and_block_index
3: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index
  6: m::real_vector_to_blocked_vector::#block1::index_from_block_and_block_index::index_from_block_and_block_index

================================================================================
Exportable Objects
================================================================================

1: m
================================================================================

Expected behavior
That blocked_vector when assigned is not identified as the beginning of block. Otherwise, the analysis of subsequent lines of code is useless.

Setup information (please complete the following information):

• OS: Linux, MacOS
• Python Version 3.14.2
• fortls Version 3.2.2
• Code editor used VS Code
• Modern Fortran v4.0.0

[kunalKumar-13]

This looks like it is already fixed by the one-line change in #484, which has been open since May 2025.

The cause is operator precedence in the pattern:

BLOCK: Pattern = compile(r"[ ]*([a-z_]\w*[ ]*:[ ]*)?BLOCK|CRITICAL(?!\w)", I)

| binds loosest, so this is [ ]*([a-z_]\w*[ ]*:[ ]*)?BLOCK or CRITICAL(?!\w), not a choice between the two keywords. The (?!\w) guard therefore applies only to CRITICAL, and since FRegex.BLOCK.match() is anchored, blocked_vector(1:2, 1) = 0 matches as the opening of a BLOCK construct. A side effect of the same precedence is that the optional construct-name group only applies to the BLOCK branch, so name: critical is not recognised as a named CRITICAL construct.

I checked out #484's patch against the reproducer above and the spurious #BLOCK1 scope is gone. It also fixes the named-CRITICAL case.

I had written the same fix plus regression tests before finding #484, so I am not opening a competing PR. If it would help move #484 along, I am happy to contribute the tests — they cover block/critical with and without a construct name, and identifiers such as blocked_vector, block_size and criticality that must not match.