Function.apply() named parameters fail when compiled to Wasm

[yjbanov]

Copied from flutter/flutter#161004:

Steps to reproduce

Use two different ways of setting container width and height:

1. Literal symbols with #width and #height.
2. Symbol('width') and Symbol('height').
3. Run the code on a Wasm web build.

Wasm doesn't seem to support symbols for named parameters.
Is this working as intended?

Expected results

Both types of symbol Function.apply() works.
Two red containers should be rendered.

On non-Wasm web builds and other platforms, both methods work.

Actual results

The second container fails on Wasm.

Code sample

Code sample

import 'package:flutter/material.dart';

void main() {
  runApp(const MaterialApp(
    home: Scaffold(
      body: Center(
        child: DemoWidget(),
      ),
    ),
  ));
}

class DemoWidget extends StatelessWidget {
  const DemoWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: [
        // 1) Direct usage with literal named parameters (#width, #height)
        createContainerWithDirectSymbols(),
        const SizedBox(height: 20),
        // 2) Using Function.apply with Symbol-based named parameters
        createContainerWithDynamicNamedParameters(),
      ],
    );
  }

  Widget createContainerWithDirectSymbols() {
    try {
      return Function.apply(
        Container.new,
        [],
        {
          #width: 150.0,
          #height: 50.0,
          #color: Colors.red,
        },
      ) as Widget;
    } catch (e) {
      return Text('Error: $e');
    }
  }

  Widget createContainerWithDynamicNamedParameters() {
    try {
      return Function.apply(
        Container.new,
        [],
        {
          Symbol('width'): 150.0,
          Symbol('height'): 50.0,
          Symbol('color'): Colors.red,
        },
      ) as Widget;
    } catch (e) {
      return Text('Error: $e');
    }
  }
}

Screenshots or Video

Screenshots / Video demonstration

There should be two Red containers. However, the dynamic named parameters fail on Wasm so the second container isn't visible.

Logs

Logs

[Paste your logs here]

Flutter Doctor output

Doctor output

[✓] Flutter (Channel beta, 3.28.0-0.1.pre, on macOS 15.1.1 24B2091 darwin-arm64, locale en-US)
    • Flutter version 3.28.0-0.1.pre on channel beta at /Users/ray/Development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 3e493a3e4d (3 weeks ago), 2024-12-12 05:59:24 +0900
    • Engine revision 2ba456fd7f
    • Dart version 3.7.0 (build 3.7.0-209.1.beta)
    • DevTools version 2.41.0

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
    • Android SDK at /Users/ray/Library/Android/sdk
    • Platform android-35, build-tools 35.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
      This is the JDK bundled with the latest Android Studio installation on this machine.
      To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS (Xcode 16.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 16C5032a
    ! CocoaPods 1.15.2 out of date (1.16.2 is recommended).
        CocoaPods is a package manager for iOS or macOS platform code.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/to/platform-plugins
      To update CocoaPods, see https://guides.cocoapods.org/using/getting-started.html#updating-cocoapods

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2024.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)

