-
Notifications
You must be signed in to change notification settings - Fork 733
Description
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 forproc_macro::Span
inspection APIs rust-lang/rust#54725:
To enable resolving file paths (e.g., in@image-url("...")
orimport from "..."
) relative to theslint!
macro's location, rather than being relative toCARGO_MANIFEST_PATH
. -
Span::column
andSpan::line
, orSpan::byte_range
Tracking issue forproc_macro::Span
inspection APIs rust-lang/rust#54725:
This would allow distinguishing betweenfoo-bar
andfoo - bar
in theslint!
macro. Currently, we parse theDebug
implementation ofSpan
, which is not future-proof, and not compatible rust-analyzer. rust-analyzer error in theslint!
macro when using dashes #685 -
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 theslint!
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
orslint-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.
- We'd like better mechanisms to communicate features from the "runtime" crate to code generation crates (e.g.,
-
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 thebackend-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:
Theslint
crate exposes many types from internal crates, which need checking.