| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Optionally print IR metadata block (#7684) ## Description This PR makes printing of the IR metadata block optional. For IR analysis, in most of the cases, the printed IR just introduces clutter. It is now not printed by default. To print it, `print-md` directive must be added to the `--ir` CLI argument (or `--print-ir` in E2E tests). E.g.: ``` --ir all modified print-md --if final print-md ``` IR metadata is removed from almost all the snapshots, except the two that use the whole `sway-lib-std`. Seeing changes in metadata when changing `std` code is still useful. The `filter-fn` option in snapshot tests was previously relying on the first `!0` as an end of the printed IR step. This is now changed to checking for a `}` in at the beginning of a line. ## Breaking Change Strictly seen, this is a breaking change, in case someone prints IR and relies on having metadata printed. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
Bump to 0.71.2 and fix crates.io publish (#7634) ## Summary - Bump workspace and `sway-lib-std` to **0.71.2** after the failed v0.71.1 crates.io publish (only `sway-utils` 0.71.1 made it up; binaries for v0.71.1 are fine). - Fix publish breakage from **yanked `core2`** (RUSTSEC-2026-0105): `FuelLabs/publish-crates` runs `cargo update` after each crate, which failed on the `multihash 0.17` → `ipfs-api` chain used by `forc-pkg`. - Patch `core2` from the `bbqsrc/core2` git rev and bump `cid` to **0.11.3** so release `cargo update` resolves again. ## Test plan - [ ] CI green on this PR - [ ] Merge and cut GitHub release **v0.71.2** - [ ] Confirm `publish` job completes on crates.io - [ ] Optional: `cargo install forc --version 0.71.2` smoke test | 3 个月前 | |
Make forc-deploy create release builds by default (#5609) ## Description Closes https://github.com/FuelLabs/sway/issues/5607 Solves part [1] of https://github.com/FuelLabs/sway/issues/5607 by making "release" the default build plan for forc-deploy. It can still be overridden, i.e. for the test harness. Other changes: - removed the `--release` and `--error-on-warnings` options from forc-deploy, since those aren't needed. - refactored `BuildProfile` into its own file and added a test, since I noticed some of the options weren't deserializing ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. | 2 年前 | |
chore: remove unmaintained `ansi_term` in favor of `ansiterm` (#6696) ## Description related to #2601. Removes ansi_term dependency from sway crates. To remove the dependency completely from dep tree we need a release of sway repo to get a new version of forc_util and use it in forc_wallet as forc_wallet is depending on `forc-util v0.47.0` which uses `ansi_term`. Once that is done we can close #2601 | 1 年前 | |
Freeze data section layout during `AllocatedProgram` compilation (#7727) ## Description This PR fixes a critical issue of potential miscompilation coming from mutating the data section layout during `AllocatedProgram` compilation. The compiler panic described in #7724 was a "lucky" manifestation of this issue, the one that made compiler panic instead of generating miscompiled code. There were three places where instruction sizes were computed against a data section that was still mutating, and they were disagreeing with each other: 1. `map_label_offsets` computed label offsets using `instruction_size_not_far_jump`, which sized `AddrDataId` by testing `data_id_to_offset(id) <= TWELVE_BITS` against the data section as it was at that moment. 1. `lower_to_realized_ops` then use those label offsets for jump deltas, while `compile_jump/compile_call_inner` inserted far jump target words into non-configurables. 1. `to_bytecode_mut` finally computed `offset_to_data_section` and then appended load pointers while re-measuring (this was the immediate cause of #7724). This PR fixes the above issues by using the existing pattern already used for far jumps. It uses the same two-phase "pessimistic freeze, then realize" pattern applied to `AddrDataId` and to data section pointer insertion. The data section layout is frozen before any jumps are calculated. In order to freeze the layout we calculate the maximum (pesimistic) number of additional data section pointers that could be inserted between the non-configurables and configurables, effectively fixing the positions of the configurables and thus the decision on the number of instructions needed to address them (1: `ADDI` only, or 2: `MOVI` + `ADD`) before jumps are calculated. The pessimistic freeze in practice has none or very minimal performance impact. E.g., contracts used in Sway tests remained byte-identical, o2 `trade-account` contract remained byte-identical, and the `order-book` contract grown from 116,680 B to 116,696 B, where the additional 16 bytes represent two reserved but unused slots for pointers in the data section, while the code section remained byte-identical. The PR also makes the `FinalizedAsm` truly final. Previously, the `to_bytecode_mut` step was further mutating the "finalized" ASM, causing the discrepancy between the ASM and the data sections printed by `--asm final` and the `--bytecode`. `to_bytecode_mut` is renamed to `to_bytecode` and is now a purely serialization step. Work on this PR showed again that having a better display of the data section entries would be very beneficial. This will be done in a follow up PR. Additionally, the PR fixes the issue of the `Entry::equiv` method missing `Datum::Slice` when determining `Entry` equivalence. This removed the deduplication of slices in the data section which is usually not noticeable because `str` literals are during compilation stored as globals which also have their own deduplication. Still, in tests that were testing `panic` expression some slices were duplicated only in tests. These duplications are now properly removed. The large number of changed lines of code in this PR are due to tests that needed to deterministically force far jumps. This is achieved by generating extremely large `asm` blocks which contributed to large number of lines of code in those tests. - Fixes #7724. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 27 天前 |