diff options
| author | Mazdak Farrokhzad <twingoow@gmail.com> | 2019-09-25 03:48:22 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-09-25 03:48:22 +0200 |
| commit | 40fae88fa82db350f1233b9b93df0be30e6579bc (patch) | |
| tree | 988ea8d7ef3a56d1cc4b191d26639ad91ad03b5f /src/libsyntax | |
| parent | dcd473d7b554a82013913244da8aba1e22a002a9 (diff) | |
| parent | f00c6346b42d2a3091752166cd86aa2d69112dcc (diff) | |
| download | rust-40fae88fa82db350f1233b9b93df0be30e6579bc.tar.gz rust-40fae88fa82db350f1233b9b93df0be30e6579bc.zip | |
Rollup merge of #64324 - alexcrichton:share-generics-again, r=michaelwoerister
rustc: Fix mixing crates with different `share_generics` This commit addresses #64319 by removing the `dylib` crate type from the list of crate type that exports generic symbols. The bug in #64319 arises because a `dylib` crate type was trying to export a symbol in an uptream crate but it miscalculated the symbol name of the uptream symbol. This isn't really necessary, though, since `dylib` crates aren't that heavily used, so we can just conservatively say that the `dylib` crate type never exports generic symbols, forcibly removing them from the exported symbol lists if were to otherwise find them. The fix here happens in two places: * First is in the `local_crate_exports_generics` method, indicating that it's now `false` for the `Dylib` crate type. Only rlibs actually export generics at this point. * Next is when we load exported symbols from upstream crate. If, for our compilation session, the crate may be included from a dynamic library, then its generic symbols are removed. When the crate was linked into a dynamic library its symbols weren't exported, so we can't consider them a candidate to link against. Overally this should avoid situations where we incorrectly calculate the upstream symbol names in the face of differnet `share_generics` options, ultimately... Closes #64319
Diffstat (limited to 'src/libsyntax')
0 files changed, 0 insertions, 0 deletions
