-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
[1.38] Regression: proc macro panicked #63894
Copy link
Copy link
Closed
Labels
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Metadata
Metadata
Assignees
Labels
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Type
Fields
Give feedbackNo fields configured for issues without a type.
#63628 (comment)
This is a regression from these series of pretty-printing improvements - #62393, #62574, #62667.
Tokens are printed more precisely now, so
#[custom_slice(error(r#type = "()"))]is now printed as is, while previously it lost the "rawness" qualifier fromtypeand was printed like this -#[custom_slice(error(type = "()"))].(Pretty-printing matters because proc macros often have to work with pretty-printed version of their input due to #43081.)
Procedural macro
define_slice_types_pairhowever doesn't recognizer#typeastypeand complains.