[Mono-dev] mcs patch to report Const location

[Atsushi Eno]

Hi,

Marek Safar wrote:
> Hello Eno,
> 
>>>> I noticed that mcs does not report locations for constants. The
>>>> attached patch fixes this matter. The patch is pretty massive
>>>> (as I had to compress it), but the fixes are pretty simple - I
>>>> just added Location parameter to everywhere BlahConstant is
>>>> created.
>>>>  
>>>>
>>> Unfortunately not for constants only. Could you make diff against mcs
>>> SVN HEAD version ?
>>
>>
>> The patch got out of date (just in two days after) - anyways
>> attached the patch for the latest head.
> 
> Oups, something is wrong I got it today.
> However, not sure about this patch. I am not convinced about usefulness 
> of this patch. On several places this location doesn't make any sense.

You will find it on compiling the repro code in bug #75805.
It used to report the error location but now it doesn't.

This is the output without my patch:

	error CS0220: The operation overflows at compile time in
	checked mode
	75805.cs(9,14): error CS0133: The expression being assigned
	to `lT' must be constant
	Compilation failed: 2 error(s), 0 warnings


After my patch. Note that location for CS0220 is supplied now:

	75805.cs(9,19): error CS0220: The operation overflows at
	compile time in checked mode:
	75805.cs(9,14): error CS0133: The expression being assigned
	to `lT' must be constant
	Compilation failed: 2 error(s), 0 warnings

> For instance
> 
> +        public static Constant Constantify (Type t, Location loc)
>         {
> 
> This method converts 'new int()' syntax not zero constant. I think if 
> someone uses this location it is mcs coding error because it is not real 
> constant.
> 
> In similar way here
> 
>         public override Constant Increment ()
>         {
> -            return new ByteConstant (checked ((byte)(Value + 1)));
> +            return new ByteConstant (checked ((byte)(Value + 1)), loc);
>         }
> 
> Returned constant is not real constant (it doesn't have any reference to 
> source code) it is more like operator.

They are nothing to do with the matter we are faced. From the point
of error reporting, it anyways needs certain location to report.

>> It stops at *-lib.cs, saying below:
>>
>> test-317.cs...  OK
>> test-318.cs...  OK
>> test-319-lib.cs...
>> Unhandled Exception: System.NullReferenceException: Object reference 
>> not set to an instance of an object
>> in [0x00020] (at 
>> C:\cygwin\home\atsushi\svn\mcs\tools\compiler-tester\compiler-tester.cs:395) 
>> TestRunner.PositiveChecker:ExecuteFile (System.Reflection.MethodInfo 
>> entry_point, System.String filename)
>> in [0x00147] (at 
>> C:\cygwin\home\atsushi\svn\mcs\tools\compiler-tester\compiler-tester.cs:353) 
>> TestRunner.PositiveChecker:Check (System.String filename)
>> in [0x0006c] (at 
>> C:\cygwin\home\atsushi\svn\mcs\tools\compiler-tester\compiler-tester.cs:153) 
>> TestRunner.Checker:Do (System.String filename)
>> in [0x00150] (at 
>> C:\cygwin\home\atsushi\svn\mcs\tools\compiler-tester\compiler-tester.cs:687) 
>> TestRunner.Tester:Main (System.String[] args)
>> make[1]: *** [run-test-local] Error 1
>> make[1]: Leaving directory `/home/atsushi/svn/mcs/tests'
>> make: *** [do-run-test] Error 1
>>
>> The attached workaround (not a fix) lets run-test completed, but
>> it still reports below:
>>
>> The latest changes caused regression in 4 file(s)
>> test-353-p2.cs
>> test-361-p2.cs
>> test-388-p2.cs
>> test-389-p2.cs
>>
>> They happen even though I haven't made any changes.
> 
> This looks strange. Are you using mono or Microsoft runtime ?

I just do "run-test" i.e. mono-wrapper runs it.

Atsushi Eno