-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Implement RFC 1717 #37973
Implement RFC 1717 #37973
Changes from 1 commit
bc019df
4508e8a
13477c7
a9a6f8c
a23c470
923034f
2e03549
b700dd3
7d05d1e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- 1.85.1
- 1.85.0
- 1.84.1
- 1.84.0
- 1.83.0
- 1.82.0
- 1.81.0
- 1.80.1
- 1.80.0
- 1.79.0
- 1.78.0
- 1.77.2
- 1.77.1
- 1.77.0
- 1.76.0
- 1.75.0
- 1.74.1
- 1.74.0
- 1.73.0
- 1.72.1
- 1.72.0
- 1.71.1
- 1.71.0
- 1.70.0
- 1.69.0
- 1.68.2
- 1.68.1
- 1.68.0
- 1.67.1
- 1.67.0
- 1.66.1
- 1.66.0
- 1.65.0
- 1.64.0
- 1.63.0
- 1.62.1
- 1.62.0
- 1.61.0
- 1.60.0
- 1.59.0
- 1.58.1
- 1.58.0
- 1.57.0
- 1.56.1
- 1.56.0
- 1.55.0
- 1.54.0
- 1.53.0
- 1.52.1
- 1.52.0
- 1.51.0
- 1.50.0
- 1.49.0
- 1.48.0
- 1.47.0
- 1.46.0
- 1.45.2
- 1.45.1
- 1.45.0
- 1.44.1
- 1.44.0
- 1.43.1
- 1.43.0
- 1.42.0
- 1.41.1
- 1.41.0
- 1.40.0
- 1.39.0
- 1.38.0
- 1.37.0
- 1.36.0
- 1.35.0
- 1.34.2
- 1.34.1
- 1.34.0
- 1.33.0
- 1.32.0
- 1.31.1
- 1.31.0
- 1.30.1
- 1.30.0
- 1.29.2
- 1.29.1
- 1.29.0
- 1.28.0
- 1.27.2
- 1.27.1
- 1.27.0
- 1.26.2
- 1.26.1
- 1.26.0
- 1.25.0
- 1.24.1
- 1.24.0
- 1.23.0
- 1.22.1
- 1.22.0
- 1.21.0
- 1.20.0
- 1.19.0
- 1.18.0
- 1.17.0
- 1.16.0
- 1.15.1
- 1.15.0
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -232,6 +232,23 @@ impl CStore { | |
self.used_libraries.borrow_mut().push(lib); | ||
} | ||
|
||
// Update kind and, optionally, the name of all native libaries (there may be more than one) | ||
// with the specified name. | ||
pub fn update_used_library(&self, name: &str, new_name: Option<&str>, | ||
new_kind: NativeLibraryKind) -> bool { | ||
let mut found = false; | ||
for item in self.used_libraries.borrow_mut().iter_mut() { | ||
if item.name == name { | ||
item.kind = new_kind; | ||
if let Some(new_name) = new_name { | ||
item.name = Symbol::intern(new_name); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we take an extra conservative route here and avoid multiple indirections of libraries? Ideally each library would be renamed at most once and wouldn't have to worry about what order we process options in. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure what you mean by "multiple indirections"... Is this about the fact that there may be several There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh I mean something like:
We shouldn't allow something like that and a lib should be "renamed" at most once. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok. Just want to note that this behavior is occasionally useful when you want to override something by appending to a pre-composed command line (usually comes up in makefiles and such). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @alexcrichton: How far did you want to take this checking? Currently the following are allowed: Under the new rules, this will merely change the kind of It feels a bit weird to allow chaining for kind alterations, but not for names. Perhaps this part of the RFC merits additional discussion. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm that does sound like an unfortunate "regression", but I'd imagine that in practice that was doomed to never link correctly anyway? It does seem like we can't strictly require that |
||
} | ||
found = true; | ||
} | ||
} | ||
found | ||
} | ||
|
||
pub fn get_used_libraries(&self) -> &RefCell<Vec<NativeLibrary>> { | ||
&self.used_libraries | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
// Copyright 2016 The Rust Project Developers. See the COPYRIGHT | ||
// file at the top-level directory of this distribution and at | ||
// http://rust-lang.org/COPYRIGHT. | ||
// | ||
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or | ||
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license | ||
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your | ||
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// no-prefer-dynamic | ||
#![crate_type = "staticlib"] | ||
|
||
#[no_mangle] | ||
pub extern "C" fn foo(x:i32) -> i32 { x } |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
// Copyright 2016 The Rust Project Developers. See the COPYRIGHT | ||
// file at the top-level directory of this distribution and at | ||
// http://rust-lang.org/COPYRIGHT. | ||
// | ||
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or | ||
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license | ||
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your | ||
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// aux-build:clibrary.rs | ||
// compile-flags: -lstatic=wronglibrary:clibrary | ||
|
||
#[link(name = "wronglibrary", kind = "dylib")] | ||
extern "C" { | ||
pub fn foo(x:i32) -> i32; | ||
} | ||
|
||
fn main() { | ||
unsafe { | ||
foo(42); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case the
new_name
is thrown away, but isn't that the name the library should be linked under?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Yes, I should use
new_name
here, if available.Probably also emit a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm actually given the option to do so let's make this a hard error to be conservative.