PR# 15822 VUOT(1) error not detected in expression that is routine actual argument

Problem Report Summary
Submitter: prestoat2000
Category: Compiler
Priority: Medium
Date: 2009/05/15
Class: Bug
Severity: Serious
Number: 15822
Release: 6.4.78600
Confidential: No
Status: Closed
Responsible:
Environment: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.0.10) Gecko/2009042715 Firefox/3.0.10 Solaris 10 on SPARC
Synopsis: VUOT(1) error not detected in expression that is routine actual argument

Description
The compiler does not detect a VUOT(1) error in an expression which is the
actual argument to a routine call or the expression of an object test.

Added eweasel test valid252 for this bug.
To Reproduce
Run eweasel test valid252.
Problem Report Interactions
From:alexk_es    Date:2017/08/27    Status: Closed    Download    
The issue was that as soon as there were no scopes for conflicting identifiers (they are present in conditional instructions, but there is none in the part 'b' of the  expression 'a and then b'). However, to avoid this inconsistency, the conflict is now checked before checking scopes. So, the error is now reported even when there are no scopes altogether.
Fixed in rev#100690 of EiffelStudio 17.11 intermediate release.

From:prestoat2000    Date:2009/05/17    Download    
The reason I reported this as a bug is that the compiler *does* report a
VUOT(1) error on the following:

   if attached {TEST2} Current as x and then attached {TEST3} Current as x then
   end

I couldn't immediately see a reason why this would be reported as VUOT(1)
while the submitted test case would not, since they looked very similar to me.
So I assumed this was just a bug.

Whatever you and Manu agree on is fine.  But more importantly, the behavior
of the compiler should match the ECMA Eiffel standard.  If you're not going
to report an error on the submitted test case, then the standard should
be changed (if necessary) to match what compiler writers are actually going
to implement.

From:alexk_es    Date:2009/05/17    Status: Analyzed    Download    
Because the original validity error allowed the scopes of OT locals to intersect, the compiler now checks the rule not at the declaration time but at the time the scope starts. So, as soon as there are intersecting scopes, it will report the validity error as expected.
In the example, if you extend the expression by adding more terms to it, you'll see VUOT errors.
It's possible to report the error at both declaration time and potential use time, but then the same error may be reported twice and it's not that easy to get rid of the duplication because the scopes are sometimes not near the declaration.
So, do you agree to leave the things as they are now?