Implement --extern-location
#72603
Implement --extern-location
#72603
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
When I saw |
|
@tshepang Yes, I have a tendency to over-abbr. |
9c0c9fe to
bd9b98c
Compare
This comment has been minimized.
This comment has been minimized.
2951ba5 to
bf1c504
Compare
This comment has been minimized.
This comment has been minimized.
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
This is great, thank you. I'll leave a few notes and questions in comments below. |
Note 1 - MotivationThis is useful not only for the All "cannot find or load crate" errors, name ambiguity errors during resolution, lint for private dependencies (#44663), perhaps something else. |
Note 2 - Dependency trackingWhen file is loaded into source map during conversion into a span that file also becomes a dependency for the build. Looks like PR puts the files specified in Lazy loading may be inconvenient in some cases when we want to work with spans uniformly, though. |
Note 3 - Relative pathIf the path in Will cargo and other tools use absolute or relative paths in practice? |
Note 4 - Command line length compressionSomewhat related to note 3. If tools start using absolute paths for In practice all the paths from cargo will refer to the same |
Note 5 - Over-engineeringAre 4 types of extern locations really necessary? |
|
@petrochenkov Thank you very much for taking the time to look at this. 1: Yes, I hadn't really considered other uses, but I'm glad there are some. 2: I was concerned about the Spans becoming part of the state of the build, both as dependencies, and for incremental builds. I wasn't sure if it was desirable or not, or what the effects would be. It sounds like it's not an issue, and even desirable. 3: I think the path should be relative to 4: I was a little concerned about command-line expansion, but ultimately decided that it isn't an issue we need to solve now - it could be added later if experience shows that it's necessary. It's proportional to the number of direct dependencies a crate has, which doesn't seem to be large - I haven't done a systematic survey, but my gut says that it's going to be almost always <50. It would be a different matter if it also affected indirect dependencies. If it is needed, then I'm thinking of some scheme of adding a new option to give short ids to paths, and a new location type to reference them, eg, 5: I have a local change to remove One thing I'd like to highlight is that the |
|
Thinking about raw vs json a bit more - the |
|
✌️ @jsgf can now approve this pull request |
|
☔ The latest upstream changes (presumably #79078) made this pull request unmergeable. Please resolve the merge conflicts. |
This allows a build system to indicate a location in its own dependency
specification files (eg Cargo's `Cargo.toml`) which can be reported
along side any unused crate dependency.
This supports several types of location:
- 'json' - provide some json-structured data, which is included in the json diagnostics
in a `tool_metadata` field
- 'raw' - emit the provided string into the output. This also appears as a json string in
`tool_metadata`.
If no `--extern-location` is explicitly provided then a default json entry of the form
`"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.
...so we can skip serializing `tool_metadata` if it hasn't been set. This makes the output a bit cleaner, and avoiding having to update a bunch of unrelated tests.
This will make sure the encoder will get updated if any new fields are added to Diagnostic.
|
@bors r+ |
|
📌 Commit 91d8c3b has been approved by |
|
@bors r=nikomatsakis |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit 91d8c3b has been approved by |
|
☀️ Test successful - checks-actions |
This PR implements
--extern-locationas a followup to #72342 as part of the implementation of #57274. The goal of this PR is to allow rustc, in coordination with the build system, to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml).EDIT: Updated to current PR state.
The location is specified for each named crate - that is, for a given
--extern foo[=path]there can also be--extern-location foo=<location>. It supportsthreetwo styles of location:~~1.
--extern-location foo=file:<path>:<line>- a file path and line specification--extern-location foo=span:<path>:<start>:<end>- a span specified as a file and start and end byte offsets~~--extern-location foo=raw:<anything>- a raw string which is included in the output--extern-location foo=json:<anything>- an arbitrary Json structure which is emitted via Json diagnostics in atool_metadatafield.1 & 2 are turned into an internalSpan, so long as the path exists and is readable, and the location is meaningful (within the file, etc). This is used as theSpanfor a fix suggestion which is reported like other fix suggestions.rawandjsonare for the case where the location isn't best expressed as a file and location within that file. For example, it could be a rule name and the name of a dependency within that rule.rustcmakes no attempt to parse the raw string, and simply includes it in the output diagnostic text.jsonis only included in json diagnostics.rawis emitted as text and also as a json string intool_metadata.If no
--extern-locationoption is specified then it will emit a default json structure consisting of{"name": name, "path": path}corresponding to the name and path in--extern name=path.This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well.
NOTE The first commit in this PR is #72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only, presented as a MVP. The second implements the full thing, and subsequent commits are incremental fixes.cc @ehuss @est31 @petrochenkov @estebank