Using impl trait across crates results in linker error #35870
Labels
A-impl-trait
Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.
A-linkage
Area: linking into static, shared libraries and binaries
C-bug
Category: This is a bug.
Comments
|
cc @rust-lang/compiler I have seen some warnings along these lines, that we need to change what we internalize to not include what |
|
Due to this check, this can be worked around by marking It looks like the actual issue is that privacy can't mark the returned type as reachable, since it's not yet known when privacy is checked. Normally, the privacy checker marks all types used in interfaces as reachable. This information is then used for computing the set of externally reachable symbols (which are then excluded from being internalized). |
|
@jonas-schievink That's syntactical, we should be able to make it simpler by running it after typeck. |
I don't think *That FIXME is wrong. |
|
@jonas-schievink Thanks for providing a workaround! :) |
eddyb
added a commit
to eddyb/rust
that referenced
this issue
Aug 22, 2016
rustc: Fix outdated comment cc rust-lang#35870 (comment) r? @eddyb
sophiajt
pushed a commit
to sophiajt/rust
that referenced
this issue
Aug 22, 2016
rustc: Fix outdated comment cc rust-lang#35870 (comment) r? @eddyb
sophiajt
pushed a commit
to sophiajt/rust
that referenced
this issue
Aug 22, 2016
rustc: Fix outdated comment cc rust-lang#35870 (comment) r? @eddyb
bors
added a commit
that referenced
this issue
Nov 28, 2016
[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions. _This is part of a series ([prev](#37412) | [next](#37688)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well. If any motivation is unclear, please ask for additional PR description clarifications or code comments._ <hr> Previously, a path like `T::Assoc::method`, while equivalent to `<<T>::Assoc>::method`, wasn't desugared in any way at the HIR level and everything inspecting it had to either deal with knowing only `T` (before typeck) or knowing only the definition of `method` (after typeck). Such a path also had only one `NodeId` and associated resolution during typeck modified `DefMap`, in a way that would be hard for incremental recompilation to track, and inconvenient for partial type conversions from HIR to `Ty`, which are required to break faux-cycles in on-demand type collection. The desugarings performed by this PR are as follows: * `use a::{b,c};` is flattened to `use a as _; use a::b; use a::c;` * as resolution is complete, `use a as _;` doesn't do anything, except get checked for stability * `Vec::new` (an expression) becomes `Vec<..>::new<..>`, to distinguish it from `<Vec>::new<..>` * the "infer all parameters" `<..>` form is internal and not even pretty-printed * used when there are no type parameters at all, in an expression or pattern path segment * `T::A::B` becomes `<<T>::A>::B` in a type, and `<<T<..>>::A<..>>::B<..>` in an expression/pattern * one additional `hir::Ty` node is created for each prefix, starting with the fully-resolved type (`T`) and extending it with each segment (e.g. `<T>::A`) * fully-resolved paths contain their `Def` in HIR, getting rid of the `DefMap` and absolving incremental recompilation of needing to manually look up nodes to handle that side information Not keeping the `DefMap` around meant that associated resolutions had to be stored somewhere else: * expressions and patterns use a new `NodeId -> Def` map in `ty::Tables` * compatible with the future per-body (constant / `fn` / closure) `Tables` * types are accessible via `Ty` and the usual per-item generics / predicates / type * `rustdoc` and `save-analysis` are the only situations which insist on mapping syntactical types to semantical ones, or at least understand the resolution of associated types, therefore the type conversion cache, i.e. a `NodeId -> Ty` map, is exposed by typeck for this purpose * stability had to be split into a pass that runs on HIR and checks the results of name resolution, and impromptu checks triggered by `typeck` for associated paths, methods, fields, etc. * privacy using semantic types results in accurate reachability for `impl Trait`, which fixes #35870, and thorough introspection of associated types, which may allow relaxing private-in-public checking on bounds, while keeping the intended ban on projections with private type parameters cc @petrochenkov
|
I'm not sure this is actually fixed. I'm still seeing this error on latest nightly (2017-03-03) when compiling mit-pdos/noria@6adf44d. Interestingly, it only happens on some machines (despite having the same nightly). Notably travis fails, but my laptop works fine. An older machine running Ubuntu 16.04 also fails. |
|
Fails with Travis: |
|
@jonhoo Do the different failures show different symbol names, given the exact same Rust nightly? |
|
The ones that fail all error out on
which is where a future is returned in a method whose return type is Fails on five different machines:
Also
Builds fine on two other machines running It sounds like this might be an Ubuntu issue? |
|
@eddyb Note also that this linking error happens between a binary and a library in the same crate. |
|
@michaelwoerister @petrochenkov Anything jump out, any known limitations to symbol exports? |
Mark-Simulacrum
added
A-impl-trait
|
Um, I presume this is fixed by now? |
osa1
added a commit
to osa1/rust
that referenced
this issue
Feb 28, 2021
Apparently rust-lang#35870 caused a problem in this code (which originally returned an impl trait) and `#[inline]` was added as a workaround, in ade79d7. The issue is now fixed and the comment and `#[inline]` can now be removed.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 2, 2021
…mulacrum Remove an old FIXME comment and inline attribute Apparently rust-lang#35870 caused a problem in this code (which originally returned an impl trait) and `#[inline]` was added as a workaround, in ade79d7. The issue is now fixed and the comment and `#[inline]` can now be removed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a small test case that doesn't work in its current state (split into two crates), producing a linker error; but works when everything is moved into one crate: https://github.com/jplatte/rust-impl-trait-across-crates
Error:
The text was updated successfully, but these errors were encountered: