Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

path attribute is silently accepted and ignored for inline mod items. #13156

Closed
pnkfelix opened this issue Mar 26, 2014 · 2 comments
Closed

path attribute is silently accepted and ignored for inline mod items. #13156

pnkfelix opened this issue Mar 26, 2014 · 2 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

Consider the following program p.rs:

#[path="q.rs"] mod q {
    pub fn q_main() { println!("Hello World"); }
}

fn main() { q::q_main() }

I don't know if this is considered a bug or a feature, but we should probably emit a warning when we encounter that useless path attribute attached to q above.

@steveklabnik steveklabnik added I-papercut A-diagnostics Area: Messages for errors, warnings, and lints labels Jan 23, 2015
@gkoz
Copy link
Contributor

gkoz commented Feb 2, 2016

Doesn't seem useless to me. The reference gives this seemingly reasonable example:

The directories and files used for loading external file modules can be influenced with the path attribute.

#[path = "thread_files"]
mod thread {
    // Load the `local_data` module from `thread_files/tls.rs`
    #[path = "tls.rs"]
    mod local_data;
}

Now suppose you're in a build script and want to include src/tls.rs. Is there a better way than

// This module hides some optional stuff
#[cfg(foo_bar)]
#[path = ""]
mod thread {
    #[path = "src/tls.rs"]
    mod local_data;
}

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum
Copy link
Member

Yeah, to my knowledge this is expected and intentional behavior; closing.

JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Sep 6, 2022
Remove hir::Expr::MacroStmts

This hir expression isn't needed and only existed as it was simpler to
deal with at first as it gave us a direct mapping for the ast version of
the same construct. This PR removes it, properly handling the statements
that are introduced by macro call expressions.
dingxiangfei2009 pushed a commit to dingxiangfei2009/rust that referenced this issue Jul 28, 2024
…=xFrednet

Remove unnecessary `res` field in `for_each_expr` visitors

Small refactor in the `for_each_expr*` visitors. This should not change anything functionally.

Instead of storing the final value `Option<B>` in the visitor and setting it to `Some` when we get a `ControlFlow::Break(B)` from the closure, we can just directly return it from the visitor itself now that visitors support that.

cc rust-lang#12829 and rust-lang/rust-clippy#12830 (comment)

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants