"Aborted (core dumped)" on typo in attribute #70763
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
P-low
Low priority
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
According to |
jonas-schievink
added
A-attributes
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
rustc crashes ungracefully when given the following input (found by fuzz-rustc):
The text was updated successfully, but these errors were encountered: