check_src_filters flag behaviour interferes with other settings

[Strooom]

[x] PlatformIO Core.

Configuration

Operating system : Win64 v11
PlatformIO Version (platformio --version) : 6.1.11

Description of problem

when using a check_src_filters flag this works only when there is only one environment. As soon as a second [env] is created, the cppcheck only checks the files in folder 'src'

Steps to Reproduce

1. set up a simple, single [env] and configure the static code checking

[env:native]
platform = native
check_tool = cppcheck
check_flags = --enable=all
check_src_filters = 
    +<test/test_*/*>
    +<src/*>

run pio check --environment native and it works, checking code in src and test folders

now add a second environment [env:another]

[env:another]

[env:native]
platform = native
check_tool = cppcheck
check_flags = --enable=all
check_src_filters = 
    +<test/test_*/*>
    +<src/*>

run pio check --environment native and it will only check source in 'src', no longer in test folders

Actual Results

does not include files in folders set by check_src_filters

Expected Results

should include files in folders set by check_src_filters, independent of how many environments there are or settings in unselected environments

[Strooom]

When moving the static code check settings to [env], the check_src_filters flag does work as expected

[env]
check_tool = cppcheck
check_flags = --enable=all
check_src_filters = 
    +<test/test_*/*>
    +<src/*>

[env:another]

[env:native]
; Environment for testing things without hardware.
platform = native

when extending/overriding general settings from [env] in the [env:native], this has no effect, ie. the [env:native] settings do not overrule the [env] settings

[env]
check_tool = cppcheck
check_flags = --enable=all
check_src_filters = 
    +<src/*>

[env:another]

[env:native]
; Environment for testing things without hardware.
platform = native
check_src_filters = 
    +<test/test_*/*>
    +<src/*>

files in test folders are not being included in cppcheck

[valeros]

Hi @Strooom, many thanks for reporting, should be fixed in the development branch.