-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
save-analysis fails with proc macro and nested generic type #47981
Comments
rls works well if you use |
Do you have the exact source code which caused this error please? |
PR which changed This part is relevant
Oh.. I think I found a clue.. // This is broken
#[derive(AstNode, Fold, Clone, Debug, PartialEq)]
pub struct Class {
pub span: Span,
pub body: Vec<ClassMethod>,
pub super_class: Option<Box<Expr>>,
}
// This works
#[derive(Clone, Debug, PartialEq)]
pub struct Class {
pub span: Span,
pub body: Vec<ClassMethod>,
pub super_class: Option<Box<Expr>>,
} So the issue is about derive macro, and I'm sure that problematic Reduced to #![feature(specialization)]
#[macro_use]
extern crate ast_node;
extern crate swc_common;
#[derive(Fold)]
pub struct Expr {
pub super_class: Option<Box<Expr>>,
} But when I copy generated code to other file, it works. (and warns about unused macro import)
pub struct Expr {
pub super_class: Option<Box<Expr>>,
}
#[allow(dead_code, non_upper_case_globals)]
const DERIVE_FOLD_FOR_Expr: () =
{
extern crate swc_common;
impl <__Folder> swc_common::FoldWith<__Folder> for Expr {
fn fold_children(self, __folder: &mut __Folder) -> Self {
match self {
Expr { super_class: _super_class } => {
return Expr{super_class:
swc_common::Folder::<Option<Box<Expr>>>::fold(__folder,
_super_class),};
}
}
}
}
}; So I guess it is related to span generated by proc macro.. In this case, Span of
|
I think title should be updated, but I'm not sure if ufcs for generic trait is necessary. |
I've been trying to repro, but it is kind of involved to setup the exact conditions to cause the crash. I currently can't do it outside of the entire project. |
I can repro, and I can see the assertion which is causing the problem and verify that there is a span problem. But there are a lot of places that the error could be introduce - could be in the proc-macro bits of the compiler or in the libs or (quite likely) in Syn. I think rather than trying to track down the error it is better to just make save-analysis more robust. |
Or the parser too, although that seems less likely given that this doesn't repro without the proc macro. |
Closes rust-lang#47981 This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here.
save-analysis: power through bracket mis-counts Closes rust-lang#47981 This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here. r? @eddyb
save-analysis: power through bracket mis-counts Closes rust-lang#47981 This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here. r? @eddyb
save-analysis: power through bracket mis-counts Closes rust-lang#47981 This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here. r? @eddyb
rls shows it as warning, but all codes after the field are not analyzed (including sibling modules). And rls ICEs on dependent crate.
Warning from rls-vscode:
[rustc] librustc_save_analysis\span_utils.rs:156: Mis-counted brackets when breaking path? Parsing 'Box>' in ecmascript\ast\src\class.rs, line 10
Backtrace (from wsl, because my windows rustc doesn't produce any stacktrace)
The text was updated successfully, but these errors were encountered: