-
Notifications
You must be signed in to change notification settings - Fork 13.3k
intra-doc: Use an enum to represent URL fragments #92088
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
Conversation
36f36bb
to
a074157
Compare
@@ -732,7 +764,7 @@ fn resolve_associated_trait_item( | |||
item_name: Symbol, | |||
ns: Namespace, | |||
cx: &mut DocContext<'_>, | |||
) -> Option<(ty::AssocKind, DefId)> { | |||
) -> Option<ty::AssocItem> { |
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.
This change is not strictly necessary, but it seems like a good refactoring. The reason I made the change is that I was going to make UrlFragment::from_assoc_item
take a ty::AssocItem
and use that to get the defaultness, but that caused some tests to fail.
This may affect perf, so @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit a074157f6b4975ebd2d80fac9c588969aab366d5 with merge b097a2fe84360de4b3bc3e854766482bf11c4acf... |
☀️ Try build successful - checks-actions |
Queued b097a2fe84360de4b3bc3e854766482bf11c4acf with parent 91a0600, future comparison URL. |
/// Render the fragment, including the leading `#`. | ||
impl std::fmt::Display for UrlFragment { | ||
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { |
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.
I thought adding a Display
impl would be the best way to go, but I could be convinced of changing this to a method that takes &mut String
or similar because
- it would then have an explanatory method name (e.g., make it clear that it includes the
#
) - it might be more efficient since it avoids the
Result
and usingFormatter
Some((kind, field.did)), | ||
)) | ||
let fragment = if def.is_enum() { | ||
// FIXME: how can the field be a variant? |
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.
This should be fixed after #92075 is merged.
@@ -457,8 +505,8 @@ impl<'a, 'tcx> LinkCollector<'a, 'tcx> { | |||
path_str: &'path str, | |||
ns: Namespace, | |||
module_id: DefId, | |||
extra_fragment: &Option<String>, | |||
) -> Result<(Res, Option<String>), ErrorKind<'path>> { | |||
extra_fragment: &Option<UrlFragment>, |
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.
I believe this and other instances of extra_fragment
are always user-written fragments.
Finished benchmarking commit (b097a2fe84360de4b3bc3e854766482bf11c4acf): comparison url. Summary: This change led to moderate relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
The rustc changes (including in the summary comment) are all spurious. Not sure what to do about those other than cc @rylev (let me know if I should stop pinging you for these). The rustdoc changes show small improvements across many benchmarks. |
max-rss shows small, low-significance regressions, but the biggest regressions are for benchmarks in which I don't think there are even intra-doc links. So probably mostly spurious. |
Since Joshua is on vacation, r? @Manishearth |
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.
lgtm! r=me with the merge conflicts addressed
This is a step in the direction of computing the links more lazily, which I think will simplify the implementation of intra-doc links. This will also make it easier to eventually use the actual `Res` for associated items, enum variants, and fields, rather than their HTML page's `Res`.
a074157
to
ae2bc69
Compare
Thanks for the review! @bors r=Manishearth rollup=never |
📌 Commit ae2bc69 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (cc65bf3): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
…anishearth rustdoc: Remove the intra-doc links side channel The side channel made the code much more complex and harder to understand. It was added as a temporary workaround in 0c99d80, but it's no longer necessary. The addition of `UrlFragment` in rust-lang#92088 was the key to getting rid of the side channel. The semantic information (rather than the strings that used to be used for fragments) that is now captured by `UrlFragment` is enough to obviate the side channel. An additional change had to be made to `UrlFragment` in this PR to make this possible: it now records `DefId`s rather than item names. This PR also consolidates the checks for anchor conflicts into one place. r? `@Manishearth`
…ishearth rustdoc: Remove the intra-doc links side channel The side channel made the code much more complex and harder to understand. It was added as a temporary workaround in 0c99d80, but it's no longer necessary. The addition of `UrlFragment` in rust-lang#92088 was the key to getting rid of the side channel. The semantic information (rather than the strings that used to be used for fragments) that is now captured by `UrlFragment` is enough to obviate the side channel. An additional change had to be made to `UrlFragment` in this PR to make this possible: it now records `DefId`s rather than item names. This PR also consolidates the checks for anchor conflicts into one place. r? `@Manishearth`
This is a step in the direction of computing the links more lazily,
which I think will simplify the implementation of intra-doc links.
This will also make it easier to eventually use the actual
Res
forassociated items, enum variants, and fields, rather than their HTML
page's
Res
.r? @jyn514