Skip to content

Add a macro to track a file #73921

@GuillaumeGomez

Description

@GuillaumeGomez
Member

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. :)

Activity

changed the title [-]Add a macro to track a file last modification time[/-] [+]Add a macro to track a file[/+] on Jul 1, 2020
Mark-Simulacrum

Mark-Simulacrum commented on Jul 1, 2020

@Mark-Simulacrum
Member

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

estebank commented on Jul 1, 2020

@estebank
Contributor

Isn't this already supported using build.rs?

ehuss

ehuss commented on Jul 3, 2020

@ehuss
Contributor

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

ehuss commented on Aug 3, 2020

@ehuss
Contributor

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

petrochenkov commented on Aug 3, 2020

@petrochenkov
Contributor

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

luser commented on Sep 29, 2020

@luser
Contributor

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.

This is #55904

20 remaining items

sunshowers

sunshowers commented on Jul 20, 2021

@sunshowers
Contributor

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

abonander commented on Jul 20, 2021

@abonander
Contributor

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 &strs.

Do we have anything against having two different functions? Say, path_str(impl AsRef<str>) and path(impl AsRef<Path>), where the former is infallible?

pksunkara

pksunkara commented on Aug 11, 2021

@pksunkara
Contributor

Tangential question: What's the path forward to stabilize this? I don't see any other PRs which are tracking this feature.

drahnr

drahnr commented on Aug 11, 2021

@drahnr
Contributor

@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

abonander commented on Aug 12, 2021

@abonander
Contributor

@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

drahnr commented on Aug 12, 2021

@drahnr
Contributor

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.

@abonander indeed, I'll document the behaviour on relative paths and which base will be used in detail.

removed their assignment
on Mar 27, 2022
m-ou-se

m-ou-se commented on Jul 20, 2022

@m-ou-se
Member

This is now tracked in #99515, together with the tracked_env feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-proc-macrosArea: Procedural macrosC-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-langRelevant to the language team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ehuss@pksunkara@sunshowers@luser@drahnr

        Issue actions

          Add a macro to track a file · Issue #73921 · rust-lang/rust