Closed harperjf closed 4 months ago
@harperjf thanks for the report! Yes, all such errors should be reported. You found a syntax error which is very rare, we haven't had one for a while. Thank you.
Btw, should we make the text "Note: Please report unclear, confusing or incorrect messages as bugs at"?
"Note: Please report unclear, confusing or incorrect messages as bugs at" is a good idea.
BTW man lfortran has a line
• -o TEXT: Specify the file to place the output into
which doesn't make it clear whether it's the compiler's executable output or the program's printed output. If it's the former (as calling the option -o would suggest) I think that line should say
• -o TEXT: Specify the file to place the compiler's executable output into
Here is a related program showing two ways of initializing a character parameter but lfortran accepts only one of them.
(lf2) john:~/Test$ cat parameters.f90
implicit none
character(*),parameter:: a(2) = 'Aa'
character ,parameter:: b(2)*(*) = 'Bb'
print *,a,b
end program
(lf2) john:~/Test$ lfortran parameters.f90
syntax error: Token '(' is unexpected here
--> parameters.f90:3:33
|
3 | character ,parameter:: b(2)*(*) = 'Bb'
| ^
Note: Please report unclear or confusing messages as bugs at
https://github.com/lfortran/lfortran/issues.
Actually the first one doesn't work fully yet:
program main
implicit none
character(*), parameter:: a(2) = 'Aa'
end program main
it fails in asr to llvm:
> lfortran c.f90
; ModuleID = 'LFortran'
source_filename = "LFortran"
@0 = private unnamed_addr constant [3 x i8] c"Aa\00", align 1
define i32 @main(i32 %0, i8** %1) {
.entry:
call void @_lpython_call_initial_functions(i32 %0, i8** %1)
%a = alloca [2 x i8*], align 8
store i8* getelementptr inbounds ([3 x i8], [3 x i8]* @0, i32 0, i32 0), [2 x i8*]* %a, align 8
ret i32 0
}
declare void @_lpython_call_initial_functions(i32, i8**)
asr_to_llvm: module failed verification. Error:
Stored value type does not match pointer operand type!
store i8* getelementptr inbounds ([3 x i8], [3 x i8]* @0, i32 0, i32 0), [2 x i8*]* %a, align 8
[2 x i8*]
code generation error: asr_to_llvm: module failed verification. Error:
Stored value type does not match pointer operand type!
store i8* getelementptr inbounds ([3 x i8], [3 x i8]* @0, i32 0, i32 0), [2 x i8*]* %a, align 8
[2 x i8*]
Note: Please report unclear or confusing messages as bugs at
https://github.com/lfortran/lfortran/issues.
Though I believe the real issue is that the generated ASR isn't correct.
From what I read, it seems like a syntax of the form: character:: c(6)*2
is from older Fortran standards. Though we definitely should support character(*), parameter:: a(2) = 'Aa'
(which I intended to fix in https://github.com/lfortran/lfortran/pull/3791), do we also usually make it a priority to support older Fortran syntax with LFortran, like the one mentioned in this issue? @certik
"Note: Please report unclear, confusing or incorrect messages as bugs at" is a good idea.
https://github.com/lfortran/lfortran/pull/3799
BTW man lfortran has a line
• -o TEXT: Specify the file to place the output into
which doesn't make it clear whether it's the compiler's executable output or the program's printed output. If it's the former (as calling the option -o would suggest) I think that line should say
• -o TEXT: Specify the file to place the compiler's executable output into
Yes, we need to support the old syntax. We can give a warning message / hint to use the new syntax.
Perfect, I think there are a few issues dependent on this, I'll try to see if I can fix this.
The following program compiled and ran with other compilers in my Ubuntu system but it would not allow an initialization in a declaration. Evidence:
(The error message is neither unclear nor confusing; I just think it is flagging something that is not an error.)