4 ms·

How's the MIR stuff going on? Is there an ETA on when MIR will land in beta/stable? Will the incremental compilation work start after that?

by rustc 10y ago

steveklabnik 10y ago
MIR is still going well. To be clear, it's already landed, and has been working, it's just not the default yet. There's a PR https://github.com/rust-lang/rust/pull/34096 https://github.com/rust-lang/rust/pull/34096 and there are currently three blockers: https://github.com/rust-lang/rust/milestone/29 https://github.com/rust-lang/rust/milestone/29 Incremental compilation has been worked on while MIR development was happening, so it won't start, it's already in-progress. :)
- moosingin3space 10y ago
  Does this imply we should see single-crate compile times improve?
  - steveklabnik 10y ago
    Which part? With MIR, yes, the idea is that compile time should improve. One of those tracking bugs is to make sure that it doesn't regress before turning it on by default. With incremental compilation, you should see compiles after the first improve; you'll need to compile a lot less code for each change. Right now, the entire crate is recompiled, but afterwards, just the portion that changed will need to be.
    - moosingin3space 10y ago
      My understanding of compilers is somewhat limited, but I'm curious how the compiler can detect "just the portion that changed", given that Rust does heavy inlining.
      - dikaiosune 10y ago
        There's some information about the design in the RFC text: https://github.com/rust-lang/rfcs/blob/master/text/1298-incremental-compilation.md#high-level-design https://github.com/rust-lang/rfcs/blob/master/text/1298-incr... AFAICT, the idea is to track and hash items like function signatures and bodies, map them to the object files produced by LLVM, and to recompile them when the hashes change.
      - kibwen 10y ago
        Indeed, inlining is an obstacle for such fine-grained incremental recompilation as Rust envisions. However, when compiling in debug mode (which is the default) Rust (or rather LLVM) does not do all that much inlining, and considering that people compile in debug mode much more often than they compile in release mode this should present a large time savings to the average developer use case. (Note also that MIR should generate somewhat faster debug binaries than current trans (by virtue of doing "obvious" optimizations in the frontend, rather than asking LLVM to chew on it), so if there are people out there who currently make release builds during development because their debug builds are too doggone slow, then this should help alleviate that.)
rubber_duck 10y ago
Also is there an ETA on syntax extensions being stabilized ? This and incremental compilation are my personal milestones that Rust (core language/compiler) went over the initial growing pains (lack of tooling I can deal with)
- steveklabnik 10y ago
  There is no ETA yet, but it is being worked on. Out of curiosity, do you want general syntax extensions, or is it stuff like Serde/Diesel, specifically?
  - rubber_duck 10y ago
    For a project I have in mind I'm looking for a way to reflect on the code and generate both serialization and RPC API from code based on conventions/traits/annotations - I guess I could do it with syntex but that looks hacky and slow (two passes). In general I'm not in a rush to start that project and these two things seem like the last big missing peaces of the compiler/language - I'm waiting on those before I start pitching rust to my coworkers.
    - steveklabnik 10y ago
      Cool, thanks. We have some ideas for a solution to these kinds of cases that might come a lot sooner than general syntax extensions, but it's still shaking out.
      - Rusky 10y ago
        Any discuss threads or RFCs I could look at? I'm also interested in those use cases.
        dikaiosune 10y ago
        There are two that I know of off the top of my head: Code generators/source maps: https://github.com/rust-lang/rfcs/pull/1573 https://github.com/rust-lang/rfcs/pull/1573 Procedural macros: https://github.com/rust-lang/rfcs/pull/1566 https://github.com/rust-lang/rfcs/pull/1566

How's the MIR stuff going on? Is there an ETA on when MIR will land in beta/stable? Will the incremental compilation work start after that?

by rustc 10y ago

How's the MIR stuff going on? Is there an ETA on when MIR will land in beta/stable? Will the incremental compilation work start after that?

steveklabnik 10y ago

MIR is still going well. To be clear, it's already landed, and has been working, it's just not the default yet. There's a PR https://github.com/rust-lang/rust/pull/34096 https://github.com/rust-lang/rust/pull/34096 and there are currently three blockers: https://github.com/rust-lang/rust/milestone/29 https://github.com/rust-lang/rust/milestone/29 Incremental compilation has been worked on while MIR development was happening, so it won't start, it's already in-progress. :)

moosingin3space 10y ago
Does this imply we should see single-crate compile times improve?
- steveklabnik 10y ago
  Which part? With MIR, yes, the idea is that compile time should improve. One of those tracking bugs is to make sure that it doesn't regress before turning it on by default. With incremental compilation, you should see compiles after the first improve; you'll need to compile a lot less code for each change. Right now, the entire crate is recompiled, but afterwards, just the portion that changed will need to be.
  - moosingin3space 10y ago
    My understanding of compilers is somewhat limited, but I'm curious how the compiler can detect "just the portion that changed", given that Rust does heavy inlining.
    - dikaiosune 10y ago
      There's some information about the design in the RFC text: https://github.com/rust-lang/rfcs/blob/master/text/1298-incremental-compilation.md#high-level-design https://github.com/rust-lang/rfcs/blob/master/text/1298-incr... AFAICT, the idea is to track and hash items like function signatures and bodies, map them to the object files produced by LLVM, and to recompile them when the hashes change.
    - kibwen 10y ago
      Indeed, inlining is an obstacle for such fine-grained incremental recompilation as Rust envisions. However, when compiling in debug mode (which is the default) Rust (or rather LLVM) does not do all that much inlining, and considering that people compile in debug mode much more often than they compile in release mode this should present a large time savings to the average developer use case. (Note also that MIR should generate somewhat faster debug binaries than current trans (by virtue of doing "obvious" optimizations in the frontend, rather than asking LLVM to chew on it), so if there are people out there who currently make release builds during development because their debug builds are too doggone slow, then this should help alleviate that.)

rubber_duck 10y ago

Also is there an ETA on syntax extensions being stabilized ? This and incremental compilation are my personal milestones that Rust (core language/compiler) went over the initial growing pains (lack of tooling I can deal with)

steveklabnik 10y ago
There is no ETA yet, but it is being worked on. Out of curiosity, do you want general syntax extensions, or is it stuff like Serde/Diesel, specifically?
- rubber_duck 10y ago
  For a project I have in mind I'm looking for a way to reflect on the code and generate both serialization and RPC API from code based on conventions/traits/annotations - I guess I could do it with syntex but that looks hacky and slow (two passes). In general I'm not in a rush to start that project and these two things seem like the last big missing peaces of the compiler/language - I'm waiting on those before I start pitching rust to my coworkers.
  - steveklabnik 10y ago
    Cool, thanks. We have some ideas for a solution to these kinds of cases that might come a lot sooner than general syntax extensions, but it's still shaking out.
    - Rusky 10y ago
      Any discuss threads or RFCs I could look at? I'm also interested in those use cases.
      - dikaiosune 10y ago
        There are two that I know of off the top of my head: Code generators/source maps: https://github.com/rust-lang/rfcs/pull/1573 https://github.com/rust-lang/rfcs/pull/1573 Procedural macros: https://github.com/rust-lang/rfcs/pull/1566 https://github.com/rust-lang/rfcs/pull/1566