6 ms·

I'd love something similar to be part of Cargo, maybe as an option in the manifest. Like the author, I've learned to guess when the codegen starts, but having t

I'd love something similar to be part of Cargo, maybe as an option in the manifest. Like the author, I've learned to guess when the codegen starts, but having this information displayed would be useful.

kibwen 11y ago
I'm actually working right now on a `cargo check` command which only runs those phases of the compiler to do with typechecking, to accommodate workflows based around tweaking types and then running the compiler to check your work. Given that the vast majority of compilation time is currently based in code generation and linking, this should drastically improve usability for this sort of rapid-iteration, dynamic-language-style workflow. (Though also note that improving the speed of codegen and linking is an ongoing task as well.)
- mafribe 11y ago
  This is a great idea. I wish other compilers would offer this feature (scalac is in dire need of such an option). Does the Rust macro system require compile-time compilation before type-checking?
  - Jweb_Guru 11y ago
    Not really. Macro expansion occurs during its own phase of compilation (which, in my experience, is generally really fast).
    - mafribe 11y ago
      Macro expansion can lead to programs that don't typecheck, unless a very restrictive typing system is used (e.g. MetaML, MetaOcaml). I don't think Rust has such restrictions, therefore I assume that type-checking happens after macro expansion.
      - Jweb_Guru 11y ago
        It does, but what I was getting at was that full compilation doesn't need to occur first. Macro expansion is one of the very first phases of compilation (and doesn't have access to typechecking information, incidentally).
        mafribe 11y ago
        So Rust macros don't offer full compile-time meta-programming?
        Jweb_Guru 11y ago
        Not in Rust 1.0. In the nightlies there are syntax extensions available that give you more power, but those are likely to see significant revisions before they're available in a stable version since they're a major backwards compatibility hazard.
        mafribe 11y ago
        Who's working on this? I may have something to contribute in this direction.
        Jweb_Guru 11y ago
        I'm not sure who specifically is working on improving the macro system, but it's definitely something that's been prioritized. My primary recommendation for contacting the relevant people would be either the Rust internals forums (https://internals.rust-lang.org https://internals.rust-lang.org) or the #rust-internals channel on irc.mozilla.org.
        Manishearth 11y ago
        Not something being actively worked on, but I and some others care about it. Rust macro-esque things are of three types: - Macro by Example (MBE): These are easily defined by the user via `macro_rules!`, which can match on their input and expand to some output at compile time. These don't need to be defined as a plugin; you can define a macro directly in your code. - tokentree expansion plugins: These take in a token tree, run arbitrary code, and output an AST (syntax tree) node. Ish. - AST expansion plugin: These take in the parsed AST, run arbitrary code, and output another AST to replace or augment it. There also is support for custom lints and llvm passes. All of this is at compile time.

kibwen 11y ago

I'm actually working right now on a `cargo check` command which only runs those phases of the compiler to do with typechecking, to accommodate workflows based around tweaking types and then running the compiler to check your work. Given that the vast majority of compilation time is currently based in code generation and linking, this should drastically improve usability for this sort of rapid-iteration, dynamic-language-style workflow. (Though also note that improving the speed of codegen and linking is an ongoing task as well.)

mafribe 11y ago
This is a great idea. I wish other compilers would offer this feature (scalac is in dire need of such an option). Does the Rust macro system require compile-time compilation before type-checking?
- Jweb_Guru 11y ago
  Not really. Macro expansion occurs during its own phase of compilation (which, in my experience, is generally really fast).
  - mafribe 11y ago
    Macro expansion can lead to programs that don't typecheck, unless a very restrictive typing system is used (e.g. MetaML, MetaOcaml). I don't think Rust has such restrictions, therefore I assume that type-checking happens after macro expansion.
    - Jweb_Guru 11y ago
      It does, but what I was getting at was that full compilation doesn't need to occur first. Macro expansion is one of the very first phases of compilation (and doesn't have access to typechecking information, incidentally).
      - mafribe 11y ago
        So Rust macros don't offer full compile-time meta-programming?
        Jweb_Guru 11y ago
        Not in Rust 1.0. In the nightlies there are syntax extensions available that give you more power, but those are likely to see significant revisions before they're available in a stable version since they're a major backwards compatibility hazard.
        mafribe 11y ago
        Who's working on this? I may have something to contribute in this direction.
        Jweb_Guru 11y ago
        I'm not sure who specifically is working on improving the macro system, but it's definitely something that's been prioritized. My primary recommendation for contacting the relevant people would be either the Rust internals forums (https://internals.rust-lang.org https://internals.rust-lang.org) or the #rust-internals channel on irc.mozilla.org.
        Manishearth 11y ago
        Not something being actively worked on, but I and some others care about it. Rust macro-esque things are of three types: - Macro by Example (MBE): These are easily defined by the user via `macro_rules!`, which can match on their input and expand to some output at compile time. These don't need to be defined as a plugin; you can define a macro directly in your code. - tokentree expansion plugins: These take in a token tree, run arbitrary code, and output an AST (syntax tree) node. Ish. - AST expansion plugin: These take in the parsed AST, run arbitrary code, and output another AST to replace or augment it. There also is support for custom lints and llvm passes. All of this is at compile time.