The garbage collector and autogenerated types are causing a runtime panic #5698
Assignees
Labels
bug
Something isn't working
compiler: frontend
Everything to do with type checking, control flow analysis, and everything between parsing and IRgen
language server
LSP server
team:compiler
Compiler Team
Comments
|
concurrent_slab.rs: pub fn get(&self, index: usize) -> Arc<T> {
let inner = self.inner.read().unwrap();
let value = inner.get(&index).unwrap_or_else(|| {
let backtrace = std::backtrace::Backtrace::force_capture();
eprintln!("backtrace: {:#?}", backtrace);
panic!("Failed to get value from index: {}", index);
});
value.clone()
} |
|
I've been digging into this, it actually isn't caused by auto complete, it just so happens that auto complete LSP request is triggered when a key is pressed. It appears this only started happening after #5306 was introduced. There is a conflict with how the garbage collection is operating and how types are constructed in the below functions. pub fn auto_impl_abi_encode(&mut self, decl: &ty::TyDecl) -> Option<TyAstNode> {
match decl {
TyDecl::StructDecl(_) => self.struct_auto_impl_abi_encode(decl),
TyDecl::EnumDecl(_) => self.enum_auto_impl_abi_encode(decl),
_ => None,
}
} We should have had a CI test to catch this when the garbage collector PR was implemented in #5251. However, at that time, we were only performing GC every 10th keystroke and it was overloading the stack in CI. Now that we have reduced this to every 3rd keystroke it seems to be fine for CI. I've just put up a PR #5704 that can recreate this crash. Hopefully it will help debug how to resolve the underlying issue, and also prevent this sort of bug to creep through in the future. Here is a stack trace of the error that is happening for reference. It's getting triggered by the .get call below at line 738 in let traitItems = map_trait_items
.clone()
.into_iter()
.map(|(name, item)| match &item {
ty::TyTraitItem::Fn(decl_ref) => {
let mut decl = (*decl_engine.get(decl_ref.id())).clone();also, if i add the following It seems that some of these dummy spans are slipping in which the GC see's and clears from the engines. I would have expected these to be recreated again on the next compilation but they don't seem to be? Here are some more observations. So it seems that possibly a So If i then don’t remove ``TyFunctionDecl If I disable clearing the type engine and only clear the decl engine with the below then this seems to work. decl_engine_clear_module!(
// function_slab, ty::TyFunctionDecl;
trait_slab, ty::TyTraitDecl;
trait_fn_slab, ty::TyTraitFn;
trait_type_slab, ty::TyTraitType;
// impl_trait_slab, ty::TyImplTrait;
// struct_slab, ty::TyStructDecl;
storage_slab, ty::TyStorageDecl;
// abi_slab, ty::TyAbiDecl;
constant_slab, ty::TyConstantDecl;
enum_slab, ty::TyEnumDecl;
type_alias_slab, ty::TyTypeAliasDecl;
);So the above seems to be 1 issue. If I comment out clearing the decl engine and just do the type engine then we encounter a whole seperate problem. |
JoshuaBatty
changed the title
JoshuaBatty
added
the
compiler: frontend
7 tasks
|
The issue is that auto generated code, or anything using |
|
I did suspect that and replaced all of the Span::dummy() 's with a dummy span containing a |
7 tasks
tritao
added a commit
that referenced
this issue
Mar 11, 2024
## Description This PR makes sure we assign specific module ids to the generated auto impl decls. Helps with #5698. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>
|
Should be addressed in #5813 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Autocomplete in LSP is not working in many cases. It seems to be using an older version of the token map, as I see this error in the LSP logs when it doesn’t work:
The text was updated successfully, but these errors were encountered: