Fix parsing of CR and CRK gates

The -Werror flag is set

Fer Grooteman reported a memory leak on libqasm, and pointed us to the code he thought this memory leak was coming from, a newed memory in src/library/libQasm.hpp that was never released.

Need to fix all compiler warnigns for V1.0

When specifying the error model, it would be very helpful we can have optionally more than one numerical parameter.

For instance, something like this:
error_model depolarizing_channel,0.003
error_model depolarizing_channel,0.003,0.004,0.003
error_model pauli_twirling_aprox,45,33

This would allow the use of several error models using the exact same syntax and it is compatible with the current syntax.

Consider the following code:

version 1.0
 
qubits 3

The second line is a single space.

This gives a syntax error. Single-space lines anywhere else seem to be accepted.

Need to have a semantic checker within the AST class?

Need to account for negative value of the iteration count of the subcircuits. -1 now gives a ridiculously large number due to the datatype.

since we use libqasm for openql testing, which is supported on Win, Linux and Mac. It is desirable to add support for Mac to libqasm as well

Remove flex bison output files from repo!

Hello!

I was wondering how I could use libqasm to get the a QASM circuit in a python data structure which I could access and operate on.

I tried:

`
from libQasm import libQasm as lq

a = lq("./test/bell.qasm") #while on the qasm_flex_bison folder
b = a.getQasmRepresentation()
`

So far so good.
But they I try to access it's methods, like numQubits, etc I can't:
b.numQubits() doesn't work, for example... The only attributes of 'b' appear to be:
b.acquire( b.append( b.disown( b.next( b.own(

Any ideas?

In the develop branch, cmake outputs:

CMake Deprecation Warning at /usr/share/cmake-3.10/Modules/UseSWIG.cmake:231 (message):
  SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
Call Stack (most recent call first):
  CMakeLists.txt:48 (SWIG_ADD_MODULE)

The following code (from line 13 in code example 3 in the cqasm 1.0 paper):

version 1.0 

qubits 5

c-x b[0],b[1],q[4]

Results in a syntax error:

  =================================================================================================== 
        _______                                                                                       
       /  ___   \   _  __      ____   ____   __  ___  __  __   __    ___  ______  ____    ___         
      /  /   /  |  | |/_/     / __/  /  _/  /  |/  / / / / /  / /   / _ |/_  __/ / __ \  / _ \        
     /  /___/  /  _>  <      _\ \   _/ /   / /|_/ / / /_/ /  / /__ / __ | / /   / /_/ / / , _/        
     \______/\__\ /_/|_|    /___/  /___/  /_/  /_/  \____/  /____//_/ |_|/_/    \____/ /_/|_|         
                                                                                                      
     version 0.2 beta - QuTech - 2018 - report bugs and suggestions to: [email protected]
  =================================================================================================== 

[+] loading circuit from '../../code.qasm' ...
error while parsing file ../../code.qasm: 
syntax error, unexpected BITHEAD, expecting NAME or QBITHEAD | Token 299 on Line: 5

We need to create the lexer input files as well as the grammar input for flex and bison respectively.

• Create .l file for flex and fill
• Create .y file for bison and fill

libqasm's equivalent to this OpenQL issue.

Current build line looks something like:

conan build . -s:h compiler.cppstd=20 -s:h libqasm/*:build_type=Release -o libqasm/*:build_tests=True -o openql/*:compat=False -b missing

As a result of the conversation for this issue that I opened, I've found out that we could turn it into something like:

conan build . -pr=conan/profiles/tests-release -b missing

Explanation (see also here):

1. If you set CMAKE_CXX_STANDARD in your project, you don't need to pass the compiler version as a command line parameter. I've noticed we were not doing that in OpenQL.
2. There is a way of not working with command line options at all, but defining them in a profile. For example, we could provide a conan/profiles folder together with the code, including a set of predefined profiles, e.g. tests-release, which would look something like:

include(default)

[settings]
libqasm/*:build_type=Release
[options]
libqasm/*:asan_enabled=False
libqasm/*:build_tests=True
libqasm/*:compat=False

And then just compile with conan build . -pr=conan/profiles/tests-release.

Or, these profiles may be copied to the ~./conan2/profiles folder, e.g. for this case, with a name such as libqasm-tests-release, and then build with conan build . -pr=libqasm-tests-release.

getQubitsInvolved is confusing as it only applies to single qubit operations. Check to see if function name can be overloaded depending on the return type (unlikely). If not possible, then change the function name to reflect appropriately.

See this related issue as a trigger for this: QuTech-Delft/qx-simulator#32

The keyword load_state is useful and should be supported by the parser since a user might not want to have to recreate the entire state from the different qubit operations. It's easier to just load from a file.

At the moment:

1. *.cq and *.golden.txt have CRLF endings, and
2. *.actual.txt files are written out in text mode (see libqasm/src/tests/v1-parsing.cpp, write_file method. That means that, depending on the OS, LF or CRLF will be written out as line endings (for Unix or Windows respectively).
3. It is important to notice that some *.cq files are used as input when writing out *.actual.txt files.

test-v1-parsing basically:

• Builds a string, and writes it out as an *.actual.txt file,
• then reads a *.golden.txt file into another string, and, finally
• checks whether both strings are the same.

Line endings shouldn't be a problem because, independently from the OS, an LF or CRLF should be read in as a \n. I understand that's why tests are currently working in Linux/macos (which use LF).

However, when running the tests in a WSL environment, the comparisons fail.

I have a fix for this which consists of:

1. Writing out *.actual.txt in binary mode (so LF is always written).
2. Changing all *.cq and *.golden.txt files to LF line endings.

But, before carrying on with the fix, I have to understand what's the issue with WSL.

The error was displayed in older versions, with the exit(), but the recent version that throws an exception does not include this info in the exception.

A suggestion for a future version of QASM (from our front-end team):

When you define a sub circuit it can only be terminated by defining a new sub circuit. This is a strange restriction. A more obvious choice would be to 1) indent the commands that are part of the subcircuit or 2) to use accolades {…} to define the sub circuit.

With the cQASM paper, there are many code examples which should be valid. They can be part of a test suite to ensure that the library is parsing correctly.

This will be done only after the library is completed.

A suggestion for a future version of QASM (from our front-end team):

• I personally would prefer lines to end with semicolons ; especially because it makes long lines that span multiple rows in a small window (like our editor) better readable

compiler::SubCircuits subcircuits_object holds the state which is declared globally in grammar.y. This results in the stateful behavior which causes problem when library is used to load cqasm file multiple times.

The semantic checker is far from complete. We need to make sure the semantic checker does:

• Check that operations are having correct vector lengths.
• Check that keywords are not used as maps.
• Provide clearer exception messages for the user.

What are the valid ones?

Should just:

version 1.0
qubits 10

parse or fail?

Need to make sure there's a grammar file so that developers in the future can look into this document and have the syntax settled. Helps create the parser via flex, bison.

version 1.0
qubits 8

error_model depolarizing_channel, 0

will result in syntax error on line 4:

syntax error, unexpected INTEGER, expecting FLOAT | Token 260 on Line: 4

We know that the library builds ok with Linux systems, but still need to test it with Windows. We'll know for sure once we have a unit testing framework.

On the develop branch, this input:

version 1.0

qubits 2 # foo

gives this output:

Path to QASM file = test.qc
Error syntax error, unexpected WS, expecting NEWLINE | Token 272 on Line: 3

Removing the # foo results in a parseable file again.

Comments should be allowed after a qubits line.

Need to discuss with @quantumkoen for fixing the warnings. This can't be done very easily at least from what I can see.

One of the use cases of libqasm it to verify if a file generated by a tool (for instance openql) conforms to the specifications. A convenient way to do that will be to have a simple interface to libqasm where it can be installed as a package and provides a simple API, for instance libqasm.assemble(qasmfile) which can be used to test if a given file can be assembled or not.

P.S. it might be useful to have a look at openql, or qxelerator to see how they provide the python interface. A more specific example can be qisa-as which has a similar API and is being used in unit-tests by openql to verify the generated QISA files for CCLight.

Many people in the QCA group are running CentOS 6 or 7 systems, which provide CMake 2.8.12. Requiring 3.12 as per #117 is therefore not reasonable.

This code:

version 1.0
# cqasm generated by QI backend for QisKit
qubits 2
Rz q[0], 1.
.measurement
   measure q[0]

results in:

  =================================================================================================== 
        _______                                                                                       
       /  ___   \   _  __      ____   ____   __  ___  __  __   __    ___  ______  ____    ___         
      /  /   /  |  | |/_/     / __/  /  _/  /  |/  / / / / /  / /   / _ |/_  __/ / __ \  / _ \        
     /  /___/  /  _>  <      _\ \   _/ /   / /|_/ / / /_/ /  / /__ / __ | / /   / /_/ / / , _/        
     \______/\__\ /_/|_|    /___/  /___/  /_/  /_/  \____/  /____//_/ |_|/_/    \____/ /_/|_|         
                                                                                                      
     version 0.1 beta - QuTech - 2016 - report bugs and suggestions to: [email protected]     
  =================================================================================================== 

[+] loading circuit from 'test3.qc' ...
Error while parsing file test3.qc: 
syntax error, unexpected INTEGER, expecting FLOAT | Token 260 on Line: 4

The expression 1. is by most programming languages etc considered to be a valid float specification.

Same for x[0,1,2,3] etc.. it seems to only work in the first one in the range. Consider this code:

version 1.0

qubits 5

prep_z q[0:4]

x q[0,1,2,3]

measure_all
display

The measurement result is:

[>>] measurement register  :  | 0 | 0 | 0 | 0 | 1 |

While we would expect 01111 instead. Also tested with measure q[0,1,2,3], which only measures q[0]

This code from the qx simulator test suite is not parsed:

version 1.0 

# file   : full_adder.qc
# author : Nader Khammassi
# brief  : quantum full adder (carry-save addition)

# define 4 qubits
qubits 4

# rename qubits
map q[0],A 
map q[1],B
map q[2],C
map q[3],D


# init inputs to some values
.init
  x A 
  x C 

  display_binary  #  initial input value


# perform addition
.add

  toffoli B,C,D
  cnot    B,C 
  toffoli A,C,D
  cnot    A,C 

  display_binary #  result

.reverse_add

  cnot    A,C 
  toffoli A,C,D
  cnot    B,C 
  toffoli B,C,D

  display_binary #  result

# error_model depolarizing_channel, 0.1 

Reports:

[+] loading circuit from 'tests/circuits/full_adder.qc' ...
Error while parsing file tests/circuits/full_adder.qc: 
syntax error, unexpected BITHEAD, expecting NAME

please remove bin directory from commits. it will be nice to make clean your code which should remove this bin directory and other temporary files to avoid adding them to commit. It is also a good practive to add .gitignore file to your project.

In case of syntax/semantic errors, the error message indicates the type of the error but not its location. it would be very helpful to indicate the location of the error (line and position) whenever the parsing fails to help debugging the QASM code and testing QX.

For example, in this message, we see the type of the error but not its location:

[+] loading circuit from 'test.qc' ...
error while parsing file test.qc: 
syntax error, unexpected QBITHEAD, expecting NAME or BITHEAD

It will be useful to add README.md file expaling a bit the tool, its setup and basic usage.

Consider this input:

version 1.0 

# foo 
# bar

qubits 2

.entangle
  H q[0]
  CNOT q[0], q[1]
  measure_all
.ma3ae5408346341c4ac42640e358fbacb
display

This results in this output:

  =================================================================================================== 
        _______                                                                                       
       /  ___   \   _  __      ____   ____   __  ___  __  __   __    ___  ______  ____    ___         
      /  /   /  |  | |/_/     / __/  /  _/  /  |/  / / / / /  / /   / _ |/_  __/ / __ \  / _ \        
     /  /___/  /  _>  <      _\ \   _/ /   / /|_/ / / /_/ /  / /__ / __ | / /   / /_/ / / , _/        
     \______/\__\ /_/|_|    /___/  /___/  /_/  /_/  \____/  /____//_/ |_|/_/    \____/ /_/|_|         
                                                                                                      
     version 0.1 beta - QuTech - 2016 - report bugs and suggestions to: [email protected]     
  =================================================================================================== 

[+] loading circuit from '/tmp/test2.qc' ...
Error syntax error, unexpected COMMENT, expecting QUBITS | Token 274 on Line: 6

Removing line 4 fixes the error.

I'd expect to be able to run something like make test to run an automated test-suite (using some c++ unit testing framework) that checks that valid qasm compiles, and invalid qasm results in syntax errors. This can then also be part of the CI/CD to have a quality gate for PR's.

The display_binary operation needs to be supported. This is so that the entire state of the qubit does not need to be displayed when a user writes display_binary instead.

cmake fails with:
CMake Error at /usr/share/cmake-3.10/Modules/UseSWIG.cmake:247 (message):
SWIG_ADD_LIBRARY: Missing LANGUAGE argument

this can be resolved by changing line 83 to:
SWIG_ADD_LIBRARY(libQasm LANGUAGE python SOURCES libqasm_swig.i)

Then you start seeing problem:
#include "doctest/doctest.h"
^
compilation terminated.
CMakeFiles/testqc.dir/build.make:62: recipe for target 'CMakeFiles/testqc.dir/home/iashraf/repositories/quantRepos/libqasm/qasm_flex_bison/test/testqc.cpp.o' failed
make[2]: *** [CMakeFiles/testqc.dir/home/iashraf/repositories/quantRepos/libqasm/qasm_flex_bison/test/testqc.cpp.o] Error 1
CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/testqc.dir/all' failed
make[1]: *** [CMakeFiles/testqc.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Discussions with Nader today created a need for custom unitary gate support. E.g.:

U q[0], mat00_real, mat00_imag, mat01..., mat10,... mat11

may be its a good idea to use cmake for building library.

Consider this input:

version 1.0

qubits 2

error_model depolarizing_channel, 0.001

Results in a syntax error:

Path to QASM file = test.qc
Error syntax error, unexpected NAME, expecting $end | Token 259 on Line: 5

It should be parsed and supported by qx simulator (and ignored by openql as was previously the case).

QX simulator parses things like error_model depolarizing_channel, 0.001, which is illegal in QASM 1.0 according to the definition. It would be good to extend the language with a #pragma-like construction (as seen in c/c++), that can be used to define syntactically valid implementation-specific instructions. If an implementation does not support the particular pragma, it can safely ignore it.