twiggy uses an ancient version of wasmparser which errors out when encountering an "unknown" entry in the custom name section. The error looks like this:

error: WASM error: Invalid name type (at offset 276799)
  caused by: Invalid name type (at offset 276799)

This PR adds code to just skip any name entry which fails to parse. This is a short term solution to resolve one specific issue which is a blocker for me. I also started to port twiggy to the newest wasmparser version in order to increase compatibility with new wasm features. This is a lot of work, though. The API changed quite a bit.

fixes #574

Fixes #174.

This is a much larger PR than I expected it to be, and apologies on that regard. :grimacing:

I tried a simpler fix here: https://github.com/rustwasm/twiggy/compare/master...data-pup:simple-function-name-demangle-fix

Notably, we need to include the type of item in the output, so that we can differentiate between code and function items. Unfortunately, this meant that the user would need to specify items by their entire name and type/location when using subcommands that accept arguments.

This change, while more involved, allows us to query for items by name, while still showing the demangled names of functions and code blocks! By moving the name of an item from the ir::Item struct into the ir::ItemKind field, we can handle these properly.

The other notable part is that this involves storing the "annotation" (i.e. func[1]) in that struct, and adding an annotated_name method which is used when displaying items. This is required because the diff command breaks if we use the annotated name, because we can't tell that two items are related if an item moved in the index space.

Because this is a hefty PR, I kept changes in separate commits, to help make reviewing this easier. I'll try and find some time to annotate the important parts over the weekend, or early next week :slightly_smiling_face:

After #118 the second PR for #109

This time for the monos command, and with even three new flags :D to cover the 2-dimensional output of generics and their individual monomorphizations:

-a, --all
    --all-generics
    --all-monos

Only some more tests are needed to get it out of WIP... I'll hurry up ;)

This is some initial work to try and solve #57. If no argument is given, then all paths should be printed. I was thinking about this, and thought that it might be nice to have this descend the paths rather than printing a whole list of ascending call paths.

I'm not totally sure if that is a good idea or not, and thought I would open up a PR for some thoughts. I have a little bit of refinement work to do on this, right now type[n] items are printed out, which I don't think should be included in the output if I understand this correctly.

So, questions I have at the moment:

• Does descending the call paths make sense if no argument is given?
• Should type items be included in the output? If not, is there an easy way to identify these?
• How should these be sorted? Name, depth, size? That might be worth adding a new issue for.
• If the ascending/descending choice is exposed as an option flag, what should that be called?

I am using wasm-pack to compile my project to a wasm file, and attempted to use Twiggy to profile the code size, following the online documentation. However, the output of Twiggy was completely useless.

Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼───────────────────────────────────────────────────────────────
        303544 ┊    35.90% ┊ data[664]
         39116 ┊     4.63% ┊ code[0]
         21903 ┊     2.59% ┊ data[663]
         21351 ┊     2.53% ┊ code[1]
         14714 ┊     1.74% ┊ code[2]
          9370 ┊     1.11% ┊ code[3]
          7535 ┊     0.89% ┊ code[4]
          7463 ┊     0.88% ┊ code[5]
          6627 ┊     0.78% ┊ code[6]
          5863 ┊     0.69% ┊ code[7]
          5408 ┊     0.64% ┊ code[8]
          4212 ┊     0.50% ┊ code[9]
          3697 ┊     0.44% ┊ code[10]

I'm guessing that Twiggy doesn't work on wasm files where the debug information was stripped, but I can't find any way to make wasm-pack output that information, and it seems counter productive to reducing binary size in any case. Is there any way to use Twiggy with wasm-pack? It seems like a strange oversight that the two tools recommended for working with wasm are completely incompatible.

This commit does a few different things, and largely finishes up the work started in #88, and #140.

First, analyze/analyses/paths.rs has been divided into separate files for the paths function itself, the emitting logic, and for the struct that represents an entry in the Paths struct. Further, the logic for traversing the ir::Items tree that was previously mixed into the emitting logic has been divided out into a separate function, create_entry.

To be sure that this is all working correctly, I added some various tests as well, especially focusing on the max_paths option. The expected output files were generated using the current master branch, to be sure that everything was behaving the same way before and after this change.

While doing this, I did notice an issue with the emit_csv function, being that the meta root is printed in the path field of a CSV record. Additionally, some items only display themselves in that field. In each of these cases, the field will instead be empty. Given that the meta root (iirc) is an internal abstraction, I think it is best left out of this command's output, especially if it is not shown in other formats.

Currently, summaries are not shown, but the code to do so is included in comments under a 'FIXME' note. Once this lands, following up by enabling these sections and updating the test cases should be very straightforward.

Minor sidenote: The output generated by emit_csv would probably be most helpful if we made a change so that duplicate rows are not displayed. For now, I've considered that out of scope for this PR, and can open up a separate issue for that.

Fixes https://github.com/rustwasm/twiggy/issues/104

