Skip to content

Non-boxed recursive tag constructor fails to compile with "Out of stack space" #1048

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.

Sign up for GitHub

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

Jump to bottom
Closed
mbrubeck opened this issue Oct 18, 2011 · 1 comment
Closed

Non-boxed recursive tag constructor fails to compile with "Out of stack space" #1048

mbrubeck opened this issue Oct 18, 2011 · 1 comment

Comments

@mbrubeck
Copy link
Contributor

If you try to compile tag list<T> { nil; cons(int, list<T>); } (note "list" instead of "@list" in the recursive constructor), then the compiler crashes with rt: e2b5:0x00000000: Out of stack space, sorry.

It would be nice to detect this condition and provide a more useful error message instead.

The bottom of the stack is:

#24545 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24546 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24547 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24548 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24549 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24550 0x080ff28e in middle::ty::type_structurally_contains::_5f3ac45ea1b71c45 ()
#24551 0x08061feb in middle::trans::type_of_tag::_a125eb2fba6a34ee ()
#24552 0x08061522 in middle::trans::type_of_inner::_f9908926438f2236 ()
#24553 0x080603bb in middle::trans::type_of_fn::_d1c7c2dc9390d6d7 ()
#24554 0x08060a5e in middle::trans::type_of_fn_from_ty::_e121377dba6b8bd0 ()
#24555 0x080bc50c in middle::trans::register_fn_full::_3897f5c49d271367 ()
#24556 0x080bc358 in middle::trans::register_fn::_2c73ab4a26be7a7a ()
#24557 0x080c2fd1 in middle::trans::collect_tag_ctor::_5ff72ae6ae3153d1 ()
#24558 0x082a833e in middle::trans::collect_tag_ctors::thunk1669 ()
#24559 0x082c9589 in syntax::visit::default_visitor::thunk5653 ()
#24560 0x080c354b in middle::trans::collect_tag_ctors::_ec22d712145eb498 ()
#24561 0x080c9503 in middle::trans::trans_crate::_19245ca61421d176 ()
#24562 0x082e809b in driver::rustc::compile_input::thunk8685 ()
#24563 0x0827812d in driver::rustc::time::_8bcb4789e2c2f57e ()
#24564 0x0827acff in driver::rustc::compile_input::_c6e994438f359ee8 ()
#24565 0x08286208 in driver::rustc::main::_ed54e060591e3a31 ()
#24566 0x08286e93 in _rust_main ()
#24567 0x082eb12c in _rust_main_wrap ()
#24568 0x01337321 in task_start_wrapper (a=0xb7fe0010) at ../src/rt/rust_task.cpp:150
#24569 0xdeadbeef in ?? ()
#24570 0xb7fe0010 in ?? ()
#24571 0x00000010 in ?? ()
@mbrubeck
Copy link
Contributor Author

Duplicate of issue #742.

@mbrubeck mbrubeck mentioned this issue Nov 5, 2011
Closed
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 21, 2015
@alexcrichton
rollup merge of rust-lang#24222: lambda/rename-soft-link-to-symlink
2fc2e12 
Implement [RFC rust-lang#1048][rfc].

On Windows, when you create a symbolic link you must specify whether it
points to a directory or a file, even if it is created dangling, while
on Unix, the same symbolic link could point to a directory, a file, or
nothing at all.  Furthermore, on Windows special privilege is necessary
to use a symbolic link, while on Unix, you can generally create a
symbolic link in any directory you have write privileges to.

This means that it is unlikely to be able to use symbolic links purely
portably; anyone who uses them will need to think about the cross
platform implications.  This means that using platform-specific APIs
will make it easier to see where code will need to differ between the
platforms, rather than trying to provide some kind of compatibility
wrapper.

Furthermore, `soft_link` has no precedence in any other API, so to avoid
confusion, move back to the more standard `symlink` terminology.

Create a `std::os::unix::symlink` for the Unix version that is
destination type agnostic, as well as `std::os::windows::{symlink_file,
symlink_dir}` for Windows.

Because this is a stable API, leave a compatibility wrapper in
`std::fs::soft_link`, which calls `symlink` on Unix and `symlink_file`
on Windows, preserving the existing behavior of `soft_link`.

[rfc]: rust-lang/rfcs#1048
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@adpaco-aws @tedinski
Add a test for ctpop (rust-lang#1048)
0e817e6 
* Add a test for `ctpop`

* Fix format
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mbrubeck