Wiki

Ticket #29 (assigned enhancement)

Opened 16 years ago

Last modified 15 years ago

Support other types of integer literals, and underscores

Reported by: Chuck Owned by: Chuck
Priority: minor Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:

Description

"0o" for octal.
"0b" for binary.
Support underscore separators in integer literals regardless of their base. This is already supported in the "standard" integer literals like "1_000_000".

Attachments

binOctLit.patch Download (16.7 KB) - added by hopscc 16 years ago.
hunk2 Download (3.2 KB) - added by hopscc 16 years ago.

Change History

Changed 16 years ago by hopscc

see Discussion  AnyOne for a Hex and closed Ticket#28

Changed 16 years ago by hopscc

  • owner set to Chuck
  • status changed from new to assigned

patch for binary and octal literals, _ separators in such lits.
Changes to hex lit support. Tests and IntRelNotes updates.

Provides both signed and unsigned support.
Syntax changed from orig in hexLits
literal must specify both size and sign ( _?(u|i)(8|16|32|64)?
previously could specify just size (_?(8|16|32|64)

Changed 16 years ago by hopscc

Changed 16 years ago by Chuck

  • owner changed from Chuck to hopscc

Patch application failed. Maybe do a "svn up" and try again? Or apply the fix you discovered previously?

>patch -p0 -i binOctLit.patch
patching file Source/CobraTokenizer.cobra
Hunk #2 succeeded at 476 (offset -103 lines).
Hunk #3 FAILED at 489.
1 out of 3 hunks FAILED -- saving rejects to file Source/CobraTokenizer.cobra.rej
patching file Tests/100-basics/922-bin-lit.cobra
patching file Tests/100-basics/920-hex-lit.cobra
patching file Tests/100-basics/924-oct-lit.cobra
patching file Developer/IntermediateReleaseNotes.text

I looked at the "reject" file, but didn't get a clue as to the problem. Also, there was too much in there to apply by hand.

I'm on Windows, fyi.

Changed 16 years ago by hopscc

It was generated against an up to date tree last night and pretested fine against that. (also on WIndows) - (I 've been the applying the workround and pretesting before posting the patch)

Strange: I just downloaded it and ran it against a clean tree here and it patched fine.

  > svn st -u
  ?                   Source\mkcobc
  ?                   Source\mktests
  ?                   Source\CobraInfo.cs  
  ?                   Source\Snapshot\CobraInfo.cs
  ?                   binOctLit.patch
  Status against revision:   1551

  > patch -p0 -i binOctLit.patch
  patching file Source/CobraTokenizer.cobra
  patching file Tests/100-basics/922-bin-lit.cobra
  patching file Tests/100-basics/920-hex-lit.cobra
  patching file Tests/100-basics/924-oct-lit.cobra
  patching file Developer/IntermediateReleaseNotes.text
  > svn st
  ?      binOctLit.patch
  ?      Source\mkcobc
  ?      Source\mktests
  ?      Source\CobraInfo.cs
  ?      Source\Snapshot\CobraInfo.cs
  M      Source\CobraTokenizer.cobra
  ?      Tests\100-basics\922-bin-lit.cobra
  ?      Tests\100-basics\924-oct-lit.cobra
  M      Tests\100-basics\920-hex-lit.cobra
  M      Developer\IntermediateReleaseNotes.text
  >

What happened to hunk#1
Thats an awfully big offset for hunk #2 against a clean tree (103 lines back
-thats starting that hunk at about line 470 ??)
what happened to the previous 100 lines in CobraTokenizer??

I can give you a verbatim cut of the failing hunk as separate text if you like - its pretty much an insertion of code anyway

Changed 16 years ago by hopscc

Changed 16 years ago by hopscc

  • owner changed from hopscc to Chuck

heres hunk#2 anyway.

Changed 16 years ago by hopscc

OOps - while named hunk2 it actually contains hunk3 - the one that failed...

Changed 15 years ago by hopscc

Touch to raise into last 50

Note: See TracTickets for help on using tickets.