Hi :) Since I'm completely new to Rust, it took me a while to figure this out... But that's the best way to learn! :D

Nevertheless I'm still a bit confused ;) causes() is defined in Fail. Just like iter_causes(). The first can be directy used as method on the Error trait (even though being deprecated), the second can't... o.O Why?

I also don't know if my solution really works, since I wasn't be able to raise a simple error somehow for testing :D How to do that?

I'm trying to install twiggy with cargo, but on my Windows 10 I'm encountering the following build error:

error: failed to run custom build command for `twiggy-opt v0.1.0`
process didn't exit successfully: `C:\Users\D071863\AppData\Local\Temp\cargo-installUGK4Ht\release\build\twiggy-opt-8f09be37635e03b4\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=./definitions.js

--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', libcore\result.rs:945:5
stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
   1: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
   2: std::sys_common::backtrace::print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
   3: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:211
   4: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:227
   5: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:463
   6: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:350
   7: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:328
   8: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   9: core::result::unwrap_failed
  10: core::result::unwrap_failed
  11: core::result::unwrap_failed
  12: <alloc::raw_vec::RawVec<T, A>>::reserve
  13: std::rt::lang_start_internal::{{closure}}
             at C:\projects\rust\src\libstd\rt.rs:59
  14: std::panicking::try::do_call<closure,i32>
             at C:\projects\rust\src\libstd\panicking.rs:310
  15: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:105
  16: std::panicking::try
             at C:\projects\rust\src\libstd\panicking.rs:289
  17: std::panic::catch_unwind
             at C:\projects\rust\src\libstd\panic.rs:374
  18: std::rt::lang_start_internal
             at C:\projects\rust\src\libstd\rt.rs:58
  19: main
  20: invoke_main
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:64
  21: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  22: BaseThreadInitThunk
  23: RtlUserThreadStart

warning: build failed, waiting for other jobs to finish...
error: failed to compile `twiggy v0.1.0`, intermediate artifacts can be found at `C:\Users\D071863\AppData\Local\Temp\cargo-installUGK4Ht`

Caused by:
  build failed

Any ideas what's going on here?

Hi,

I wanted to add twiggy to the list of linters at awesome-static-analysis, but I was unsure about the license of the code. Can we add a license to the project? 😃

Hello,

I'm trying to use twiggy 0.2.0 with mono's wasm port and hitting this crash on OSX:

tijuca:wasm rokumper$ RUST_BACKTRACE=1 twiggy top debug/mono.wasm
thread 'main' panicked at 'assertion failed: index < u32::MAX as usize', /Users/kumpera/.cargo/registry/src/github.com-1ecc6299db9ec823/twiggy-ir-0.2.0/./ir.rs:414:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: twiggy_ir::Id::entry
   7: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::section::ElementSection>::parse_edges
   8: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::module::Module>::parse_edges
   9: twiggy_parser::parse_wasm
  10: twiggy_parser::read_and_parse
  11: twiggy::main
  12: std::rt::lang_start::{{closure}}
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::rt::lang_start_internal
  16: main

To reproduce it. Download this file: https://jenkins.mono-project.com/job/test-mono-mainline-wasm/926/label=ubuntu-1804-amd64/Azure/processDownloadRequest/926/ubuntu-1804-amd64/sdks/wasm/mono-wasm-24c1f2a40c1.zip

Then run twiggy: twiggy top debug/mono.wasm

Fixes #174. (Finally! :smile_cat:)

In #270, we proposed merging the IR items for code/function section entries.

I wonder if it makes sense to collapse func[123] and code[123] into the same IR item, since no body is used by more than one func and vice versa. They are essentially the same, even if they are split at the physical binary level (to allow eager type checking and validation).

I think I agree [..] that the best way to handle this on WebAssembly is to merge the func/code nodes. When looking at the size of a function we may as well account for the bytes that the function type pointer takes up (although it's like 1-3 at most realistically). It'll definitely make reading the output a bit easier as I know in the past I've had to follow chains a few levels deep to get to the real part of a function!

This combines the func/code nodes in the IR generated when parsing a wasm module :tada:

To keep this somewhat more reviewable, I've divided the PR into 3 commits.

• 9e82d6c - No changes to behavior, this simply refactors the parsing code towards a structure where merging the func/code nodes can be accomplished in as small a change as possible. This commit will still pass the original test snapshots.
• 474b193 - This is where the actual IR node merge occurs, including changes to how we draw edges between nodes.
• e1fcfba - This commit is purely updating the test snapshots. This should probably be reviewed first, so that we can decide whether this is an acceptable change regarding ergonomics/correctness :slightly_smiling_face:

Bumps object from 0.17.0 to 0.30.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps cargo_toml from 0.13.0 to 0.14.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps thiserror from 1.0.37 to 1.0.38.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps anyhow from 1.0.65 to 1.0.68.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps gimli from 0.26.2 to 0.27.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps cpp_demangle from 0.3.5 to 0.4.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.