[✓] VS Code (version 1.96.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.102.0

[✓] Connected device (3 available)
    • macOS (desktop)                 • macos                 • darwin-arm64   • macOS 15.1.1 24B2091 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad • darwin         • macOS 15.1.1 24B2091 darwin-arm64
    • Chrome (web)                    • chrome                • web-javascript • Google Chrome 131.0.6778.205

[✓] Network resources
    • All expected network resources are available.

[osa1]

Smaller repro:

void main() {
  Function.apply(f, [], {#a: 123});
  Function.apply(f, [], {Symbol('a'): 123});
  Function.apply(f, [], {const Symbol('a'): 123});
}

f({Object? a}) => print(a);

[mkustermann]

@osa1 How about we do the same as the VM? We compare symbols not via identical but by string, but at the same time rename the symbols to smaller randomized identifiers in --minify mode?

Then users can explicitly use --no-minify if they want this to work?

[osa1]

@mkustermann that works but it makes --minify a semantics changing flag.

[mkustermann]

@mkustermann that works but it makes --minify a semantics changing flag.

I would expect a --minify to actually minify symbol names, so that's the semantics I would expect from that flag.
It also aligns it with the VM and avoids users relying on non-constant Symbols if they want to minify.

[osa1]

I would expect a --minify to actually minify symbol names, so that's the semantics I would expect from that flag.

Yes because you work on the VM and dart2wasm. A user won't know where exactly symbols are used and how, and what effect changing them would cause.

I'm not saying we shouldn't do it, just pointing out that doing this will replace one confusion with another.

[mkustermann]

I'm not saying we shouldn't do it, just pointing out that doing this will replace one confusion with another.

It's a valid point, especially because on the VM the obfuscation is an opt-in feature, whereas in dart2wasm we enable it by default in -O2/-O3/-O4.

Though currently new Symbol('x') == #x doesn't work in dart2wasm - so we can today start to mangle const symbols (just like VM) in --minify mode without breaking existing dart2wasm users. Then as a follow-up we can make this comparison work in --no-minify solving this issue for users that accept to not use minification.

[lrhn]

I also think minify/obfuscate should be allowed to change semantics. I think of them not as not compiler modes, but more like preprocessors which change the actual names before they're compiled. They might be built into the compiler, but that doesn't make them a language feature, just a tool-chain feature.

Changing names breaks reflection, and that's to be expected. If you don't like that, stop obfuscating/minifying.

The alternative, if new Symbol("foo") = #foo should always wor even if you do minify or obfuscate, would be retaining a translation between minified and non-minified names at runtime. When someone uses new Symbol("foo"), the runtime system would have a table that tells it that the runtime symbol for "foo" is "m1" (or whatever, there doesn't need to be a runtime string at all, just a check for whether something is the "same symbol"), so that it can create a Symbol that will == #foo.

Such a runtime table would be counter to the core idea of obfuscation. The translation information should exist at compile time, otherwise modular compilation can't canonicalize constant symbols across compilation modules, but putting it into the runtime is leaking source names for obfuscation.
Such a atable would be an overhead for minification.
In either case it's at odds with the purpose of doing a name transformation to begin with.

[gmpassos]

Any updates on this issue?

This is a significant problem on the Wasm architecture.

[mkustermann]

As we've explained above, with minification turned on the symbols can be minified/obfuscated at runtime and it doesn't make sense to keep a map from original names to minified names (as that completely defeats the purposes of minification).

What we can do and I'd be in favor of is to say: Users that want to create Symbolss from strings at runtime can use Function.apply but only in --no-minify mode. @gmpassos @rayliverified Would that work for you?

This aligns the behavior also with the Dart VM's AOT compiler and it's obfuscation mode.

[gmpassos]

@mkustermann

I have just released a fix to my package “reflection_factory”, where named parameters are tracked and used to generate a table of "const Symbol" values. This table is then used to provide the "const Symbol" instances needed to make dynamic calls.

As pointed out by @osa1 in my other issue (a duplicate of this one), you can use "const Symbol" values, still minify the code, and it will work normally when compiled to Wasm.

My suggestion is to add this behavior to the documentation and also point out that "Function.apply" should use "const Symbol"s for named parameters to ensure correct calls in minified compilations.

[mkustermann]

I have just released a fix to my package “reflection_factory”, where named parameters are tracked and used to generate a table of "const Symbol" values. This table is then used to provide the "const Symbol" instances needed to make dynamic calls.

That sounds like a good idea if one wants to minify the app in general but then manually keep a (small subset) of the string->symbol mapping for those symbols needed for Function.apply.

My suggestion is to add this behavior to the documentation and also point out that "Function.apply" should use "const Symbol"s for named parameters to ensure correct calls in minified compilations.

That's good suggestions. We can add this to the Function.apply documentation and potentially throw a runtime error if the symbols given to Function.apply are not Symbol constants iff --minify is on.