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::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. rust-analyzer error in the slint! macro when using dashes #685 (done)

• 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.

• Nice to have to get better user experience when there are errors in the slint! macro: Support for fatal compile_error that suppresses subsequent errors rust-lang/rust#68838

• non_exhaustive_omitted_patterns Tracking Issue for #![feature(non_exhaustive_omitted_patterns_lint)] rust-lang/rust#89554 which we already use in our CI to get warnings if we miss some new added enum variant in some places.

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.

• Unstable features stable/unstable/nightly-only features rust-lang/cargo#10881:
  For experimental features and so we can expose crates that don't have the same stability as us in the public API (eg: winit, wgpu)

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.