Skip to content
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

-Z show-span crashes rustc #17115

Closed
kaseyc opened this issue Sep 9, 2014 · 0 comments · Fixed by #17142
Closed

-Z show-span crashes rustc #17115

kaseyc opened this issue Sep 9, 2014 · 0 comments · Fixed by #17142
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@kaseyc
Copy link
Contributor

kaseyc commented Sep 9, 2014

Platform: Linux Mint 16, 64-bit
Rustc version: rustc 0.12.0-pre-nightly (09cebc2 2014-09-07 00:31:28 +0000)

Sample Program:

fn main() {
    println!("Hello Rust");
}

When compiled with -Z show-span, the compiler will fail with `task 'rustc' failed at:

visit_mac disabled by default', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/ast_util.rs:776

Backtrace:

   1:     0x7effc43bfee0 - rt::backtrace::imp::write::h0322cc36a3f58594H8q
   2:     0x7effc43c3080 - failure::on_fail::h4244bff77454f4f4pur
   3:     0x7effc4bb8850 - unwind::begin_unwind_inner::h9f77a03cfeff340062d
   4:     0x7effc4f99370 - unwind::begin_unwind::h13888748684028530931
   5:     0x7effc511a510 - visit::Visitor::visit_mac::h5175099642578985137
   6:     0x7effc57f00f0 - visit::walk_block::h15593329261720824210
   7:     0x7effc57f0e50 - visit::walk_fn::h9877552939557075411
   8:     0x7effc57f0770 - visit::walk_item::h5589296153533657905
   9:     0x7effc57f17a0 - front::show_span::run::h345bf25a20bee057xPq
  10:     0x7effc5686d00 - driver::driver::phase_1_parse_input::hb08a34f5b31b9e02qxD
  11:     0x7effc58531d0 - driver::driver::compile_input::hfbabd4a6c7c0be4aIsD
  12:     0x7effc58e4a70 - driver::run_compiler::h5e700b3d5abdd789ZjH
  13:     0x7effc58e4960 - driver::main_args::closure.147495
  14:     0x7effc4fd1310 - task::TaskBuilder<S>::try_future::closure.100103
  15:     0x7effc4fd1110 - task::TaskBuilder<S>::spawn_internal::closure.100074
  16:     0x7effc638e5f0 - task::spawn_opts::closure.8408
  17:     0x7effc4c0e360 - rust_try_inner
  18:     0x7effc4c0e350 - rust_try
  19:     0x7effc4bb5f20 - unwind::try::hd71c364f2ee27fc1gRd
  20:     0x7effc4bb5d80 - task::Task::run::h7964802050e4385692c
  21:     0x7effc638e360 - task::spawn_opts::closure.8348
  22:     0x7effc4bb7900 - thread::thread_start::hdb150e157ee517fagod
  23:     0x7effc3e7cea0 - start_thread
  24:     0x7effc487e999 - __clone
  25:                0x0 - <unknown>
@huonw huonw added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Sep 9, 2014
sfackler added a commit to sfackler/rust that referenced this issue Sep 10, 2014
lnicola pushed a commit to lnicola/rust that referenced this issue Apr 24, 2024
…, r=Veykril

Try to generate more meaningful names in json converter

I just found out about rust-analyzer json converter, but I think it would be more convenient, if names were more useful, like using the names of the keys.

Let's look at some realistic arbitrary json:

```json
{
    "user": {
        "address": {
            "street": "Main St",
            "house": 3
        },
        "email": "example@example.com"
    }
}
```
I think, new generated code is much easier to read and to edit, than the old:
```rust
// Old
struct Struct1{ house: i64, street: String }
struct Struct2{ address: Struct1, email: String }
struct Struct3{ user: Struct2 }

// New
struct Address1{ house: i64, street: String }
struct User1{ address: Address1, email: String }
struct Root1{ user: User1 }
```

Ideally, if we drop the numbers, I can see it being usable just as is (may be rename root)
```rust
struct Address{ house: i64, street: String }
struct User{ address: Address, email: String }
struct Root{ user: User }
```

Sadly, we can't just drop them, because there can be multiple fields (recursive) with the same name, and we can't just easily retroactively add numbers if the name has 2 instances due to parsing being single pass.
We could ignore the `1` and add number only if it's > 1, but I will leave this open to discussion and right now made it the simpler way

In sum, even with numbers, I think this PR still helps in readability
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants