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
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.
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.
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.
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.
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.
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.
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.
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?
Maybe this page can be of interest too: https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/constants-enums/constant-and-literal-data-types.
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.
Is there something that needs to be done here or can the status be changed to fixed?
(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.
(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.