Skip to content

Rewrite inline attribute parser to use new infrastructure and improve diagnostics for all parsed attributes #138165

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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

jdonszelmann
Copy link
Contributor

@jdonszelmann jdonszelmann commented Mar 7, 2025

r? @oli-obk

This PR:

Builds on top of #138164

Closes #137950

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 7, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@@ -584,7 +546,6 @@ fn codegen_fn_attrs(tcx: TyCtxt<'_>, did: LocalDefId) -> CodegenFnAttrs {
return OptimizeAttr::Default;
};

inline_span = Some(attr.span());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes #137950

@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from e6dad01 to 2a707bf Compare March 9, 2025 15:34
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Mar 11, 2025

☔ The latest upstream changes (presumably #138302) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk oli-obk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 28, 2025
@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from b7dda57 to 88a713a Compare June 9, 2025 22:40
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

@rustbot review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 9, 2025
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

ah shit, broke clippy 😭

@bors
Copy link
Collaborator

bors commented Jun 13, 2025

☔ The latest upstream changes (presumably #142432) made this pull request unmergeable. Please resolve the merge conflicts.

//@ is "$.index[?(@.name=='just_inline')].attrs" '["#[inline]"]'
//@ is "$.index[?(@.name=='just_inline')].attrs" '["#[attr = Inline(Hint)]"]'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So to understand https://github.com/rust-lang/rust/pull/138165/files?diff=unified&w=1#r2143839007 right, we could represent this attrs list in json not as a list of strings, but as a list of either strings (unstable format, only print or view it) or json maps that contain all the information in a structured way and doesn't require consumers to re-parse it.

If we change the map representation, we bump the format. If we change the string representation, we do not.

Either way, we either break csc or we bump the version so csc can gate its parser on it. The only question we're asking right now is whether we bump the version twice (once now, and once for when we move to json maps).

is that about right @aDotInTheVoid @obi1kenobi ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a c-s-c perspective I don't have a strong opinion, we don't check #[inline] and the change shouldn't break us.

From a rustdoc JSON format perspective, I think it's kinder to other rustdoc JSON users if we bump.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oli-obk if we bump, we should also decide if we bump from now on on every reworked attribute parser.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@obi1kenobi and I talked synchronously for a bit, and for now we both think it's best to do version bumps for a bit until we can implement a more structured approach. Pushed a commit that does the bump.

@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the inline branch 2 times, most recently from 220615f to 43dd618 Compare June 16, 2025 17:16
@rustbot
Copy link
Collaborator

rustbot commented Jun 16, 2025

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

@jdonszelmann
Copy link
Contributor Author

I think that addresses all the review comments by others @oli-obk :)

@bors
Copy link
Collaborator

bors commented Jun 16, 2025

☔ The latest upstream changes (presumably #142589) made this pull request unmergeable. Please resolve the merge conflicts.

@@ -30,7 +30,7 @@ pub type FxHashMap<K, V> = HashMap<K, V>; // re-export for use in src/librustdoc
/// This integer is incremented with every breaking change to the API,
/// and is returned along with the JSON blob as [`Crate::format_version`].
/// Consuming code should assert that this value matches the format version(s) that it supports.
pub const FORMAT_VERSION: u32 = 46;
pub const FORMAT_VERSION: u32 = 47;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this PR isn't bitrotty or urgent, it'd be really nice if could land after #142601 (and a rebase), so it's guaranteed not to race with #142502 to do the same bump. (#142601 fixes this by making this a conflict, so we'll never need to manually worry about this again 🤞)

Copy link
Contributor Author

@jdonszelmann jdonszelmann Jun 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one seems to have few conflicts, will preemptively bump to 48

@rust-log-analyzer

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Diagnostics error in interaction between #[optimize(..)] and #[no_sanitize(..)]
9 participants