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

Match assumes extern statics stay the same forever #8694

Closed
bytwise opened this issue Aug 23, 2013 · 2 comments
Closed

Match assumes extern statics stay the same forever #8694

bytwise opened this issue Aug 23, 2013 · 2 comments

Comments

@bytwise
Copy link
Contributor

bytwise commented Aug 23, 2013

The code:

// aux.rs
#[crate_type = "lib"];
pub static Foo: uint = 1;
// main.rs
extern mod aux;
fn main() {
    let x = aux::Foo;
    match x {
        aux::Foo => println("Foo == Foo"),
        _ => println("Foo != Foo")
    }
}

produces the expected output: Foo == Foo
But after changing aux.rs to

#[crate_type = "lib"];
pub static Foo: uint = 2;

and recompiling only aux.rs, the output is Foo != Foo

This is because rustc is too eager and replaces the match pattern aux::Foo with 1 at compile-time. That works until we change aux::Foo. Because x gets its value at runtime, it becomes 2 and doesn't fit the first match arm.

@nikomatsakis
Copy link
Contributor

This is not (necessarily) too eager. You are expected to recompile if
static constants change (the same is true in many languages). There is
however a need to clearly and explicitly lay out the conditions in
which a recompile is expected.

@alexcrichton
Copy link
Member

This is working as intended. Changing a static is like changing a #define in a header file. C/C++ don't magically recompile object files, you have to explicitly lay out dependencies.

This would fall under the purview of a project like rustpkg, but there is currently no form of dependency management between crates.

Due to working as intended, I'm closing this issue. It's well understood that dependency management is not ideal today, but I don't think that this is the right issue to track that in.

flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 11, 2022
More proc-macro detection

fixes rust-lang#6514
fixes rust-lang#8683
fixes rust-lang#6858
fixes rust-lang#6594

This is a more general way of checking if an expression comes from a macro and could be trivially applied to other lints. Ideally this would be fixed in rustc's proc-macro api, but I don't see that happening any time soon.

changelog: FPs: [`unit_arg`] [`default_trait_access`] [`missing_docs_in_private_items`]: No longer trigger in code generated from proc-macros.
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 11, 2022
Use `check_proc_macro` for `missing_const_for_fn`

This uses `@Jarcho's` rust-lang#8694 implementation to fix `missing_const_for_fn` linting in proc-macros.
I'm not 100% sure what I'm doing here, any feedback is appreciated.

Previously: Jarcho/rust-clippy#1.
Fixes rust-lang#8854.

changelog: [`missing_const_for_fn`]: No longer lints in proc-macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants