Vscode-cpptools: Add support for __int128_t and __uint128_t

[CharlesJu1]

I am using VS Code wiht C++ extension on Ubuntu 16.04 to navigate code. IN the following code, I got a red wiggle under print saying

identifier "print" is not defined

print is defined in eosiolib/print.hpp which is in /usr/local/include which is in the includePath and browse path in c_cpp_properties.json. When I do "go to definition on "print" , it takes me to a definition of print in boost library which does not match the signature.

In eosiolib/print.hpp, there is a line

static_assert( sizeof(long) == sizeof(int), "unexpected size difference" );

I copy that line over and added to the following code. There is a red wiggle under static_assert saying

static assertion failed with "unexpected size difference"

Is this possible the reason why the definition of print in eosiolib/print.hpp not seen by VS code? how to make VS code to ignore such assert to bring in the definition of print?

#include <eosiolib/eosio.hpp>
#include <eosiolib/print.hpp>
using namespace eosio;

class hello : public eosio::contract {
  public:
      using contract::contract;

      static_assert( sizeof(long) == sizeof(int), "unexpected size difference" );

      /// @abi action
      void hi( account_name user ) {
         require_auth( user );
         print( "Hello, ", name{user} );
      }

      void hhi( account_name user, uint64_t num) {
         require_auth( user );
         print( "Hello hhi, ", name{user}, "num is ", num );
      }
};

EOSIO_ABI( hello, (hi)(hhi) ) 

[bobbrow]

Are you building a 32-bit application? I was pretty sure that sizeof(long) == 8 and sizeof(int) == 4 for 64-bit linux applications. We only expose 64-bit IntelliSense modes right now (msvc-x64 and clang-x64) but will be supporting more flavors in the future. I wouldn't expect this static_assert to succeed with the current set of modes, but it shouldn't prevent the subsequent methods in the class from being defined.

So you're saying that print.hpp exists at /usr/local/include/eosiolib/print.hpp and /usr/local/include is in your includePath? If that's the case, then we should be able to find it. If you set the following setting: "C_Cpp.loggingLevel": "6" in your settings.json file, we will log the include path to the Output Window that we ended up using for IntelliSense when a source file is opened in the editor. Can you double check that log or paste it here?

[CharlesJu1]

This is to build an EOS smart contract, which will be run in WASM on EOS blockchain. I am not sure on WASM it is true that sizeof(long) == sizeof(int).

I set "C_Cpp.loggingLevel": "Information" in setting.json and restart VS Code. Here is the log

IntelliSense Engine = Default.
The extension will use the Tag Parser for IntelliSense when #includes don't resolve.
Autocomplete is enabled.
Error squiggles are enabled.
File exclude: **/.git
File exclude: **/.svn
File exclude: **/.hg
File exclude: **/CVS
File exclude: **/.DS_Store
File exclude: **/.vscode
Search exclude: **/node_modules
Search exclude: **/bower_components
Search exclude: **/.vscode
Code browsing service initialized
  Folder: /home/cju/eos_master_contract/hello/ will be indexed
  Folder: /home/cju/opt/boost_1_66_0/include/ will be indexed
  Folder: /usr/lib/llvm-4.0/lib/clang/4.0.0/include/ will be indexed
  Folder: /usr/local/include/ will be indexed
  Folder: /usr/include/ will be indexed
Discovering files...
Checking for syntax errors: file:///home/cju/eos_master_contract/hello/src/hello.cpp
  Processing folder (recursive): /home/cju/eos_master_contract/hello/
  Processing folder (recursive): /home/cju/opt/boost_1_66_0/include/
  Processing folder (recursive): /usr/lib/llvm-4.0/lib/clang/4.0.0/include/
  Processing folder (recursive): /usr/local/include/
  Processing folder (recursive): /usr/include/
  Discovering files: 24025 file(s) processed
  0 file(s) removed from database
Done discovering files.
Parsing open files...
Done parsing open files.
Parsing remaining files...
  Parsing: 0 files(s) processed
Done parsing remaining files.

