Fix stack overflow when macro_rules! macros shadow builtin attributes or types #142946
+52
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
rustbot
added
S-waiting-on-review
clauses3
changed the title
|
Compiler also crashes with SIGBUS when shadowing type with RUST_MIN_STACK=1048576: #[macro_export]
macro_rules! String {
() => {
fn get_string() -> String {
"hello".to_owned()
}
};
}
#[cfg(test)]
mod tests {
use super::*;
String!();
#[test]
fn test_string_shadow() {
assert_eq!(get_string(), "hello");
}
}Name collision between proc macros and macro rules (SIGBUS): // Trigger name resolution bug before
// compiler validates crate structure
extern crate proc_macro;
use proc_macro::TokenStream;
#[proc_macro_attribute]
pub fn test(_attr: TokenStream, item: TokenStream) -> TokenStream {
}
#[test]
fn my_test_function() {
assert_eq!(2 + 2, 4);
}
// Never gets here
fn main() {
println!("Hi!");
}More cases (SIGBUS): [package]
name = "test_proc_macro"
version = "0.1.0"
edition = "2024"
[lib]
proc-macro = true
[dependencies]
extern crate proc_macro;
use proc_macro::TokenStream;
/// A procedural attribute macro whose only purpose is to create a name collision.
#[proc_macro_attribute]
pub fn ambiguous_macro(_attr: TokenStream, item: TokenStream) -> TokenStream {
item
}
[package]
name = "my_app"
version = "0.1.0"
edition = "2024"
[dependencies]
test_proc_macro = { path = "../test_proc_macro" }
use test_proc_macro::ambiguous_macro;
#[macro_export]
macro_rules! ambiguous_macro {
() => {
fn created_by_macro_rules() {}
};
}
fn main() {
ambiguous_macro!();
created_by_macro_rules();
}RUST_MIN_STACK=1048576 cargo build --manifest-path my_app/Cargo.tomlJust shadowing keywords in general (SIGBUS after syntax errors): #[macro_export]
macro_rules! fn {
() => {
// This macro's name shadows the `fn` keyword.
// The goal is to see if this confuses the parser, which operates
// before the name resolution stage where previous bugs were found.
println!("The `fn` macro was called.");
};
}
// Now, we attempt to define a regular function using the `fn` keyword.
// If the parser incorrectly identifies `fn` as the macro, it could lead
// to a crash or a deeply confusing error message, as the fundamental
// structure of the language is being challenged.
fn my_test_function() {
println!("This is a standard function.");
}
fn main() {
// We can invoke the macro to make sure it's active.
fn!();
// And call the regular function.
my_test_function();
} |
|
This seems misguided. There are numerous way to trigger this recursion limit, and most of them do not involve any shadowing and are not affected by changes to ident.rs made in this PR. (The change doesn't affect the reproducer with Also, this is not the only recursion limit error in rustc, there are similar errors in type checking, in const evaluation, probably somewhere else. |
petrochenkov
added
S-waiting-on-author
|
Thanks for the quick reply. Here's the output of the original issue, encountered while testing a gpui project: |
|
There are a few dozens of targeted uses of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Compiler crashes with SIGSEGV when
macro_rules!shadows a builtin attribute like#[test]and uses that attribute within its expansion.Repro
RUST_MIN_STACK=1048576 rustc --test crash_test.rs # Segmentation fault (core dumped)Can crash in regular situations without limiting stack as well, like gpui tests in Zed.
Fix adds a check in
early_resolve_ident_in_lexical_scopeto prevent infinite recursion by always preferring the builtin attribute when there's an ambiguity between amacro_rules!macro and a builtin attribute. This only applies tomacro_rules!macros to preserve existing proc-macro ambiguity detection.Questions
Should there be a warning when a
macro_rules!macro shadows a builtin attribute? What's the precedence order?With a very small stack, a crash can still happen before execution gets here. Move fix?
r? @WaffleLapkin bug originally found in gpui 😸