We already guarantee in debug builds that every symbol we mangle can be demangled, so a proper fuzzer would have to mutate the symbols in Swift binaries to be useful.

@belkadan I am assuming you mispoke and meant when asserts are enabled?

Er, yes, sorry for imprecision.

No worries. I am imprecise all the time as well ; ). I was specifically imagining a simple driver that just pushed strings through swift-demangle. I am not talking about generating swift programs with libfuzzer. I am just talking about generating/mixing random strings.

And to be clear, I know how to do this ; ). So I am going to mark making the infrastructure a starter bug.

Comment by Tapan Thaker (JIRA)

@gottesmm: Wanted to take up this bug, but I am not entirely sure what you mean. Trying to get clarity:

This task involves the following subtasks:
1 - Add a new argument to swiftc such that `swiftc -driver-demangle <string>' would demangle and print the string
2 - Use the above and write a test using http://llvm.org/docs/LibFuzzer.html

tt (JIRA User) This was actually implemented recently by @dcci. I just forgot to move this bug to resolved.

That being said there are other opportunities for fuzzing that we would like to implement. Consider for instance a fuzzer that took in a sil module and then fuzzed the optimizer list. Would something like that interest you?

Comment by Tapan Thaker (JIRA)

@gottesmm: Sure, I will be interested. I am still pretty new to the codebase. So might need some help here and there 🙂.

tt (JIRA User) Sure. Here is an SR for it:

https://bugs.swift.org/browse/SR-7994

I outlined there what I imagined was the simplest way to do this. Lets continue the discussion there.