Re-exporting items using a glob breaks if the module imports another module #4865
Comments
|
Not critical for 0.7. Nominating for milestone 1, well-defined. |
|
accepted for well defined - promises made by the resolve pass need to be written down |
|
Still applies. Here's the updated source code: pub use hello::*; // doesn't work - `pub use hello::hello;` does
pub mod say {
pub fn hello() { println("hello"); }
}
pub mod hello {
use say;
pub fn hello() {
say::hello();
}
}
fn main() {
hello();
}The error is now: The error about |
|
And here's a failing cross-crate example that's very probably related, so I thought I'd add it here instead of opening a new issue. // foo.rs
pub use foo::*;
mod foo {
pub fn foo() { println("foo"); }
}// bar.rs
extern mod foo;
use foo::*;
fn main() {
foo();
}Compilation: |
|
This is still an issue. |
|
@Blei, your second test case (which fails with a linker error), I believe was fixed by #9791. Otherwise I believe that this is another facet of glob imports having circular references causing problems. The imports at the top level of the crate cannot be considered resolved until the glob is resolved, but the glob cannot get resolved until This is one of the reasons why globs are currently behind a feature flag. Their behavior is subtle and unexpected in certain ways, along with them not always having the best error messages. Regardless, leaving open for now as it still reproduces. |
|
Globs are feature gated. Nominating to remove from backcompat-lang. |
|
revised Priority to P-low |
|
Another example (stripped down) from gl-rs: #![crate_type = "lib"]
#![feature(globs)]
extern crate libc;
use std::mem;
use self::types::*;
pub mod types {
use libc;
}
mod storage {
use libc;
}
mod failing {
use libc;
use super::types::*;
} |
Shuffles around how exactly libc is used to work around a nasty bug in glob imports. Unfortunately now requires users of the syntax extension to have an `extern crate libc`.
|
Triage: globs are un-feature gated, but this issue still persists. |
|
Re-nominating because of that |
|
polish issue, 1.0 P-high. (Note that we believe this and other glob bugs we know of are "only" rejecting valid programs, and thus the associated bug can be fixed backwards compatibly.) If someone knows of a case where an invalid program is accepted due to glob bugs, that would be much more severe. |
pnkfelix
added
P-medium
|
P-high 1.1 |
|
I reached this point while reducing an issue, I think it is the same problem, and the testcase is somewhat simpler. pub mod a {
use b::*;
}
pub mod b {
use a::*;
}
use a::*;
fn main() {
} |
|
Still apply. Spend two days getting mad because of this bug. Note that there is no need for the modules to reference each others directly : pub mod a {
use b::fn_b;
use c::*;
pub fn fn_a(){
}
}
pub mod b {
use a::fn_a;
use c::*;
pub fn fn_b(){
}
}
pub mod c{
pub fn fn_c(){
}
}
use a::fn_a;
use b::fn_b;
fn main() {
}Here the star imports (mod::*) are not the modules themself, but another module, the module c. |
|
@gbersac 's test case seems especially frustrating; as he noted, the reported error is for imports that are not glob imports, and yet for some reason the presence of the unrelated glob imports is causing the resolution of the circular non-glob imports to fail. |
|
The final case here is solved by #26242 |
When resolving 'use' statements, only consider pub imports of the target module as blocking. Closes rust-lang#4865
As noted in my previous PR #27439 , the import resolution algorithm has two cases where it bails out: - The algorithm will delay an import if the module containing the target of the import still has unresolved glob imports - The algorithm will delay a glob import of the target module still has unresolved imports This PR alters the behaviour to only bail out when the above described unresolved imports are `pub`, as non-pub imports don't affect the result anyway. It is still possible to fail the algorithm with examples like ```rust pub mod a { pub use b::*; } pub mod b { pub use a::*; } ``` but such configurations cannot be resolved in any meaningful way, as these are cyclic imports. Closes #4865
On stable, running with `--help|-h` shows information about `file-lines` which is a nightly-only option. This commit removes all mention of `file-lines` from the help message on stable. There is room for improvement here; perhaps a new struct called, e.g., `StableOptions` could be added to complement the existing `GetOptsOptions` struct. `StableOptions` could have a field for each field in `GetOptsOptions`, with each field's value being a `bool` that specifies whether or not the option exists on stable. Or is this adding too much complexity?
Results in this error when compiling:
As mentioned in the code, explicitly re-exporting items works but is not a good alternative for when you have hundreds of items (including variants) in a module. Changing the say module to public doesn't fix it.
The text was updated successfully, but these errors were encountered: