Bug 130677 - Support for &h &o Basic literals is incomplete
Summary: Support for &h &o Basic literals is incomplete
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Shubham Jain
URL:
Whiteboard: target:7.2.0
Keywords: difficultyInteresting, topicCleanup
Depends on:
Blocks: Macro-StarBasic
  Show dependency treegraph
 
Reported: 2020-02-15 09:48 UTC by LibreOfficiant
Modified: 2021-03-24 13:02 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LibreOfficiant 2020-02-15 09:48:26 UTC
Description:
Literals rendered datatypes should be either Integer either Long. This is not always the case. Literals should support datatypes suffixes. Literals behaviour should be identical across LibreOffice Basic runtimes (RT). Ideally malformed literals should be detected by the compiler, not only at runtime.

Steps to Reproduce:
1. Copy Basic macros in IDE
2. Execute them
3. Check the results

Actual Results:
TypeName(expr) and VarType(expr) return inconsistent values for literals

Expected Results:
TypeName(expr) and VarType(expr) return consistent values


Reproducible: Always


User Profile Reset: No



Additional Info:
online help:
https://help.libreoffice.org/7.0/en-US/text/sbasic/shared/01020100.html?DbPAR=BASIC#bm_id3149346
Comment 1 LibreOfficiant 2020-02-15 10:21:13 UTC
MS-VBA help offers little if no information about literals. However foreign Basic-like languages hold preciser information:

o  IBM LotusScript - Literal number construction rules
https://www.ibm.com/support/knowledgecenter/SSVRGU_10.0.0/basic/LSAZ_LITERAL_NUMBER_CONSTRUCTION_RULES.html

o  FreeBASIC 
https://www.freebasic.net/wiki/wikka.php?wakka=ProPgLiterals

o  Xojo aka RealBasic 
https://docs.xojo.com/Val & alter

Usage of literals spans over multiple places in Basic. Examples are numerical expressions and math functions as well as conversion or datatype functions such as Typename() or Vartype(). It no obvious to locate literal-related QA Basic test cases or to determine whether they should be spread over various QA test cases or test suites.

Bugs or enhancement requests with regards to literals are listed herewith.
Comment 2 LibreOfficiant 2020-02-15 10:31:34 UTC
Leading zeroes in &h and &o literals should be ignored. 

As far as I understand this is the case at runtime. I am unclear if this is the cases in all contexts, i.e. regardless of Basic Compile/Runtime Option statements.

MS-VBA compiler strips leading zeroes.
Comment 3 LibreOfficiant 2020-02-15 10:40:56 UTC
MAX and MIN literal expressions must be checked

&h: &h7FFFFFFF = 2^31-1 - &h80000000 = 2^31)
&o: ..

I assume this is performed inside test_scanner.cxx. I am unclear as far as &o octal literals are concerned. Is this the cases for all contexts/runtimes?

MS-VBA compiler rejects overflow and underflow situations.
Comment 4 Andreas Heinisch 2020-02-15 11:41:31 UTC
The tests, at least for the hex case, are in https://opengrok.libreoffice.org/xref/core/basic/qa/cppunit/test_scanner.cxx?r=7ddedd25#780

We could add also the tests for Min/Max and octal notations.
Comment 5 LibreOfficiant 2020-02-15 12:53:24 UTC
In the absence of a suffix &h &o notations should return Integer or Long values. Basic seems to behave this way although Basic engine internals are stored differently. 

Whenever hexadecimal &h or octal &o literals can be rendered to Int16 numbers, Typename() returns "Integer", Vartype() returns V_INTEGER

Whenever hexadecimal &h or octal &o literals are rendered to Int32 numbers, Typename() returns "Double" instead of "Long", Vartype() returns V_INTEGER instead of V_LONG

Basic-like languages do not necessarily 'explicitly' enforce 'default' Integer or 'Long' number typing for & h &o notations. However I feel LibreOffice Basic should support that.
Comment 6 LibreOfficiant 2020-02-15 13:05:14 UTC
Literal &h &o notations, and other to come, do not support number suffixes yet.

Declaration type characters, as called in Basic online help, should apply to &h and &o notations. LibO Basic help - Using variables:
https://help.libreoffice.org/7.0/en-US/text/sbasic/shared/01020100.html?DbPAR=BASIC#bm_id3149346

MS-VBA support variable type declaration thru suffixes.

Variable or literal type suffixes are supported by all Basic-like languages and offer valuable disambiguation to literal notations. As such I feel LibreOffice Basic should support that in all contexts.
Comment 7 LibreOfficiant 2020-02-15 13:21:55 UTC
BASIC QA test cases/suites locations and organisation is unclear

o  Some tests are performed as .cxx test suites
o  LibO Basic coverage exist as .vb
o  VBA compatible cases exist as .vb

Literal notations spans overs multiple areas such as: number computation, number conversion, datatypes composition, and so on. Numerous functions implicitly make use of literals. Determining where to implement test cases is a challenge. 

A wiki page documenting test cases/suites organization and how to organize literal notation may be of interest.
Comment 8 Andreas Heinisch 2021-01-26 20:17:43 UTC
Regarding MS-VBA https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/data-types/type-characters could be interesting.

We should check if all these literals are implemented an can be used throughout LO. In addition, the wiki page should be updated an maybe some of the tests in https://opengrok.libreoffice.org/xref/core/basic/qa/cppunit/test_scanner.cxx?r=7ddedd25#781 can be moved to a vb file where all the literals are tested.

Even the date literal test (https://opengrok.libreoffice.org/xref/core/basic/qa/basic_coverage/test_date_literal.vb?r=09425ab9) could be merged in this test file for literals.

What do you think?
Comment 10 Commit Notification 2021-02-17 14:35:20 UTC
shubham656 committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/30ca77c43ba1c8f94d6f34eea763a3d3ca7e72f6

tdf#130677 Write new tests for literals

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Buovjaga 2021-03-23 07:47:42 UTC
Is there something that needs to be done here or can the status be changed to fixed?
Comment 12 Alain Romedenne 2021-03-24 12:56:15 UTC
(In reply to Andreas Heinisch from comment #8)
> Regarding MS-VBA
> https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/
> language-features/data-types/type-characters could be interesting.
> 
> We should check if all these literals are implemented an can be used
> throughout LO. In addition, the wiki page should be updated an maybe some of
> the tests in
> https://opengrok.libreoffice.org/xref/core/basic/qa/cppunit/test_scanner.
> cxx?r=7ddedd25#781 can be moved to a vb file where all the literals are
> tested.
> 
> Even the date literal test
> (https://opengrok.libreoffice.org/xref/core/basic/qa/basic_coverage/
> test_date_literal.vb?r=09425ab9) could be merged in this test file for
> literals.
> 
> What do you think?

Don't be fooled by 'Visual Basic' documentation content. Strictly speaking VBA and VB are different languages.

As for tests, they would greatly benefit from being moved in .VB files. This would widen the potential list of updaters or reviewers.
Comment 13 Alain Romedenne 2021-03-24 13:01:17 UTC
(In reply to Buovjaga from comment #11)
> Is there something that needs to be done here or can the status be changed
> to fixed?

As stated above tests would benefit being from being moved to .VB files whenever possible. Such requires still some C++/Basic combined approach.

Date/time literals also suffer from incomplete support but that can be addressed in a separate report.

While the topic of documenting QA test cases is not fully covered, I think that bug can be considered solved.