Chapel: avoid term 'lvalue' in error messages

Created on 17 Dec 2016  路  6Comments  路  Source: chapel-lang/chapel

Bug Report

Summary of Problem

The compiler currently uses the term 'lvalue' in its error messages. I think we should stop doing this.

Steps to Reproduce

Source Code:

From test/variables/constants/assignConstError.chpl added in PR #5067 :

const two = 2;
two = 3;

Compile command:
chpl assignConstError.chpl

Execution command:
N/A

Configuration Information

  • Output of chpl --version: 1.14.0.7d05050
  • Output of $CHPL_HOME/util/printchplenv --anonymize: N/A
  • Back-end compiler and version, e.g. gcc --version or clang --version: N/A
  • (For Cray systems only) Output of module list: N/A
Compiler Error Message

Most helpful comment

PR #15800 improves this situation by complaining about "const values" in many cases. However for a case like future variables/constants/assignValueExprError.chpl :

proc returnsIntByValue() { return 1; }  
returnsIntByValue() = 1;

the compiler will still report an lvalue error. It currently reports

assignValueExprError.chpl:2: error: illegal lvalue in assignment

@bradcray suggested that it could report

assignValueExprError.chpl:2: error: cannot assign to const expression

Arguably, we could use const expression in all of the error messages (instead of sometimes reporting const value as the compiler will do after PR #15800).

All 6 comments

I wholeheartedly support moving away from "lvalue" in error messages

I threw the "easy" tag on here because I think it is (modulo agreeing on what the new error messages should say... but lots of things would be better than what we have today).

I agree with the concept for general users, though seeing the term lvalue in an error message saved me some work the other day, since it pinpointed exactly what was wrong. It will be difficult to come up with another term that works as well for that purpose.

I don't think this should have an [easy] label until we agree upon a replacement, which doesn't seem to be happening anytime soon.

I think the person who owns this issue will need to sort through the error messages and propose alternatives based on the context (e.g., things like 'const', 'param', or 'read-only' may be appropriate depending on the context). I still assert that this is an easy task (including the proposal) but I'm trying to restrain myself from getting caught up into a label wrestling war.

PR #15800 improves this situation by complaining about "const values" in many cases. However for a case like future variables/constants/assignValueExprError.chpl :

proc returnsIntByValue() { return 1; }  
returnsIntByValue() = 1;

the compiler will still report an lvalue error. It currently reports

assignValueExprError.chpl:2: error: illegal lvalue in assignment

@bradcray suggested that it could report

assignValueExprError.chpl:2: error: cannot assign to const expression

Arguably, we could use const expression in all of the error messages (instead of sometimes reporting const value as the compiler will do after PR #15800).

Was this page helpful?
0 / 5 - 0 ratings