Rustpkg should operate on a URL-like pkgid #5679
Labels
E-hard
Call for participation: Hard difficulty. Experience needed to fix: A lot.
Milestone
Comments
ghost
assigned
This was referenced Apr 2, 2013
catamorphism
added a commit
to catamorphism/rust
that referenced
this issue
Apr 12, 2013
…to declare IDs explicitly This is preliminary work on bringing rustpkg up to conformance with rust-lang#5679 and related issues. This change makes rustpkg infer a package ID from its containing directory, instead of requiring name and vers attributes in the code. Many aspects of it are incomplete; I've only tested one package (see README.txt) and one command, "build". So far it only works for local packages. I also removed code for several of the package commands other than "build", replacing them with stubs that fail, since they used package IDs in ways that didn't jibe well with the new scheme. I will re-implement the commands one at a time.
bors
added a commit
that referenced
this issue
Apr 12, 2013
r? @graydon This is preliminary work on bringing rustpkg up to conformance with #5679 and related issues. This change makes rustpkg infer a package ID from its containing directory, instead of requiring name and vers attributes in the code. Many aspects of it are incomplete; I've only tested one package (see README.txt) and one command, "build". So far it only works for local packages. I also removed code for several of the package commands other than "build", replacing them with stubs that fail, since they used package IDs in ways that didn't jibe well with the new scheme. I will re-implement the commands one at a time.
|
#6418 will close this. |
|
6a9c3bd fixes this. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Nov 5, 2020
…r=flip1995 Add lint: from_iter_instead_of_collect Fixes rust-lang#5679 This implements lint for `::from_iter()` from rust-lang#5679 not the general issue (`std::ops::Add::add`, etc.). This lint checks if expression is function call with `from_iter` name and if it's implementation of the `std::iter::FromIterator` trait. changelog: Introduce from_iter_instead_of_collect lint
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sub-bug of #5677
Rustpkg and the rust driver currently have several kinds of identifier for packages and crates: the
name,urlanduuidfields in#[link]andextern modas well as the putativeidof a rustpkg (which is being sketched-out as a reverse-DNS-dot-path the way java packages were named). These are terribly confusing and lead people to randomly cargo-culting variants of redundant sub-naming schemes, few of which are meaningful.We want to consolidate these as much as possible, and will be following the design of the Go package-naming system, though with a slight simplification in that our packages aren't "self identifying" -- there's no
package foo;declaration in each file, for example -- so don't have a separate (default) name aside from their pkgid stem ("import path" stem, in Go-ese). Those can vary in Go but there doesn't seem to be much point to allowing it for us. They exist in Go to disambiguate exported symbols at the linkage level, but our linkage model encodes the metadata-hash (likely, eventually, just a hash of the pkgid) in each symbol, so we're solving this a different (and hopefully less confusing, more robust) way. If you absolutely need to vary the module-local name a crate is bound under when youextern modit, you'll be able to; the default will be automatically derived from the pkgid stem. I.e.extern mod "github.com/graydon/foo";will produce a local bindingfoo, and you'll have to writeextern mod bar = "github.com/graydon/foo";to get a different local name.An example structure for holding a path is here:
https://github.com/graydon/rust/blob/rustpkg/src/librustpkg/rustpkg.rc#L1046
The main points to ensure are these:
Crate names should be deduced from the directory containing them, rather than a
#[link]attribute inside the crate file. This should work whether a package has one or many crates within it: the immediate containing dir provides the short identifier-name for the crate, and this just happens to be the stem of the pkgid if there is only a single crate in the package (and the crate root is found in the package root).The text was updated successfully, but these errors were encountered: