Skip to content

Allow access to location information from proc_macro TokenStreams #38546

Open

Description

@djc

I would like to build a template engine that leverages custom derive to attach a template rendering function to a struct at compile time. I was planning on attaching an attribute to the struct to specify the path to the template file, which could then be read and transpiled into Rust. However, it seems it is currently not possible to get at the path to the source file where the TokenStream originated. As such, it seems I would have to rely on absolute paths to template files or on the current working directory. Even assuming cargo compiles (including workspaces), this does not seem reliable.

The Items that are part of the TokenStream contain a Span, but I don't think the CodeMap they index into is currently available to a proc_macro. Would that be a viable implementation strategy?

Activity

  1. djc commented on Dec 22, 2016

    @djc
    ContributorAuthor

    My experimental code can be found here: https://github.com/djc/askama

  2. LukasKalbertodt commented on Aug 25, 2017

    @LukasKalbertodt
    Contributor

    Is there any update on this? I need this feature, too: I'm writing a macro that has its own "module system" so to speak. Thus I need to load files form disk relative to the file in which the macro is called.

    @jseyfried @alexcrichton I could try implementing this feature for proc_macro. What do you think? Are there reasons not to expose the current path to the macro author?

  3. alexcrichton commented on Aug 25, 2017

    @alexcrichton
    Member

    There's some work in #43604 but AFAIK there's no movement towards manufacturing custom spans. I know it's something we'd like to support eventually!

  4. abonander commented on Aug 25, 2017

    @abonander
    Contributor

    #43604 is mainly just waiting on review right now.

  5. jyn514 commented on Jul 14, 2021

    @jyn514
    Member
  6. added and removed
    A-syntaxextArea: Syntax extensions
    on Jul 14, 2021
  7. djc commented on Jul 14, 2021

    @djc
    ContributorAuthor

    I have a hard time remembering exactly my intent with this issue from 5 years ago, but I think this would depend on getting proc_macro_span stabilized (for the Span::source_file() method).

  8. abonander commented on Jul 14, 2021

    @abonander
    Contributor

    What would actually be more useful, less work to stabilize and have additional utility, is to basically just be able to resolve a file path the way include!() or include_str!() does, given a span or SourceFile.

    Then like the new proc_macro_tracked_path feature, the compiler could know to watch that file for changes and trigger recompilation.

    @petrochenkov I feel like it would actually make a lot of sense to just combine these. Maybe something like:

    impl SourceFile {
        /// Load a file relative to this source file and parse it as a `TokenStream`.
        ///
        /// The file path will be included in the resulting dep-info and will trigger recompilation when it changes.
        pub fn include(&self, path: impl AsRef<Path>) -> Result<TokenStream, IncludeError> { ... }
    
        /// Load a file relative to this source file as a UTF-8 string.
        ///
        /// The file path will be included in the resulting dep-info and will trigger recompilation when it changes.
        pub fn include_str(path: impl AsRef<Path>) -> Result<String, IncludeError> { ... }
    }

    This would actually fix a long-outstanding issue in SQLx (although I think include_str!() would fix it, just haven't gotten around to trying it): transact-rs/sqlx#663 (comment)

  9. djc commented on Jul 14, 2021

    @djc
    ContributorAuthor

    Yeah, that would be pretty great to have for my use case.

  10. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
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-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions