You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hot_module attribute macro (via hot_functions_from_file!("path/to/file.rs")) and the define_lib_reloader!(...) macro allow specifying Rust source files from which public #[no_mangle] functions are discovered and for which hot-reloadable proxy functions are created.
So far, both macros expected file relative paths, i.e. paths relative to the file where the macro was defined. So, for example:
The reasoning behind it was that it might be more intuitive and easier to reason about with larger code bases but there are two problems that requiring a relative path created:
We need Rust nightly to use the proc_macro::Span feature to lookup the path of the file in which the macro was declared
rust-analyzer fails to expand the macro and cannot give code completion
Thinking about it again, requiring that the path of the files to be relative to the project root is not so bad and will solve both of the problems above. But it means that we need to break the interface. For this reason this change requires a version bump to v0.6.
So` instead of the above, the following will be expected:
The
hot_module
attribute macro (viahot_functions_from_file!("path/to/file.rs")
) and thedefine_lib_reloader!(...)
macro allow specifying Rust source files from which public#[no_mangle]
functions are discovered and for which hot-reloadable proxy functions are created.So far, both macros expected file relative paths, i.e. paths relative to the file where the macro was defined. So, for example:
Code for this is here: https://github.com/rksm/hot-lib-reloader-rs/blob/cb016a03c68ea2fb2176b683ff466d8bdb8f94e0/macro/src/util.rs
The reasoning behind it was that it might be more intuitive and easier to reason about with larger code bases but there are two problems that requiring a relative path created:
proc_macro::Span
feature to lookup the path of the file in which the macro was declaredThinking about it again, requiring that the path of the files to be relative to the project root is not so bad and will solve both of the problems above. But it means that we need to break the interface. For this reason this change requires a version bump to v0.6.
So` instead of the above, the following will be expected:
The text was updated successfully, but these errors were encountered: