Tracking Desired Rust & Cargo Upstream Features

[ogoffart]

This issue serves as a tracker for features and improvements we would like to see in Rust, Cargo, and related tools that would benefit Slint. It is meant to be updated and edited over time.

Features We Wish to See in Rust:

• Span::source_file().path() Tracking issue for proc_macro::Span inspection APIs rust-lang/rust#54725:
  To enable resolving file paths (e.g., in @image-url("...") or import from "...") relative to the slint! macro's location, rather than being relative to CARGO_MANIFEST_PATH.

• Span::column and Span::line, or Span::byte_range Tracking issue for proc_macro::Span inspection APIs rust-lang/rust#54725:
  This would allow distinguishing between foo-bar and foo - bar in the slint! macro. Currently, we parse the Debug implementation of Span, which is not future-proof, and not compatible rust-analyzer.

• Allow numeric tokens containing 'e' that aren't exponents be passed to proc macros rust-lang/rust#111615:
  To prevent errors in color literals like #12e3abc used in the slint! macro.

• Improved ABI for core types (RFC 3470):
  Enhancements to the ABI for types like trait objects or slices would simplify our code for the C++ API.

• Compilation speed Very slow 80 minutes release build, due mir_pass_scalar_replacement_of_aggregates (sroa) optimization enabled rust-lang/rust#121354:
  Our generated structs with many fields lead to significantly slow compile times, which we hope can be addressed.

Features We Wish to See in Cargo:

• Improved communication between runtime and code generation crates:

  • We'd like better mechanisms to communicate features from the "runtime" crate to code generation crates (e.g., slint-macro or slint-build).
  • This would allow us to surface relevant errors when required features are not enabled (e.g., detecting if Qt is available for backend-qt).
  • Currently, we rely on hacks like the SLINT_DEFAULT_STYLE.txt, which is unreliable.

• Feature flags based on system dependencies:

  • build.rs currently cannot influence features. It would be useful to enable or disable features based on detected system dependencies (e.g., disabling the backend-winit crate if Qt is found on the system).
  • A configure.rs-like system would address this need.

• Simpler disabling of individual default features Ability to disable individual default features rust-lang/cargo#3126:
  An easier mechanism to selectively disable default features would help as we have many default features and they need to be repeated in each depending crates.

In cargo-semver-check:

• Cross-crate item checks Tracking issue: Checking cross-crate items obi1kenobi/cargo-semver-checks#638:
  The slint crate exposes many types from internal crates, which need checking.