diff --git a/1_Set up job.txt b/1_Set up job.txt index 6ba6e94..8a81393 100644 --- a/1_Set up job.txt +++ b/1_Set up job.txt @@ -1,27 +1,27 @@ -2023-05-01T12:14:22.2302731Z Current runner version: '2.303.0' -2023-05-01T12:14:22.2339918Z ##[group]Operating System -2023-05-01T12:14:22.2340428Z Ubuntu -2023-05-01T12:14:22.2340709Z 22.04.2 -2023-05-01T12:14:22.2340964Z LTS -2023-05-01T12:14:22.2341181Z ##[endgroup] -2023-05-01T12:14:22.2342941Z ##[group]Runner Image -2023-05-01T12:14:22.2343539Z Image: ubuntu-22.04 -2023-05-01T12:14:22.2343872Z Version: 20230426.1 -2023-05-01T12:14:22.2344494Z Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230426.1/images/linux/Ubuntu2204-Readme.md -2023-05-01T12:14:22.2345356Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230426.1 -2023-05-01T12:14:22.2346008Z ##[endgroup] -2023-05-01T12:14:22.2346730Z ##[group]Runner Image Provisioner -2023-05-01T12:14:22.2347046Z 2.0.161.1 -2023-05-01T12:14:22.2347276Z ##[endgroup] -2023-05-01T12:14:22.2348142Z ##[group]GITHUB_TOKEN Permissions -2023-05-01T12:14:22.2348685Z Contents: read -2023-05-01T12:14:22.2348977Z Metadata: read -2023-05-01T12:14:22.2349211Z Packages: read -2023-05-01T12:14:22.2350092Z ##[endgroup] -2023-05-01T12:14:22.2355622Z Secret source: Actions -2023-05-01T12:14:22.2356294Z Prepare workflow directory -2023-05-01T12:14:22.3288963Z Prepare all required actions -2023-05-01T12:14:22.3515802Z Getting action download info -2023-05-01T12:14:22.5979855Z Download action repository 'actions/checkout@v2' (SHA:ee0669bd1cc54295c223e0bb666b733df41de1c5) -2023-05-01T12:14:23.2864873Z Download action repository 'excitedleigh/setup-nox@v2.0.0' (SHA:38c698655f40d5fe659b8589764ed04ee36d0414) -2023-05-01T12:14:23.8683710Z Complete job name: Run Nox (multi_version-3.6) +2023-05-01T12:14:21.5670685Z Current runner version: '2.303.0' +2023-05-01T12:14:21.5699172Z ##[group]Operating System +2023-05-01T12:14:21.5699773Z Ubuntu +2023-05-01T12:14:21.5700035Z 22.04.2 +2023-05-01T12:14:21.5700354Z LTS +2023-05-01T12:14:21.5700773Z ##[endgroup] +2023-05-01T12:14:21.5701051Z ##[group]Runner Image +2023-05-01T12:14:21.5701403Z Image: ubuntu-22.04 +2023-05-01T12:14:21.5701730Z Version: 20230426.1 +2023-05-01T12:14:21.5702199Z Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230426.1/images/linux/Ubuntu2204-Readme.md +2023-05-01T12:14:21.5702897Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230426.1 +2023-05-01T12:14:21.5703342Z ##[endgroup] +2023-05-01T12:14:21.5703692Z ##[group]Runner Image Provisioner +2023-05-01T12:14:21.5703983Z 2.0.161.1 +2023-05-01T12:14:21.5704318Z ##[endgroup] +2023-05-01T12:14:21.5704960Z ##[group]GITHUB_TOKEN Permissions +2023-05-01T12:14:21.5705496Z Contents: read +2023-05-01T12:14:21.5705822Z Metadata: read +2023-05-01T12:14:21.5706188Z Packages: read +2023-05-01T12:14:21.5706806Z ##[endgroup] +2023-05-01T12:14:21.5710518Z Secret source: Actions +2023-05-01T12:14:21.5711065Z Prepare workflow directory +2023-05-01T12:14:21.6434871Z Prepare all required actions +2023-05-01T12:14:21.6620142Z Getting action download info +2023-05-01T12:14:21.8388715Z Download action repository 'actions/checkout@v2' (SHA:ee0669bd1cc54295c223e0bb666b733df41de1c5) +2023-05-01T12:14:22.1836478Z Download action repository 'excitedleigh/setup-nox@v2.0.0' (SHA:38c698655f40d5fe659b8589764ed04ee36d0414) +2023-05-01T12:14:22.5120337Z Complete job name: Run Nox (parametrized_display_name(one)) diff --git a/2_Pull.ghcr.ioactionsjekyll-build-pagesv1.0.8.txt b/2_Pull.ghcr.ioactionsjekyll-build-pagesv1.0.8.txt deleted file mode 100644 index ff1e984..0000000 --- a/2_Pull.ghcr.ioactionsjekyll-build-pagesv1.0.8.txt +++ /dev/null @@ -1,54 +0,0 @@ -2023-07-28T08:03:52.6370583Z ##[group]Pull down action image 'ghcr.io/actions/jekyll-build-pages:v1.0.8' -2023-07-28T08:03:52.6462771Z ##[command]/usr/bin/docker pull ghcr.io/actions/jekyll-build-pages:v1.0.8 -2023-07-28T08:03:53.6522772Z v1.0.8: Pulling from actions/jekyll-build-pages -2023-07-28T08:03:53.6524365Z eff15d958d66: Pulling fs layer -2023-07-28T08:03:53.6524679Z 923e91ae3a1b: Pulling fs layer -2023-07-28T08:03:53.6524957Z 2aa5d3a4a151: Pulling fs layer -2023-07-28T08:03:53.6525233Z bc64adf2d0b2: Pulling fs layer -2023-07-28T08:03:53.6525511Z bfc5cca7d80e: Pulling fs layer -2023-07-28T08:03:53.6525875Z bc64adf2d0b2: Waiting -2023-07-28T08:03:53.6526182Z 89be6ec64867: Pulling fs layer -2023-07-28T08:03:53.6526497Z ffeaef3959d6: Pulling fs layer -2023-07-28T08:03:53.6526759Z bfc5cca7d80e: Waiting -2023-07-28T08:03:53.6526991Z 89be6ec64867: Waiting -2023-07-28T08:03:53.6527243Z 06513ce512f4: Pulling fs layer -2023-07-28T08:03:53.6527511Z 933a637e20a3: Pulling fs layer -2023-07-28T08:03:53.6527798Z 2bc7b2c3bae9: Pulling fs layer -2023-07-28T08:03:53.6528128Z ffeaef3959d6: Waiting -2023-07-28T08:03:53.6528365Z 06513ce512f4: Waiting -2023-07-28T08:03:53.6528592Z 933a637e20a3: Waiting -2023-07-28T08:03:53.6528808Z 2bc7b2c3bae9: Waiting -2023-07-28T08:03:53.8473644Z 2aa5d3a4a151: Verifying Checksum -2023-07-28T08:03:53.8474298Z 2aa5d3a4a151: Download complete -2023-07-28T08:03:53.9262109Z 923e91ae3a1b: Verifying Checksum -2023-07-28T08:03:53.9265522Z 923e91ae3a1b: Download complete -2023-07-28T08:03:54.0987479Z eff15d958d66: Verifying Checksum -2023-07-28T08:03:54.0996986Z eff15d958d66: Download complete -2023-07-28T08:03:54.1464955Z bfc5cca7d80e: Verifying Checksum -2023-07-28T08:03:54.1478385Z bfc5cca7d80e: Download complete -2023-07-28T08:03:54.2482660Z bc64adf2d0b2: Verifying Checksum -2023-07-28T08:03:54.2523988Z bc64adf2d0b2: Download complete -2023-07-28T08:03:54.3339963Z ffeaef3959d6: Verifying Checksum -2023-07-28T08:03:54.3348452Z ffeaef3959d6: Download complete -2023-07-28T08:03:54.6146480Z 933a637e20a3: Verifying Checksum -2023-07-28T08:03:54.6152742Z 933a637e20a3: Download complete -2023-07-28T08:03:54.8836197Z 2bc7b2c3bae9: Verifying Checksum -2023-07-28T08:03:54.8837499Z 2bc7b2c3bae9: Download complete -2023-07-28T08:03:54.9101377Z 06513ce512f4: Verifying Checksum -2023-07-28T08:03:54.9101996Z 06513ce512f4: Download complete -2023-07-28T08:03:55.6461568Z 89be6ec64867: Verifying Checksum -2023-07-28T08:03:55.6466645Z 89be6ec64867: Download complete -2023-07-28T08:03:56.3544953Z eff15d958d66: Pull complete -2023-07-28T08:03:58.5284793Z 923e91ae3a1b: Pull complete -2023-07-28T08:03:58.5942221Z 2aa5d3a4a151: Pull complete -2023-07-28T08:03:59.3712762Z bc64adf2d0b2: Pull complete -2023-07-28T08:03:59.4389604Z bfc5cca7d80e: Pull complete -2023-07-28T08:04:06.0600747Z 89be6ec64867: Pull complete -2023-07-28T08:04:06.1301915Z ffeaef3959d6: Pull complete -2023-07-28T08:04:08.8109355Z 06513ce512f4: Pull complete -2023-07-28T08:04:08.9182679Z 933a637e20a3: Pull complete -2023-07-28T08:04:08.9831781Z 2bc7b2c3bae9: Pull complete -2023-07-28T08:04:08.9896186Z Digest: sha256:0acf1ae6395c949f82958789a80606717fb3c50f0266e91cffad09f513cdec78 -2023-07-28T08:04:08.9924365Z Status: Downloaded newer image for ghcr.io/actions/jekyll-build-pages:v1.0.8 -2023-07-28T08:04:08.9977380Z ghcr.io/actions/jekyll-build-pages:v1.0.8 -2023-07-28T08:04:09.0006280Z ##[endgroup] diff --git a/3_Setup Pages.txt b/3_Setup Pages.txt deleted file mode 100644 index dd3a613..0000000 --- a/3_Setup Pages.txt +++ /dev/null @@ -1,5 +0,0 @@ -2023-06-18T05:09:25.0168062Z ##[group]Run actions/configure-pages@v3 -2023-06-18T05:09:25.0168312Z with: -2023-06-18T05:09:25.0168711Z token: *** -2023-06-18T05:09:25.0168920Z enablement: false -2023-06-18T05:09:25.0169106Z ##[endgroup] diff --git a/4_Setup Pages.txt b/4_Setup Pages.txt deleted file mode 100644 index 00eae31..0000000 --- a/4_Setup Pages.txt +++ /dev/null @@ -1,5 +0,0 @@ -2023-07-28T08:04:10.1158737Z ##[group]Run actions/configure-pages@v3 -2023-07-28T08:04:10.1159029Z with: -2023-07-28T08:04:10.1159362Z token: *** -2023-07-28T08:04:10.1159582Z enablement: false -2023-07-28T08:04:10.1159784Z ##[endgroup] diff --git a/5_Build with Jekyll.txt b/5_Build with Jekyll.txt deleted file mode 100644 index 3b6ab17..0000000 --- a/5_Build with Jekyll.txt +++ /dev/null @@ -1,58 +0,0 @@ -2023-07-28T08:04:10.5197293Z ##[group]Run actions/jekyll-build-pages@v1 -2023-07-28T08:04:10.5197650Z with: -2023-07-28T08:04:10.5197845Z source: ./ -2023-07-28T08:04:10.5198067Z destination: ./_site -2023-07-28T08:04:10.5198292Z future: false -2023-07-28T08:04:10.5198558Z build_revision: 4c8b6c268367cac64bf6cd5f56faca7a791d011a -2023-07-28T08:04:10.5198838Z verbose: true -2023-07-28T08:04:10.5199192Z token: *** -2023-07-28T08:04:10.5199393Z env: -2023-07-28T08:04:10.5199602Z GITHUB_PAGES: true -2023-07-28T08:04:10.5199819Z ##[endgroup] -2023-07-28T08:04:10.5501963Z ##[command]/usr/bin/docker run --name ghcrioactionsjekyllbuildpagesv108_16c888 --label 5bedb4 --workdir /github/workspace --rm -e "GITHUB_PAGES" -e "INPUT_SOURCE" -e "INPUT_DESTINATION" -e "INPUT_FUTURE" -e "INPUT_BUILD_REVISION" -e "INPUT_VERBOSE" -e "INPUT_TOKEN" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_ID_TOKEN_REQUEST_URL" -e "ACTIONS_ID_TOKEN_REQUEST_TOKEN" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/Devlynnx.GitHub.io/Devlynnx.GitHub.io":"/github/workspace" ghcr.io/actions/jekyll-build-pages:v1.0.8 -2023-07-28T08:04:11.8666369Z Configuration file: none -2023-07-28T08:04:11.8881566Z Logging at level: debug -2023-07-28T08:04:11.8882456Z GitHub Pages: github-pages v228 -2023-07-28T08:04:11.8883168Z GitHub Pages: jekyll v3.9.3 -2023-07-28T08:04:11.8884028Z Theme: jekyll-theme-primer -2023-07-28T08:04:11.8884571Z Theme source: /usr/local/bundle/gems/jekyll-theme-primer-0.6.0 -2023-07-28T08:04:11.8885007Z Requiring: jekyll-github-metadata -2023-07-28T08:04:11.9917894Z To use retry middleware with Faraday v2.0+, install `faraday-retry` gem -2023-07-28T08:04:14.5504901Z Requiring: jekyll-seo-tag -2023-07-28T08:04:14.5505646Z Requiring: jekyll-coffeescript -2023-07-28T08:04:14.5506280Z Requiring: jekyll-commonmark-ghpages -2023-07-28T08:04:14.5507519Z Requiring: jekyll-gist -2023-07-28T08:04:14.5507860Z Requiring: jekyll-github-metadata -2023-07-28T08:04:14.5508266Z Requiring: jekyll-paginate -2023-07-28T08:04:14.5508737Z Requiring: jekyll-relative-links -2023-07-28T08:04:14.5509305Z Requiring: jekyll-optional-front-matter -2023-07-28T08:04:14.5509694Z Requiring: jekyll-readme-index -2023-07-28T08:04:14.5510067Z Requiring: jekyll-default-layout -2023-07-28T08:04:14.5510453Z Requiring: jekyll-titles-from-headings -2023-07-28T08:04:14.5510781Z GitHub Metadata: Initializing... -2023-07-28T08:04:14.5511083Z Source: /github/workspace/./ -2023-07-28T08:04:14.5511378Z Destination: /github/workspace/./_site -2023-07-28T08:04:14.5511809Z Incremental build: disabled. Enable with --incremental -2023-07-28T08:04:14.5512118Z Generating... -2023-07-28T08:04:14.5531197Z Generating: JekyllOptionalFrontMatter::Generator finished in 0.000145801 seconds. -2023-07-28T08:04:14.5532087Z Generating: JekyllReadmeIndex::Generator finished in 0.002074713 seconds. -2023-07-28T08:04:14.5532695Z Generating: Jekyll::Paginate::Pagination finished in 4.2e-06 seconds. -2023-07-28T08:04:14.5533218Z Generating: JekyllRelativeLinks::Generator finished in 2.79e-05 seconds. -2023-07-28T08:04:14.5533718Z Generating: JekyllDefaultLayout::Generator finished in 8.27e-05 seconds. -2023-07-28T08:04:14.5534251Z Generating: JekyllTitlesFromHeadings::Generator finished in 2.71e-05 seconds. -2023-07-28T08:04:14.5534617Z Rendering: assets/css/style.scss -2023-07-28T08:04:14.5534980Z Pre-Render Hooks: assets/css/style.scss -2023-07-28T08:04:14.5535274Z Rendering Markup: assets/css/style.scss -2023-07-28T08:04:14.5535752Z Rendering: README.md -2023-07-28T08:04:14.5536298Z Pre-Render Hooks: README.md -2023-07-28T08:04:14.5536561Z Rendering Markup: README.md -2023-07-28T08:04:14.5536917Z Requiring: kramdown-parser-gfm -2023-07-28T08:04:14.5537585Z Rendering Layout: README.md -2023-07-28T08:04:14.5537832Z Layout source: theme -2023-07-28T08:04:14.5538221Z GitHub Metadata: Generating for devlynnx/Devlynnx.GitHub.io -2023-07-28T08:04:14.5538895Z GitHub Metadata: Calling @client.repository("devlynnx/Devlynnx.GitHub.io", {:accept=>"application/vnd.github.drax-preview+json"}) -2023-07-28T08:04:14.5539437Z GitHub Metadata: Calling @client.pages("devlynnx/Devlynnx.GitHub.io", {}) -2023-07-28T08:04:14.5540497Z Writing: /github/workspace/_site/assets/css/style.css -2023-07-28T08:04:14.5540973Z Writing: /github/workspace/_site/index.html -2023-07-28T08:04:14.5541333Z done in 2.202 seconds. -2023-07-28T08:04:14.5541758Z Auto-regeneration: disabled. Use --watch to enable. diff --git a/6_Upload artifact.txt b/6_Upload artifact.txt deleted file mode 100644 index 762cca0..0000000 --- a/6_Upload artifact.txt +++ /dev/null @@ -1,84 +0,0 @@ -2023-07-28T08:04:14.7243950Z ##[group]Run actions/upload-pages-artifact@v1 -2023-07-28T08:04:14.7244292Z with: -2023-07-28T08:04:14.7244486Z name: github-pages -2023-07-28T08:04:14.7244708Z path: _site/ -2023-07-28T08:04:14.7244923Z retention-days: 1 -2023-07-28T08:04:14.7245127Z env: -2023-07-28T08:04:14.7245325Z GITHUB_PAGES: true -2023-07-28T08:04:14.7245538Z ##[endgroup] -2023-07-28T08:04:14.7601414Z ##[group]Run chmod -c -R +rX "$INPUT_PATH" | while read line; do -2023-07-28T08:04:14.7602672Z chmod -c -R +rX "$INPUT_PATH" | while read line; do -2023-07-28T08:04:14.7603107Z  echo "::warning title=Invalid file permissions automatically fixed::$line" -2023-07-28T08:04:14.7603446Z done -2023-07-28T08:04:14.7603653Z tar \ -2023-07-28T08:04:14.7603939Z  --dereference --hard-dereference \ -2023-07-28T08:04:14.7604259Z  --directory "$INPUT_PATH" \ -2023-07-28T08:04:14.7604551Z  -cvf "$RUNNER_TEMP/artifact.tar" \ -2023-07-28T08:04:14.7604842Z  --exclude=.git \ -2023-07-28T08:04:14.7605161Z  --exclude=.github \ -2023-07-28T08:04:14.7605404Z  . -2023-07-28T08:04:14.7673243Z shell: /usr/bin/sh -e {0} -2023-07-28T08:04:14.7673503Z env: -2023-07-28T08:04:14.7674052Z GITHUB_PAGES: true -2023-07-28T08:04:14.7674270Z INPUT_PATH: _site/ -2023-07-28T08:04:14.7674482Z ##[endgroup] -2023-07-28T08:04:14.7862220Z chmod: changing permissions of '_site/': Operation not permitted -2023-07-28T08:04:14.7864983Z chmod: changing permissions of '_site/index.html': Operation not permitted -2023-07-28T08:04:14.7876456Z chmod: changing permissions of '_site/1_Set up job.txt': Operation not permitted -2023-07-28T08:04:14.7877049Z chmod: changing permissions of '_site/events (4).json': Operation not permitted -2023-07-28T08:04:14.7877955Z chmod: changing permissions of '_site/astro.yml.txt': Operation not permitted -2023-07-28T08:04:14.7878477Z chmod: changing permissions of '_site/events (1).json': Operation not permitted -2023-07-28T08:04:14.7879014Z chmod: changing permissions of '_site/1_Get Matrix.txt': Operation not permitted -2023-07-28T08:04:14.7879560Z chmod: changing permissions of '_site/meta.json': Operation not permitted -2023-07-28T08:04:14.7881092Z chmod: changing permissions of '_site/4_Run session.txt': Operation not permitted -2023-07-28T08:04:14.7881682Z chmod: changing permissions of '_site/events.json': Operation not permitted -2023-07-28T08:04:14.7882233Z chmod: changing permissions of '_site/events (3).json': Operation not permitted -2023-07-28T08:04:14.7882751Z chmod: changing permissions of '_site/README.md': Operation not permitted -2023-07-28T08:04:14.7883276Z chmod: changing permissions of '_site/github-pages.zip': Operation not permitted -2023-07-28T08:04:14.7883804Z chmod: changing permissions of '_site/assets': Operation not permitted -2023-07-28T08:04:14.7884313Z chmod: changing permissions of '_site/assets/css': Operation not permitted -2023-07-28T08:04:14.7884828Z chmod: changing permissions of '_site/assets/css/style.css': Operation not permitted -2023-07-28T08:04:14.7885373Z chmod: changing permissions of '_site/events (2).json': Operation not permitted -2023-07-28T08:04:14.7885888Z chmod: changing permissions of '_site/index.json': Operation not permitted -2023-07-28T08:04:14.7917727Z ./ -2023-07-28T08:04:14.7918018Z ./index.html -2023-07-28T08:04:14.7918259Z ./1_Set up job.txt -2023-07-28T08:04:14.7918492Z ./events (4).json -2023-07-28T08:04:14.7918708Z ./astro.yml.txt -2023-07-28T08:04:14.7918935Z ./events (1).json -2023-07-28T08:04:14.7919161Z ./1_Get Matrix.txt -2023-07-28T08:04:14.7919365Z ./meta.json -2023-07-28T08:04:14.7919587Z ./4_Run session.txt -2023-07-28T08:04:14.7919812Z ./events.json -2023-07-28T08:04:14.7920018Z ./events (3).json -2023-07-28T08:04:14.7920239Z ./README.md -2023-07-28T08:04:14.7920593Z ./github-pages.zip -2023-07-28T08:04:14.7920815Z ./assets/ -2023-07-28T08:04:14.7921028Z ./assets/css/ -2023-07-28T08:04:14.7921256Z ./assets/css/style.css -2023-07-28T08:04:14.7921477Z ./events (2).json -2023-07-28T08:04:14.7921698Z ./index.json -2023-07-28T08:04:14.8041076Z ##[group]Run actions/upload-artifact@v3 -2023-07-28T08:04:14.8041368Z with: -2023-07-28T08:04:14.8041582Z name: github-pages -2023-07-28T08:04:14.8041871Z path: /home/runner/work/_temp/artifact.tar -2023-07-28T08:04:14.8042173Z retention-days: 1 -2023-07-28T08:04:14.8042448Z if-no-files-found: error -2023-07-28T08:04:14.8042675Z env: -2023-07-28T08:04:14.8042896Z GITHUB_PAGES: true -2023-07-28T08:04:14.8043285Z ##[endgroup] -2023-07-28T08:04:14.8999083Z With the provided path, there will be 1 file uploaded -2023-07-28T08:04:14.9004854Z Starting artifact upload -2023-07-28T08:04:14.9005953Z For more detailed logs during the artifact upload process, enable step-debugging: https://docs.github.com/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging -2023-07-28T08:04:14.9006642Z Artifact name is valid! -2023-07-28T08:04:15.0360013Z Container for artifact "github-pages" successfully created. Starting upload of file(s) -2023-07-28T08:04:15.2760184Z Total size of all the files uploaded is 90747 bytes -2023-07-28T08:04:15.2764896Z File upload process has finished. Finalizing the artifact upload -2023-07-28T08:04:15.3773539Z Artifact has been finalized. All files have been successfully uploaded! -2023-07-28T08:04:15.3774798Z -2023-07-28T08:04:15.3778357Z The raw size of all the files that were specified for upload is 727040 bytes -2023-07-28T08:04:15.3779389Z The size of all the files that were uploaded is 90747 bytes. This takes into account any gzip compression used to reduce the upload size, time and storage -2023-07-28T08:04:15.3780487Z -2023-07-28T08:04:15.3821188Z Note: The size of downloaded zips can differ significantly from the reported size. For more information see: https://github.com/actions/upload-artifact#zipped-artifact-downloads -2023-07-28T08:04:15.3822086Z -2023-07-28T08:04:15.3822865Z Artifact github-pages has been successfully uploaded! diff --git a/abi-spec.rst.txt b/abi-spec.rst.txt deleted file mode 100644 index 41967dd..0000000 --- a/abi-spec.rst.txt +++ /dev/null @@ -1,826 +0,0 @@ -.. index:: abi, application binary interface - -.. _ABI: - -************************** -Contract ABI Specification -************************** - -Basic Design -============ - -The Contract Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem, both -from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type, -as described in this specification. The encoding is not self describing and thus requires a schema in order to decode. - -We assume that the interface functions of a contract are strongly typed, known at compilation time and static. -We assume that all contracts will have the interface definitions of any contracts they call available at compile-time. - -This specification does not address contracts whose interface is dynamic or otherwise known only at run-time. - -.. _abi_function_selector: -.. index:: ! selector; of a function - -Function Selector -================= - -The first four bytes of the call data for a function call specifies the function to be called. It is the -first (left, high-order in big-endian) four bytes of the Keccak-256 hash of the signature of -the function. The signature is defined as the canonical expression of the basic prototype without data -location specifier, i.e. -the function name with the parenthesised list of parameter types. Parameter types are split by a single -comma — no spaces are used. - -.. note:: - The return type of a function is not part of this signature. In - :ref:`Solidity's function overloading ` return types are not considered. - The reason is to keep function call resolution context-independent. - The :ref:`JSON description of the ABI` however contains both inputs and outputs. - -Argument Encoding -================= - -Starting from the fifth byte, the encoded arguments follow. This encoding is also used in -other places, e.g. the return values and also event arguments are encoded in the same way, -without the four bytes specifying the function. - -Types -===== - -The following elementary types exist: - -- ``uint``: unsigned integer type of ``M`` bits, ``0 < M <= 256``, ``M % 8 == 0``. e.g. ``uint32``, ``uint8``, ``uint256``. - -- ``int``: two's complement signed integer type of ``M`` bits, ``0 < M <= 256``, ``M % 8 == 0``. - -- ``address``: equivalent to ``uint160``, except for the assumed interpretation and language typing. - For computing the function selector, ``address`` is used. - -- ``uint``, ``int``: synonyms for ``uint256``, ``int256`` respectively. For computing the function - selector, ``uint256`` and ``int256`` have to be used. - -- ``bool``: equivalent to ``uint8`` restricted to the values 0 and 1. For computing the function selector, ``bool`` is used. - -- ``fixedx``: signed fixed-point decimal number of ``M`` bits, ``8 <= M <= 256``, - ``M % 8 == 0``, and ``0 < N <= 80``, which denotes the value ``v`` as ``v / (10 ** N)``. - -- ``ufixedx``: unsigned variant of ``fixedx``. - -- ``fixed``, ``ufixed``: synonyms for ``fixed128x18``, ``ufixed128x18`` respectively. For - computing the function selector, ``fixed128x18`` and ``ufixed128x18`` have to be used. - -- ``bytes``: binary type of ``M`` bytes, ``0 < M <= 32``. - -- ``function``: an address (20 bytes) followed by a function selector (4 bytes). Encoded identical to ``bytes24``. - -The following (fixed-size) array type exists: - -- ``[M]``: a fixed-length array of ``M`` elements, ``M >= 0``, of the given type. - - .. note:: - - While this ABI specification can express fixed-length arrays with zero elements, they're not supported by the compiler. - -The following non-fixed-size types exist: - -- ``bytes``: dynamic sized byte sequence. - -- ``string``: dynamic sized unicode string assumed to be UTF-8 encoded. - -- ``[]``: a variable-length array of elements of the given type. - -Types can be combined to a tuple by enclosing them inside parentheses, separated by commas: - -- ``(T1,T2,...,Tn)``: tuple consisting of the types ``T1``, ..., ``Tn``, ``n >= 0`` - -It is possible to form tuples of tuples, arrays of tuples and so on. It is also possible to form zero-tuples (where ``n == 0``). - -Mapping Solidity to ABI types ------------------------------ - -Solidity supports all the types presented above with the same names with the -exception of tuples. On the other hand, some Solidity types are not supported -by the ABI. The following table shows on the left column Solidity types that -are not part of the ABI, and on the right column the ABI types that represent -them. - -+-------------------------------+-----------------------------------------------------------------------------+ -| Solidity | ABI | -+===============================+=============================================================================+ -|:ref:`address payable
`|``address`` | -+-------------------------------+-----------------------------------------------------------------------------+ -|:ref:`contract` |``address`` | -+-------------------------------+-----------------------------------------------------------------------------+ -|:ref:`enum` |``uint8`` | -+-------------------------------+-----------------------------------------------------------------------------+ -|:ref:`user defined value types |its underlying value type | -|` | | -+-------------------------------+-----------------------------------------------------------------------------+ -|:ref:`struct` |``tuple`` | -+-------------------------------+-----------------------------------------------------------------------------+ - -.. warning:: - Before version ``0.8.0`` enums could have more than 256 members and were represented by the - smallest integer type just big enough to hold the value of any member. - -Design Criteria for the Encoding -================================ - -The encoding is designed to have the following properties, which are especially useful if some arguments are nested arrays: - -1. The number of reads necessary to access a value is at most the depth of the value - inside the argument array structure, i.e. four reads are needed to retrieve ``a_i[k][l][r]``. In a - previous version of the ABI, the number of reads scaled linearly with the total number of dynamic - parameters in the worst case. - -2. The data of a variable or an array element is not interleaved with other data and it is - relocatable, i.e. it only uses relative "addresses". - - -Formal Specification of the Encoding -==================================== - -We distinguish static and dynamic types. Static types are encoded in-place and dynamic types are -encoded at a separately allocated location after the current block. - -**Definition:** The following types are called "dynamic": - -* ``bytes`` -* ``string`` -* ``T[]`` for any ``T`` -* ``T[k]`` for any dynamic ``T`` and any ``k >= 0`` -* ``(T1,...,Tk)`` if ``Ti`` is dynamic for some ``1 <= i <= k`` - -All other types are called "static". - -**Definition:** ``len(a)`` is the number of bytes in a binary string ``a``. -The type of ``len(a)`` is assumed to be ``uint256``. - -We define ``enc``, the actual encoding, as a mapping of values of the ABI types to binary strings such -that ``len(enc(X))`` depends on the value of ``X`` if and only if the type of ``X`` is dynamic. - -**Definition:** For any ABI value ``X``, we recursively define ``enc(X)``, depending -on the type of ``X`` being - -- ``(T1,...,Tk)`` for ``k >= 0`` and any types ``T1``, ..., ``Tk`` - - ``enc(X) = head(X(1)) ... head(X(k)) tail(X(1)) ... tail(X(k))`` - - where ``X = (X(1), ..., X(k))`` and - ``head`` and ``tail`` are defined for ``Ti`` as follows: - - if ``Ti`` is static: - - ``head(X(i)) = enc(X(i))`` and ``tail(X(i)) = ""`` (the empty string) - - otherwise, i.e. if ``Ti`` is dynamic: - - ``head(X(i)) = enc(len( head(X(1)) ... head(X(k)) tail(X(1)) ... tail(X(i-1)) ))`` - ``tail(X(i)) = enc(X(i))`` - - Note that in the dynamic case, ``head(X(i))`` is well-defined since the lengths of - the head parts only depend on the types and not the values. The value of ``head(X(i))`` is the offset - of the beginning of ``tail(X(i))`` relative to the start of ``enc(X)``. - -- ``T[k]`` for any ``T`` and ``k``: - - ``enc(X) = enc((X[0], ..., X[k-1]))`` - - i.e. it is encoded as if it were a tuple with ``k`` elements - of the same type. - -- ``T[]`` where ``X`` has ``k`` elements (``k`` is assumed to be of type ``uint256``): - - ``enc(X) = enc(k) enc((X[0], ..., X[k-1]))`` - - i.e. it is encoded as if it were a tuple with ``k`` elements of the same type (resp. an array of static size ``k``), prefixed with - the number of elements. - -- ``bytes``, of length ``k`` (which is assumed to be of type ``uint256``): - - ``enc(X) = enc(k) pad_right(X)``, i.e. the number of bytes is encoded as a - ``uint256`` followed by the actual value of ``X`` as a byte sequence, followed by - the minimum number of zero-bytes such that ``len(enc(X))`` is a multiple of 32. - -- ``string``: - - ``enc(X) = enc(enc_utf8(X))``, i.e. ``X`` is UTF-8 encoded and this value is interpreted - as of ``bytes`` type and encoded further. Note that the length used in this subsequent - encoding is the number of bytes of the UTF-8 encoded string, not its number of characters. - -- ``uint``: ``enc(X)`` is the big-endian encoding of ``X``, padded on the higher-order - (left) side with zero-bytes such that the length is 32 bytes. -- ``address``: as in the ``uint160`` case -- ``int``: ``enc(X)`` is the big-endian two's complement encoding of ``X``, padded on the higher-order (left) side with ``0xff`` bytes for negative ``X`` and with zero-bytes for non-negative ``X`` such that the length is 32 bytes. -- ``bool``: as in the ``uint8`` case, where ``1`` is used for ``true`` and ``0`` for ``false`` -- ``fixedx``: ``enc(X)`` is ``enc(X * 10**N)`` where ``X * 10**N`` is interpreted as a ``int256``. -- ``fixed``: as in the ``fixed128x18`` case -- ``ufixedx``: ``enc(X)`` is ``enc(X * 10**N)`` where ``X * 10**N`` is interpreted as a ``uint256``. -- ``ufixed``: as in the ``ufixed128x18`` case -- ``bytes``: ``enc(X)`` is the sequence of bytes in ``X`` padded with trailing zero-bytes to a length of 32 bytes. - -Note that for any ``X``, ``len(enc(X))`` is a multiple of 32. - -Function Selector and Argument Encoding -======================================= - -All in all, a call to the function ``f`` with parameters ``a_1, ..., a_n`` is encoded as - - ``function_selector(f) enc((a_1, ..., a_n))`` - -and the return values ``v_1, ..., v_k`` of ``f`` are encoded as - - ``enc((v_1, ..., v_k))`` - -i.e. the values are combined into a tuple and encoded. - -Examples -======== - -Given the contract: - -.. code-block:: solidity - :force: - - // SPDX-License-Identifier: GPL-3.0 - pragma solidity >=0.4.16 <0.9.0; - - contract Foo { - function bar(bytes3[2] memory) public pure {} - function baz(uint32 x, bool y) public pure returns (bool r) { r = x > 32 || y; } - function sam(bytes memory, bool, uint[] memory) public pure {} - } - - -Thus, for our ``Foo`` example if we wanted to call ``baz`` with the parameters ``69`` and -``true``, we would pass 68 bytes total, which can be broken down into: - -- ``0xcdcd77c0``: the Method ID. This is derived as the first 4 bytes of the Keccak hash of - the ASCII form of the signature ``baz(uint32,bool)``. -- ``0x0000000000000000000000000000000000000000000000000000000000000045``: the first parameter, - a uint32 value ``69`` padded to 32 bytes -- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the second parameter - boolean - ``true``, padded to 32 bytes - -In total: - -.. code-block:: none - - 0xcdcd77c000000000000000000000000000000000000000000000000000000000000000450000000000000000000000000000000000000000000000000000000000000001 - -It returns a single ``bool``. If, for example, it were to return ``false``, its output would be -the single byte array ``0x0000000000000000000000000000000000000000000000000000000000000000``, a single bool. - -If we wanted to call ``bar`` with the argument ``["abc", "def"]``, we would pass 68 bytes total, broken down into: - -- ``0xfce353f6``: the Method ID. This is derived from the signature ``bar(bytes3[2])``. -- ``0x6162630000000000000000000000000000000000000000000000000000000000``: the first part of the first - parameter, a ``bytes3`` value ``"abc"`` (left-aligned). -- ``0x6465660000000000000000000000000000000000000000000000000000000000``: the second part of the first - parameter, a ``bytes3`` value ``"def"`` (left-aligned). - -In total: - -.. code-block:: none - - 0xfce353f661626300000000000000000000000000000000000000000000000000000000006465660000000000000000000000000000000000000000000000000000000000 - -If we wanted to call ``sam`` with the arguments ``"dave"``, ``true`` and ``[1,2,3]``, we would -pass 292 bytes total, broken down into: - -- ``0xa5643bf2``: the Method ID. This is derived from the signature ``sam(bytes,bool,uint256[])``. Note that ``uint`` is replaced with its canonical representation ``uint256``. -- ``0x0000000000000000000000000000000000000000000000000000000000000060``: the location of the data part of the first parameter (dynamic type), measured in bytes from the start of the arguments block. In this case, ``0x60``. -- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the second parameter: boolean true. -- ``0x00000000000000000000000000000000000000000000000000000000000000a0``: the location of the data part of the third parameter (dynamic type), measured in bytes. In this case, ``0xa0``. -- ``0x0000000000000000000000000000000000000000000000000000000000000004``: the data part of the first argument, it starts with the length of the byte array in elements, in this case, 4. -- ``0x6461766500000000000000000000000000000000000000000000000000000000``: the contents of the first argument: the UTF-8 (equal to ASCII in this case) encoding of ``"dave"``, padded on the right to 32 bytes. -- ``0x0000000000000000000000000000000000000000000000000000000000000003``: the data part of the third argument, it starts with the length of the array in elements, in this case, 3. -- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the first entry of the third parameter. -- ``0x0000000000000000000000000000000000000000000000000000000000000002``: the second entry of the third parameter. -- ``0x0000000000000000000000000000000000000000000000000000000000000003``: the third entry of the third parameter. - -In total: - -.. code-block:: none - - 0xa5643bf20000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000464617665000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000003 - -Use of Dynamic Types -==================== - -A call to a function with the signature ``f(uint256,uint32[],bytes10,bytes)`` with values -``(0x123, [0x456, 0x789], "1234567890", "Hello, world!")`` is encoded in the following way: - -We take the first four bytes of ``keccak("f(uint256,uint32[],bytes10,bytes)")``, i.e. ``0x8be65246``. -Then we encode the head parts of all four arguments. For the static types ``uint256`` and ``bytes10``, -these are directly the values we want to pass, whereas for the dynamic types ``uint32[]`` and ``bytes``, -we use the offset in bytes to the start of their data area, measured from the start of the value -encoding (i.e. not counting the first four bytes containing the hash of the function signature). These are: - -- ``0x0000000000000000000000000000000000000000000000000000000000000123`` (``0x123`` padded to 32 bytes) -- ``0x0000000000000000000000000000000000000000000000000000000000000080`` (offset to start of data part of second parameter, 4*32 bytes, exactly the size of the head part) -- ``0x3132333435363738393000000000000000000000000000000000000000000000`` (``"1234567890"`` padded to 32 bytes on the right) -- ``0x00000000000000000000000000000000000000000000000000000000000000e0`` (offset to start of data part of fourth parameter = offset to start of data part of first dynamic parameter + size of data part of first dynamic parameter = 4\*32 + 3\*32 (see below)) - -After this, the data part of the first dynamic argument, ``[0x456, 0x789]`` follows: - -- ``0x0000000000000000000000000000000000000000000000000000000000000002`` (number of elements of the array, 2) -- ``0x0000000000000000000000000000000000000000000000000000000000000456`` (first element) -- ``0x0000000000000000000000000000000000000000000000000000000000000789`` (second element) - -Finally, we encode the data part of the second dynamic argument, ``"Hello, world!"``: - -- ``0x000000000000000000000000000000000000000000000000000000000000000d`` (number of elements (bytes in this case): 13) -- ``0x48656c6c6f2c20776f726c642100000000000000000000000000000000000000`` (``"Hello, world!"`` padded to 32 bytes on the right) - -All together, the encoding is (newline after function selector and each 32-bytes for clarity): - -.. code-block:: none - - 0x8be65246 - 0000000000000000000000000000000000000000000000000000000000000123 - 0000000000000000000000000000000000000000000000000000000000000080 - 3132333435363738393000000000000000000000000000000000000000000000 - 00000000000000000000000000000000000000000000000000000000000000e0 - 0000000000000000000000000000000000000000000000000000000000000002 - 0000000000000000000000000000000000000000000000000000000000000456 - 0000000000000000000000000000000000000000000000000000000000000789 - 000000000000000000000000000000000000000000000000000000000000000d - 48656c6c6f2c20776f726c642100000000000000000000000000000000000000 - -Let us apply the same principle to encode the data for a function with a signature ``g(uint256[][],string[])`` -with values ``([[1, 2], [3]], ["one", "two", "three"])`` but start from the most atomic parts of the encoding: - -First we encode the length and data of the first embedded dynamic array ``[1, 2]`` of the first root array ``[[1, 2], [3]]``: - -- ``0x0000000000000000000000000000000000000000000000000000000000000002`` (number of elements in the first array, 2; the elements themselves are ``1`` and ``2``) -- ``0x0000000000000000000000000000000000000000000000000000000000000001`` (first element) -- ``0x0000000000000000000000000000000000000000000000000000000000000002`` (second element) - -Then we encode the length and data of the second embedded dynamic array ``[3]`` of the first root array ``[[1, 2], [3]]``: - -- ``0x0000000000000000000000000000000000000000000000000000000000000001`` (number of elements in the second array, 1; the element is ``3``) -- ``0x0000000000000000000000000000000000000000000000000000000000000003`` (first element) - -Then we need to find the offsets ``a`` and ``b`` for their respective dynamic arrays ``[1, 2]`` and ``[3]``. -To calculate the offsets we can take a look at the encoded data of the first root array ``[[1, 2], [3]]`` -enumerating each line in the encoding: - -.. code-block:: none - - 0 - a - offset of [1, 2] - 1 - b - offset of [3] - 2 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [1, 2] - 3 - 0000000000000000000000000000000000000000000000000000000000000001 - encoding of 1 - 4 - 0000000000000000000000000000000000000000000000000000000000000002 - encoding of 2 - 5 - 0000000000000000000000000000000000000000000000000000000000000001 - count for [3] - 6 - 0000000000000000000000000000000000000000000000000000000000000003 - encoding of 3 - -Offset ``a`` points to the start of the content of the array ``[1, 2]`` which is line -2 (64 bytes); thus ``a = 0x0000000000000000000000000000000000000000000000000000000000000040``. - -Offset ``b`` points to the start of the content of the array ``[3]`` which is line 5 (160 bytes); -thus ``b = 0x00000000000000000000000000000000000000000000000000000000000000a0``. - - -Then we encode the embedded strings of the second root array: - -- ``0x0000000000000000000000000000000000000000000000000000000000000003`` (number of characters in word ``"one"``) -- ``0x6f6e650000000000000000000000000000000000000000000000000000000000`` (utf8 representation of word ``"one"``) -- ``0x0000000000000000000000000000000000000000000000000000000000000003`` (number of characters in word ``"two"``) -- ``0x74776f0000000000000000000000000000000000000000000000000000000000`` (utf8 representation of word ``"two"``) -- ``0x0000000000000000000000000000000000000000000000000000000000000005`` (number of characters in word ``"three"``) -- ``0x7468726565000000000000000000000000000000000000000000000000000000`` (utf8 representation of word ``"three"``) - -In parallel to the first root array, since strings are dynamic elements we need to find their offsets ``c``, ``d`` and ``e``: - -.. code-block:: none - - 0 - c - offset for "one" - 1 - d - offset for "two" - 2 - e - offset for "three" - 3 - 0000000000000000000000000000000000000000000000000000000000000003 - count for "one" - 4 - 6f6e650000000000000000000000000000000000000000000000000000000000 - encoding of "one" - 5 - 0000000000000000000000000000000000000000000000000000000000000003 - count for "two" - 6 - 74776f0000000000000000000000000000000000000000000000000000000000 - encoding of "two" - 7 - 0000000000000000000000000000000000000000000000000000000000000005 - count for "three" - 8 - 7468726565000000000000000000000000000000000000000000000000000000 - encoding of "three" - -Offset ``c`` points to the start of the content of the string ``"one"`` which is line 3 (96 bytes); -thus ``c = 0x0000000000000000000000000000000000000000000000000000000000000060``. - -Offset ``d`` points to the start of the content of the string ``"two"`` which is line 5 (160 bytes); -thus ``d = 0x00000000000000000000000000000000000000000000000000000000000000a0``. - -Offset ``e`` points to the start of the content of the string ``"three"`` which is line 7 (224 bytes); -thus ``e = 0x00000000000000000000000000000000000000000000000000000000000000e0``. - - -Note that the encodings of the embedded elements of the root arrays are not dependent on each other -and have the same encodings for a function with a signature ``g(string[],uint256[][])``. - -Then we encode the length of the first root array: - -- ``0x0000000000000000000000000000000000000000000000000000000000000002`` (number of elements in the first root array, 2; the elements themselves are ``[1, 2]`` and ``[3]``) - -Then we encode the length of the second root array: - -- ``0x0000000000000000000000000000000000000000000000000000000000000003`` (number of strings in the second root array, 3; the strings themselves are ``"one"``, ``"two"`` and ``"three"``) - -Finally we find the offsets ``f`` and ``g`` for their respective root dynamic arrays ``[[1, 2], [3]]`` and -``["one", "two", "three"]``, and assemble parts in the correct order: - -.. code-block:: none - - 0x2289b18c - function signature - 0 - f - offset of [[1, 2], [3]] - 1 - g - offset of ["one", "two", "three"] - 2 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [[1, 2], [3]] - 3 - 0000000000000000000000000000000000000000000000000000000000000040 - offset of [1, 2] - 4 - 00000000000000000000000000000000000000000000000000000000000000a0 - offset of [3] - 5 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [1, 2] - 6 - 0000000000000000000000000000000000000000000000000000000000000001 - encoding of 1 - 7 - 0000000000000000000000000000000000000000000000000000000000000002 - encoding of 2 - 8 - 0000000000000000000000000000000000000000000000000000000000000001 - count for [3] - 9 - 0000000000000000000000000000000000000000000000000000000000000003 - encoding of 3 - 10 - 0000000000000000000000000000000000000000000000000000000000000003 - count for ["one", "two", "three"] - 11 - 0000000000000000000000000000000000000000000000000000000000000060 - offset for "one" - 12 - 00000000000000000000000000000000000000000000000000000000000000a0 - offset for "two" - 13 - 00000000000000000000000000000000000000000000000000000000000000e0 - offset for "three" - 14 - 0000000000000000000000000000000000000000000000000000000000000003 - count for "one" - 15 - 6f6e650000000000000000000000000000000000000000000000000000000000 - encoding of "one" - 16 - 0000000000000000000000000000000000000000000000000000000000000003 - count for "two" - 17 - 74776f0000000000000000000000000000000000000000000000000000000000 - encoding of "two" - 18 - 0000000000000000000000000000000000000000000000000000000000000005 - count for "three" - 19 - 7468726565000000000000000000000000000000000000000000000000000000 - encoding of "three" - -Offset ``f`` points to the start of the content of the array ``[[1, 2], [3]]`` which is line 2 (64 bytes); -thus ``f = 0x0000000000000000000000000000000000000000000000000000000000000040``. - -Offset ``g`` points to the start of the content of the array ``["one", "two", "three"]`` which is line 10 (320 bytes); -thus ``g = 0x0000000000000000000000000000000000000000000000000000000000000140``. - -.. _abi_events: - -Events -====== - -Events are an abstraction of the Ethereum logging/event-watching protocol. Log entries provide the contract's -address, a series of up to four topics and some arbitrary length binary data. Events leverage the existing function -ABI in order to interpret this (together with an interface spec) as a properly typed structure. - -Given an event name and series of event parameters, we split them into two sub-series: those which are indexed and -those which are not. -Those which are indexed, which may number up to 3 (for non-anonymous events) or 4 (for anonymous ones), are used -alongside the Keccak hash of the event signature to form the topics of the log entry. -Those which are not indexed form the byte array of the event. - -In effect, a log entry using this ABI is described as: - -- ``address``: the address of the contract (intrinsically provided by Ethereum); -- ``topics[0]``: ``keccak(EVENT_NAME+"("+EVENT_ARGS.map(canonical_type_of).join(",")+")")`` (``canonical_type_of`` - is a function that simply returns the canonical type of a given argument, e.g. for ``uint indexed foo``, it would - return ``uint256``). This value is only present in ``topics[0]`` if the event is not declared as ``anonymous``; -- ``topics[n]``: ``abi_encode(EVENT_INDEXED_ARGS[n - 1])`` if the event is not declared as ``anonymous`` - or ``abi_encode(EVENT_INDEXED_ARGS[n])`` if it is (``EVENT_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` that - are indexed); -- ``data``: ABI encoding of ``EVENT_NON_INDEXED_ARGS`` (``EVENT_NON_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` - that are not indexed, ``abi_encode`` is the ABI encoding function used for returning a series of typed values - from a function, as described above). - -For all types of length at most 32 bytes, the ``EVENT_INDEXED_ARGS`` array contains -the value directly, padded or sign-extended (for signed integers) to 32 bytes, just as for regular ABI encoding. -However, for all "complex" types or types of dynamic length, including all arrays, ``string``, ``bytes`` and structs, -``EVENT_INDEXED_ARGS`` will contain the *Keccak hash* of a special in-place encoded value -(see :ref:`indexed_event_encoding`), rather than the encoded value directly. -This allows applications to efficiently query for values of dynamic-length types -(by setting the hash of the encoded value as the topic), but leaves applications unable -to decode indexed values they have not queried for. For dynamic-length types, -application developers face a trade-off between fast search for predetermined values -(if the argument is indexed) and legibility of arbitrary values (which requires that -the arguments not be indexed). Developers may overcome this tradeoff and achieve both -efficient search and arbitrary legibility by defining events with two arguments — one -indexed, one not — intended to hold the same value. - -.. _abi_errors: -.. index:: error, selector; of an error - -Errors -====== - -In case of a failure inside a contract, the contract can use a special opcode to abort execution and revert -all state changes. In addition to these effects, descriptive data can be returned to the caller. -This descriptive data is the encoding of an error and its arguments in the same way as data for a function -call. - -As an example, let us consider the following contract whose ``transfer`` function always -reverts with a custom error of "insufficient balance": - -.. code-block:: solidity - - // SPDX-License-Identifier: GPL-3.0 - pragma solidity ^0.8.4; - - contract TestToken { - error InsufficientBalance(uint256 available, uint256 required); - function transfer(address /*to*/, uint amount) public pure { - revert InsufficientBalance(0, amount); - } - } - -The return data would be encoded in the same way as the function call -``InsufficientBalance(0, amount)`` to the function ``InsufficientBalance(uint256,uint256)``, -i.e. ``0xcf479181``, ``uint256(0)``, ``uint256(amount)``. - -The error selectors ``0x00000000`` and ``0xffffffff`` are reserved for future use. - -.. warning:: - Never trust error data. - The error data by default bubbles up through the chain of external calls, which - means that a contract may receive an error not defined in any of the contracts - it calls directly. - Furthermore, any contract can fake any error by returning data that matches - an error signature, even if the error is not defined anywhere. - -.. _abi_json: - -JSON -==== - -The JSON format for a contract's interface is given by an array of function, event and error descriptions. -A function description is a JSON object with the fields: - -- ``type``: ``"function"``, ``"constructor"``, ``"receive"`` (the :ref:`"receive Ether" function `) or ``"fallback"`` (the :ref:`"default" function `); -- ``name``: the name of the function; -- ``inputs``: an array of objects, each of which contains: - - * ``name``: the name of the parameter. - * ``type``: the canonical type of the parameter (more below). - * ``components``: used for tuple types (more below). - -- ``outputs``: an array of objects similar to ``inputs``. -- ``stateMutability``: a string with one of the following values: ``pure`` (:ref:`specified to not read - blockchain state `), ``view`` (:ref:`specified to not modify the blockchain - state `), ``nonpayable`` (function does not accept Ether - the default) and ``payable`` (function accepts Ether). - -Constructor, receive, and fallback never have ``name`` or ``outputs``. Receive and fallback do not have ``inputs`` either. - -.. note:: - Sending non-zero Ether to non-payable function will revert the transaction. - -.. note:: - The state mutability ``nonpayable`` is reflected in Solidity by not specifying - a state mutability modifier at all. - -An event description is a JSON object with fairly similar fields: - -- ``type``: always ``"event"`` -- ``name``: the name of the event. -- ``inputs``: an array of objects, each of which contains: - - * ``name``: the name of the parameter. - * ``type``: the canonical type of the parameter (more below). - * ``components``: used for tuple types (more below). - * ``indexed``: ``true`` if the field is part of the log's topics, ``false`` if it is one of the log's data segments. - -- ``anonymous``: ``true`` if the event was declared as ``anonymous``. - -Errors look as follows: - -- ``type``: always ``"error"`` -- ``name``: the name of the error. -- ``inputs``: an array of objects, each of which contains: - - * ``name``: the name of the parameter. - * ``type``: the canonical type of the parameter (more below). - * ``components``: used for tuple types (more below). - -.. note:: - There can be multiple errors with the same name and even with identical signature - in the JSON array; for example, if the errors originate from different - files in the smart contract or are referenced from another smart contract. - For the ABI, only the name of the error itself is relevant and not where it is - defined. - - -For example, - -.. code-block:: solidity - - // SPDX-License-Identifier: GPL-3.0 - pragma solidity ^0.8.4; - - - contract Test { - constructor() { b = hex"12345678901234567890123456789012"; } - event Event(uint indexed a, bytes32 b); - event Event2(uint indexed a, bytes32 b); - error InsufficientBalance(uint256 available, uint256 required); - function foo(uint a) public { emit Event(a, b); } - bytes32 b; - } - -would result in the JSON: - -.. code-block:: json - - [{ - "type":"error", - "inputs": [{"name":"available","type":"uint256"},{"name":"required","type":"uint256"}], - "name":"InsufficientBalance" - }, { - "type":"event", - "inputs": [{"name":"a","type":"uint256","indexed":true},{"name":"b","type":"bytes32","indexed":false}], - "name":"Event" - }, { - "type":"event", - "inputs": [{"name":"a","type":"uint256","indexed":true},{"name":"b","type":"bytes32","indexed":false}], - "name":"Event2" - }, { - "type":"function", - "inputs": [{"name":"a","type":"uint256"}], - "name":"foo", - "outputs": [] - }] - -Handling tuple types --------------------- - -Despite the fact that names are intentionally not part of the ABI encoding, they do make a lot of sense to be included -in the JSON to enable displaying it to the end user. The structure is nested in the following way: - -An object with members ``name``, ``type`` and potentially ``components`` describes a typed variable. -The canonical type is determined until a tuple type is reached and the string description up -to that point is stored in ``type`` prefix with the word ``tuple``, i.e. it will be ``tuple`` followed by -a sequence of ``[]`` and ``[k]`` with -integers ``k``. The components of the tuple are then stored in the member ``components``, -which is of an array type and has the same structure as the top-level object except that -``indexed`` is not allowed there. - -As an example, the code - -.. code-block:: solidity - - // SPDX-License-Identifier: GPL-3.0 - pragma solidity >=0.7.5 <0.9.0; - pragma abicoder v2; - - contract Test { - struct S { uint a; uint[] b; T[] c; } - struct T { uint x; uint y; } - function f(S memory, T memory, uint) public pure {} - function g() public pure returns (S memory, T memory, uint) {} - } - -would result in the JSON: - -.. code-block:: json - - [ - { - "name": "f", - "type": "function", - "inputs": [ - { - "name": "s", - "type": "tuple", - "components": [ - { - "name": "a", - "type": "uint256" - }, - { - "name": "b", - "type": "uint256[]" - }, - { - "name": "c", - "type": "tuple[]", - "components": [ - { - "name": "x", - "type": "uint256" - }, - { - "name": "y", - "type": "uint256" - } - ] - } - ] - }, - { - "name": "t", - "type": "tuple", - "components": [ - { - "name": "x", - "type": "uint256" - }, - { - "name": "y", - "type": "uint256" - } - ] - }, - { - "name": "a", - "type": "uint256" - } - ], - "outputs": [] - } - ] - -.. _abi_packed_mode: - -Strict Encoding Mode -==================== - -Strict encoding mode is the mode that leads to exactly the same encoding as defined in the formal specification above. -This means that offsets have to be as small as possible while still not creating overlaps in the data areas, and thus no gaps are -allowed. - -Usually, ABI decoders are written in a straightforward way by just following offset pointers, but some decoders -might enforce strict mode. The Solidity ABI decoder currently does not enforce strict mode, but the encoder -always creates data in strict mode. - -Non-standard Packed Mode -======================== - -Through ``abi.encodePacked()``, Solidity supports a non-standard packed mode where: - -- types shorter than 32 bytes are concatenated directly, without padding or sign extension -- dynamic types are encoded in-place and without the length. -- array elements are padded, but still encoded in-place - -Furthermore, structs as well as nested arrays are not supported. - -As an example, the encoding of ``int16(-1), bytes1(0x42), uint16(0x03), string("Hello, world!")`` results in: - -.. code-block:: none - - 0xffff42000348656c6c6f2c20776f726c6421 - ^^^^ int16(-1) - ^^ bytes1(0x42) - ^^^^ uint16(0x03) - ^^^^^^^^^^^^^^^^^^^^^^^^^^ string("Hello, world!") without a length field - -More specifically: - -- During the encoding, everything is encoded in-place. This means that there is - no distinction between head and tail, as in the ABI encoding, and the length - of an array is not encoded. -- The direct arguments of ``abi.encodePacked`` are encoded without padding, - as long as they are not arrays (or ``string`` or ``bytes``). -- The encoding of an array is the concatenation of the - encoding of its elements **with** padding. -- Dynamically-sized types like ``string``, ``bytes`` or ``uint[]`` are encoded - without their length field. -- The encoding of ``string`` or ``bytes`` does not apply padding at the end, - unless it is part of an array or struct (then it is padded to a multiple of - 32 bytes). - -In general, the encoding is ambiguous as soon as there are two dynamically-sized elements, -because of the missing length field. - -If padding is needed, explicit type conversions can be used: ``abi.encodePacked(uint16(0x12)) == hex"0012"``. - -Since packed encoding is not used when calling functions, there is no special support -for prepending a function selector. Since the encoding is ambiguous, there is no decoding function. - -.. warning:: - - If you use ``keccak256(abi.encodePacked(a, b))`` and both ``a`` and ``b`` are dynamic types, - it is easy to craft collisions in the hash value by moving parts of ``a`` into ``b`` and - vice-versa. More specifically, ``abi.encodePacked("a", "bc") == abi.encodePacked("ab", "c")``. - If you use ``abi.encodePacked`` for signatures, authentication or data integrity, make - sure to always use the same types and check that at most one of them is dynamic. - Unless there is a compelling reason, ``abi.encode`` should be preferred. - - -.. _indexed_event_encoding: - -Encoding of Indexed Event Parameters -==================================== - -Indexed event parameters that are not value types, i.e. arrays and structs are not -stored directly but instead a Keccak-256 hash of an encoding is stored. This encoding -is defined as follows: - -- the encoding of a ``bytes`` and ``string`` value is just the string contents - without any padding or length prefix. -- the encoding of a struct is the concatenation of the encoding of its members, - always padded to a multiple of 32 bytes (even ``bytes`` and ``string``). -- the encoding of an array (both dynamically- and statically-sized) is - the concatenation of the encoding of its elements, always padded to a multiple - of 32 bytes (even ``bytes`` and ``string``) and without any length prefix - -In the above, as usual, a negative number is padded by sign extension and not zero padded. -``bytesNN`` types are padded on the right while ``uintNN`` / ``intNN`` are padded on the left. - -.. warning:: - - The encoding of a struct is ambiguous if it contains more than one dynamically-sized - array. Because of that, always re-check the event data and do not rely on the search result - based on the indexed parameters alone.