cju@ubuntu-16-04:/usr/local/include/eosiolib$ pwd
/usr/local/include/eosiolib
cju@ubuntu-16-04:/usr/local/include/eosiolib$ ls
account.h       compiler_builtins.h  dispatcher.hpp        math.h               permission.h           real.hpp       token.hpp
account.hpp     contract.hpp         eosio.hpp             math.hpp             print.h                reflect.hpp    transaction.h
action.h        contracts.dox        eosiolib.cpp          memory.h             print.hpp              rpc.dox        transaction.hpp
action.hpp      crypto.h             fixed_key.hpp         memory.hpp           privileged.h           serialize.hpp  types.h
asset.hpp       currency.hpp         fixedpoint.hpp        multi_index.hpp      privileged.hpp         singleton.hpp  types.hpp
chain.h         datastream.hpp       generic_currency.hpp  native_currency.hpp  producer_schedule.hpp  stdlib.hpp     varint.hpp
CMakeLists.txt  db.h                 mainpage.md           optional.hpp         public_key.hpp         system.h       vector.hpp
cju@ubuntu-16-04:/usr/local/include/eosiolib$ 

[CharlesJu1]

If I right click on "print" and select "Go to definition", it will take me to a definition of print from boost library located in /home/cju/opt/boost_1_66_0/include/boost/beast/core/impl/string_param.ipp.

Here is the configuration section for Linux in c_cpp_properties.json.

{
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}",
                "/home/cju/opt/boost_1_66_0/include",
                "/usr/include/c++/5",
                "/usr/include/x86_64-linux-gnu/c++/5",
                "/usr/include/c++/5/backward",
                "/usr/lib/llvm-4.0/lib/clang/4.0.0/include",
                "/usr/local/include",
                "/usr/include/x86_64-linux-gnu",
                "/usr/include"

            ],
            "defines": [],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "${workspaceFolder}",
                    "/home/cju/opt/boost_1_66_0/include",
                    "/usr/include/c++/5",
                    "/usr/include/x86_64-linux-gnu/c++/5",
                    "/usr/include/c++/5/backward",
                    "/usr/lib/llvm-4.0/lib/clang/4.0.0/include",
                    "/usr/local/include",
                    "/usr/include/x86_64-linux-gnu",
                    "/usr/include"

                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "compilerPath": "/usr/bin/clang++-4.0",
            "cStandard": "c11",
            "cppStandard": "c++17"
        },

[CharlesJu1]

It seems to have something to do with the boost include. If I remove the boost include path, vs code can find the correct definition of print and Go to definition takes to the right place. Since I removed the boost include path, there is a green squiggly line under #include <eosiolib/eosio.hpp> saying it depends on boost and could not find header file.

[bobbrow]

I cloned this library on OSX and can see the squiggles. I'll take a look.

[bobbrow]

The problem is with 128-bit types which we don't have support for in the IntelliSense engine yet.

[sean-mcmanus]

@bobbrow Are you referring to the 128-bit int GNU extension or is this a different issue?

[bobbrow]

yes. I tried recompiling with 128-bit support, but it didn't work out of the box, so there's something else we need to do to make it work.

EDIT: adding a using uint128_t = __uint128_t; statement before including print.hpp resolved the squiggles in my special build, but I haven't determined why eosiolib is unhappy without it.

[sean-mcmanus]

@bobbrow The VS team supposedly implemented this recently, but I haven't tried their pulling in their changes yet.

[sean-mcmanus]

For 0.21.0-insiders (not released yet) we've added support for __int128_t and __uint128_t, but uint128_t needs to be defined by the user or library, i.e. using uint128_t = __uint128_t; in code or uint128_t=__uint128_t in the defines section of c_cpp_properties.json gets rid of the squiggles.

The static_assert(sizeof(long)==sizeof(int)) is still failing, but from what I see that is intentional due to the compiler defines I am receiving -- if your compiler defines for __INT_MAX__ and __LONG_MAX__ are the same and the assertion still fails, then let us know (setting the C_Cpp.loggingLevel to Debug should enable seeing those defines).

[sean-mcmanus]

Should be fixed with 0.21.0-insiders (auto installed if "C_Cpp.updateChannel": "Insiders" is set, or the offline vsix). Let us know if you find any problems with it.

[ekkis]

@sean-mcmanus could you explain how to set the feature you indicate above? I'm running VSCode 1.34.0 and have red squiggles under a uint128_t declaration

I don't think I have Insiders installed... so the real question is, when will that code be merged into production?

[sean-mcmanus]

We expect users to use using uint128_t = __uint128_t; Or add uint128_t=__uint128_t do your defines section.

[ekkis]

ah. awesome