-
Notifications
You must be signed in to change notification settings - Fork 13.3k
"Aborted (core dumped)" on typo in attribute #70763
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
According to |
Here's a somewhat cuter test case that hits the same failure: fn main() {
let _ = || {
#[cfg(any(target_arch == "arm"))]
let _ = ();
};
}
|
cc @Centril, I think you might have been around that code recently. |
Simplified: const _: _ = [#[cfg(ident(ident ==))] 0]; |
Backtrace:
|
Something in the closure here is causing a panic: impl<'a, 'b> MutVisitor for InvocationCollector<'a, 'b> {
fn visit_expr(&mut self, expr: &mut P<ast::Expr>) {
self.cfg.configure_expr(expr);
visit_clobber(expr.deref_mut(), |mut expr| {
self.cfg.configure_expr_kind(&mut expr.kind);
// ignore derives so they remain unused
let (attr, after_derive) = self.classify_nonitem(&mut expr);
if attr.is_some() {
// Collect the invoc regardless of whether or not attributes are permitted here
// expansion will eat the attribute so it won't error later.
attr.as_ref().map(|a| self.cfg.maybe_emit_expr_attr_err(a));
// AstFragmentKind::Expr requires the macro to emit an expression.
return self
.collect_attr(
attr,
vec![],
Annotatable::Expr(P(expr)),
AstFragmentKind::Expr,
after_derive,
)
.make_expr()
.into_inner();
}
if let ast::ExprKind::MacCall(mac) = expr.kind {
self.check_attributes(&expr.attrs);
self.collect_bang(mac, expr.span, AstFragmentKind::Expr).make_expr().into_inner()
} else {
noop_visit_expr(&mut expr, self);
expr
}
});
} With the definition: /// Use a map-style function (`FnOnce(T) -> T`) to overwrite a `&mut T`. Useful
/// when using a `flat_map_*` or `filter_map_*` method within a `visit_`
/// method. Abort the program if the closure panics.
//
// No `noop_` prefix because there isn't a corresponding method in `MutVisitor`.
pub fn visit_clobber<T, F>(t: &mut T, f: F)
where
F: FnOnce(T) -> T,
{
unsafe {
// Safe because `t` is used in a read-only fashion by `read()` before
// being overwritten by `write()`.
let old_t = ptr::read(t);
let new_t =
panic::catch_unwind(panic::AssertUnwindSafe(|| f(old_t))).unwrap_or_else(|_| {
println!("{}", std::backtrace::Backtrace::force_capture());
process::abort()
});
ptr::write(t, new_t);
}
} The problem seems to occur in the call to Digging further, unsurprisingly, the panic happens in the fn filter_map_expr(&mut self, expr: P<ast::Expr>) -> Option<P<ast::Expr>> {
let expr = configure!(self, expr);
expr.filter_map(|mut expr| { |
Further down the rabbit hole, we have: pub fn in_cfg(&self, attrs: &[Attribute]) -> bool { which calls let nmis = parse_in(sess, t.clone(), "meta list", |p| p.parse_meta_seq_top())?; which calls: fn parse_meta_item_inner(&mut self) -> PResult<'a, ast::NestedMetaItem> { which has: match self.parse_meta_item() { so we will end up in: crate fn parse_meta_item_kind(&mut self) -> PResult<'a, ast::MetaItemKind> {
Ok(if false && self.eat(&token::Eq) {
ast::MetaItemKind::NameValue(self.parse_unsuffixed_lit()?)
} else if self.check(&token::OpenDelim(token::Paren)) {
// Matches `meta_seq = ( COMMASEP(meta_item_inner) )`.
let (list, _) = self.parse_paren_comma_seq(|p| p.parse_meta_item_inner())?;
ast::MetaItemKind::List(list)
} else {
ast::MetaItemKind::Word
})
} and reach the However, this was nested, so we are in the } else if self.last_unexpected_token_span == Some(self.token.span) {
FatalError.raise();
} and there we have our panic. Making that line not trigger removes the abort here. |
Unfortunately, removing the |
Assigning |
Latest stable does not crash any more, errors gracefully. |
It looks to me like the inputs above still cause rustc to abort ungracefully (using the latest Also, I found another example input triggering the same crash, reported in #87790. |
rustc crashes ungracefully when given the following input (found by fuzz-rustc):
The text was updated successfully, but these errors were encountered: