@@ -227,7 +227,6 @@ pub fn get_extern_const<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: ast::DefId,
227
227
// FIXME(nagisa): perhaps the map of externs could be offloaded to llvm somehow?
228
228
// FIXME(nagisa): investigate whether it can be changed into define_global
229
229
let c = declare:: declare_global ( ccx, & name[ ..] , ty) ;
230
-
231
230
// Thread-local statics in some other crate need to *always* be linked
232
231
// against in a thread-local fashion, so we need to be sure to apply the
233
232
// thread-local attribute locally if it was present remotely. If we
@@ -239,42 +238,7 @@ pub fn get_extern_const<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: ast::DefId,
239
238
llvm:: set_thread_local ( c, true ) ;
240
239
}
241
240
}
242
-
243
- // MSVC is a little ornery about how items are imported across dlls, and for
244
- // lots more info on dllimport/dllexport see the large comment in
245
- // SharedCrateContext::new. Unfortunately, unlike functions, statics
246
- // imported from dlls *must* be tagged with dllimport (if you forget
247
- // dllimport on a function then the linker fixes it up with an injected
248
- // shim). This means that to link correctly to an upstream Rust dynamic
249
- // library we need to make sure its statics are tagged with dllimport.
250
- //
251
- // Hence, if this translation is using dll storage attributes and the crate
252
- // that this const originated from is being imported as a dylib at some
253
- // point we tag this with dllimport.
254
- //
255
- // Note that this is not 100% correct for a variety of reasons:
256
- //
257
- // 1. If we are producing an rlib and linking to an upstream rlib, we'll
258
- // omit the dllimport. It's a possibility, though, that some later
259
- // downstream compilation will link the same upstream dependency as a
260
- // dylib and use our rlib, causing linker errors because we didn't use
261
- // dllimport.
262
- // 2. We may have multiple crate output types. For example if we are
263
- // emitting a statically linked binary as well as a dynamic library we'll
264
- // want to omit dllimport for the binary but we need to have it for the
265
- // dylib.
266
- //
267
- // For most every day uses, however, this should suffice. During the
268
- // bootstrap we're almost always linking upstream to a dylib for some crate
269
- // type output, so most imports will be tagged with dllimport (somewhat
270
- // appropriately). Otherwise rust dylibs linking against rust dylibs is
271
- // pretty rare in Rust so this will likely always be `false` and we'll never
272
- // tag with dllimport.
273
- //
274
- // Note that we can't just blindly tag all constants with dllimport as can
275
- // cause linkage errors when we're not actually linking against a dll. For
276
- // more info on this see rust-lang/rust#26591.
277
- if ccx. use_dll_storage_attrs ( ) && ccx. upstream_dylib_used ( did. krate ) {
241
+ if ccx. use_dll_storage_attrs ( ) {
278
242
llvm:: SetDLLStorageClass ( c, llvm:: DLLImportStorageClass ) ;
279
243
}
280
244
ccx. externs ( ) . borrow_mut ( ) . insert ( name. to_string ( ) , c) ;
0 commit comments