-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-proc-macrosArea: Procedural macrosArea: Procedural macrosC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-langRelevant to the language teamRelevant to the language team
Description
I recently released doc-comment
0.4 which converted declarative macros to proc-macros. I encountered a "funny" issue though: I needed the compiler to track files that were included using my proc-macros. In order to do so, I generated anonymous constants which looked like this:
const _: &'static str = include_str!("file.md");
However, I have no use for those constants and they make the source code heavier for just keeping track of a file. Therefore, I propose to add a track!("file")
macro which would allow to track files like include_str!
without requiring the usage of anonymous constants.
I can make the implementation if the rust teams agree to add this feature. :)
drahnr, jgarvin, zetanumbers, tjkirch, SeaDve and 1 morecyqsimonfinnbear
Metadata
Metadata
Assignees
Labels
A-proc-macrosArea: Procedural macrosArea: Procedural macrosC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-langRelevant to the language teamRelevant to the language team
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
[-]Add a macro to track a file last modification time[/-][+]Add a macro to track a file[/+]Mark-Simulacrum commentedon Jul 1, 2020
IMO, the proper solution is to add proc_macro APIs that indicate "interest" in a file, rather than further expanding the set of macros.
estebank commentedon Jul 1, 2020
Isn't this already supported using
build.rs
?ehuss commentedon Jul 3, 2020
The user of the proc-macro would need to add it to their
build.rs
, which is a bit tedious (and I suspect most people won't even know they should do that). It would also cause the entire build script to rerun, which could be quite expensive if it is doing other unrelated things. Build scripts can also be tricky for inexperienced users (such as requiring "rerun-if-changed=build.rs" to avoid full rebuilds).I've seen it mentioned in several places where there is desire to register change detection for various things (including environment variables mentioned here).
Grepping through crates.io, I found about 10 proc-macros that use the include_str/include_bytes trick to force a dependency check.
ehuss commentedon Aug 3, 2020
cc #74690, where the ability to register the usage of an environment variable was added. I would suspect adding support for tracking files could use a similar mechanism. I'm not sure if this specifically needs to use a macro, or if a function call would be sufficient (
tracked_env::file(...)
?tracked_env::path(...)
?).petrochenkov commentedon Aug 3, 2020
The bare minimum would be ability to add file paths to dependencies.
However, it would be significantly more useful to also have ability to load the file into a token stream and create a source map for it, so all the spans are assigned properly.
luser commentedon Sep 29, 2020
This is #55904
20 remaining items
sunshowers commentedon Jul 20, 2021
yeah, depinfo is an instance of what I call the "makefile problem". Given that rustc uses these files, should it support non-utf8 paths at all? cargo already doesn't.
I guess you don't need cross-platform support for depinfo files, so the case is a bit less strong for rustc than for cargo.
abonander commentedon Jul 20, 2021
There's a couple orthogonal concerns here:
The API really needs to document what it does with relative paths. If it's purely up to whatever is consuming the depinfo then that should be documented as well, though it would also be very helpful to describe how Cargo treats it in that case. SQLx's proc macros are already written with the assumption that Cargo is being used, although that has also drawn a few complaints.
If we don't want to specify the behavior with relative paths and just tell the user to always canonicalize the path, that's okay. We just need to say one way or the other.
As for non-UTF-8 paths, I'm torn. In SQLx's case the paths are taken from string literals in the macro input so they should always be UTF-8.
If I knew I didn't need to manipulate the paths at all, I'd be perfectly fine with the function taking
impl AsRef<str>
.If the treatment of relative dirs was specified but differed from my expectation, say for example, I'm expecting the paths to be relative to the crate root whereas Cargo interprets the paths relative to the workspace root, then I would still need to do path manipulation and
impl AsRef<Path>
would be nicer.For sanity if we take
impl AsRef<Path>
then the function should be fallible and return an error on non-UTF-8 paths. That's just the sanest way to do it and lets the proc macro keep control over what to do next. However, that's an unnecessary annoyance if you're always dealing with paths as&str
s.Do we have anything against having two different functions? Say,
path_str(impl AsRef<str>)
andpath(impl AsRef<Path>)
, where the former is infallible?pksunkara commentedon Aug 11, 2021
Tangential question: What's the path forward to stabilize this? I don't see any other PRs which are tracking this feature.
drahnr commentedon Aug 11, 2021
@pksunkara the PR #87173 is probably the next step.
@abonander Adding two versions seems excessive compared to the feature provided, #87173 (comment) resolves this by a steering meeting discussion outcome, to use a
Path
based argument in order to not limit the API to the limitations of today's implemention.I am not aware of any further issues at this point.
abonander commentedon Aug 12, 2021
@drahnr please see my concerns above about specifying the semantics regarding relative paths and directories, that doesn't appear to have been discussed at all in the linked PR.
drahnr commentedon Aug 12, 2021
@abonander indeed, I'll document the behaviour on relative paths and which base will be used in detail.
include_str!
to trigger recompile when sample file changes evestera/json_typegen#35SourceMap
#92565embed_migrations!
macro doesn't pick up new migration files due to cargo build cache diesel-rs/diesel#3119m-ou-se commentedon Jul 20, 2022
This is now tracked in #99515, together with the
tracked_env
feature.flate!
doesn't automatically trigger rebuild SOF3/include-flate#12