5 ms·

What do you mean when stating that applications aren't supported for developing around libcore?

steveklabnik 11y ago
Specifically, there are two 'weak lang items' that need to be defined. Lang items are not yet stable. So while you can build libraries with only core, the final binary still needs to be compiled with nightly. For now. Furthermore, you can use a no_std library with an application that uses std just fine. The use case not quite covered is "I want an application with no standard library at all, period."
- JoshTriplett 11y ago
  > Specifically, there are two 'weak lang items' that need to be defined. Lang items are not yet stable. What two specific items? By "lang item" here, do you mean roughly "symbol", or something else entirely?
  - brson 11y ago
    'lang item' does roughly mean symbol, but they have their own Rust syntax to communicate their existence to the compiler. Lang items are special functions / types that can only be defined once globally, must be defined for certain features to work. They are how the standard library hooks into the Rust language for a variety of purposes, and to a large extent what makes it possible for Rust to define much of its functionality in libraries instead of in the language. The two lang items that are absolutely required but not defined in core are 'eh_personality' and 'panic_fmt'. Read more here: http://doc.rust-lang.org/nightly/book/no-stdlib.html http://doc.rust-lang.org/nightly/book/no-stdlib.html
  - steveklabnik 11y ago
    $ cargo new example --bin $ cd example $ cat > src/main.rs #![no_std] fn main() {} ^D $ multirust run stable cargo run Compiling example v0.1.0 (file:///home/steve/tmp/example) error: language item required, but not found: `panic_fmt` error: language item required, but not found: `eh_personality` error: aborting due to 2 previous errors Could not compile `example`. In general a "lang item" is some portion of Rust that the language expects to be defined in some manner. They must all be defined for compiling to work. `libcore` defines many of these language items, but does not for these last two. `libstd` does. You can provide your own: #[lang = "eh_personality"] extern "C" fn eh_personality() { } #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } These are enough to get going, but actually using `#[lang]` requires a `#![feature]`, which requires nightly. You also end up needing #[start], which is also behind a feature gate. The documentation brson linked you to contains an example no_std executable.
  - deleted 11y ago
    [deleted]
- mindslight 11y ago
  FWIW, the stable release purposely having this functionality removed is pretty annoying. Using periodic versioned releases is much nicer than sporadic snapshots (I've avoided the issue by not mucking with STM32 stuff in a while). A flag like #![use_unstable_features] would be friendlier.
  - steveklabnik 11y ago
    The stable release does not have functionality removed, only deprecated. As in, this functionality was never present in a previous stable release, and now is. That flag you refer to exists, it's #![feature].
    - mindslight 11y ago
      Sure, but the functionality was present back when snapshots were the only game in town. I'd hope progress to versioned releases meant that users could make their life easier by using them rather than having to stay using snapshotted nightlies. I'm glad now libraries are at least supported, which is good enough for my purpose (linking done with gcc, no idea if that's still state of the art for rust-on-stm32 or what), but it had been an annoyance. But I believe procedural macros are still in the same boat. Somewhat tangential, this is the kind of blind spot encouraged by the rustup.sh degeneracy.
      - steveklabnik 11y ago
        When snapshots were the only game, it was all unstable. There's no difference from today. EDIT: sorry, it seems I've mis-read you. I get it now. Unfortunately, we have a strong compatibility story, and so must take strong measures to enforce it. You can use the nightly released on the same night to get a build that's like a particular stable, but allows features.
        mindslight 11y ago
        Sure, that is simply stating a different way. With the resulting implication that if one wants procedural macros, the stable 1.x releases have unfortunately been empty progress. Breakage from forwards-incompatibility isn't my problem, it's potentially having to tackle it every morning rather than in batch mode when there's a new release. edit: If this compatibility story really dictates that releases can't contain beta features, even with a #![unstable_beta_features_1_6] directive, then a separate beta release would be nice. But now it looks like I'm asking for something additional.

Specifically, there are two 'weak lang items' that need to be defined. Lang items are not yet stable. So while you can build libraries with only core, the final binary still needs to be compiled with nightly. For now. Furthermore, you can use a no_std library with an application that uses std just fine. The use case not quite covered is "I want an application with no standard library at all, period."

JoshTriplett 11y ago
> Specifically, there are two 'weak lang items' that need to be defined. Lang items are not yet stable. What two specific items? By "lang item" here, do you mean roughly "symbol", or something else entirely?
- brson 11y ago
  'lang item' does roughly mean symbol, but they have their own Rust syntax to communicate their existence to the compiler. Lang items are special functions / types that can only be defined once globally, must be defined for certain features to work. They are how the standard library hooks into the Rust language for a variety of purposes, and to a large extent what makes it possible for Rust to define much of its functionality in libraries instead of in the language. The two lang items that are absolutely required but not defined in core are 'eh_personality' and 'panic_fmt'. Read more here: http://doc.rust-lang.org/nightly/book/no-stdlib.html http://doc.rust-lang.org/nightly/book/no-stdlib.html
- steveklabnik 11y ago
  $ cargo new example --bin $ cd example $ cat > src/main.rs #![no_std] fn main() {} ^D $ multirust run stable cargo run Compiling example v0.1.0 (file:///home/steve/tmp/example) error: language item required, but not found: `panic_fmt` error: language item required, but not found: `eh_personality` error: aborting due to 2 previous errors Could not compile `example`. In general a "lang item" is some portion of Rust that the language expects to be defined in some manner. They must all be defined for compiling to work. `libcore` defines many of these language items, but does not for these last two. `libstd` does. You can provide your own: #[lang = "eh_personality"] extern "C" fn eh_personality() { } #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } These are enough to get going, but actually using `#[lang]` requires a `#![feature]`, which requires nightly. You also end up needing #[start], which is also behind a feature gate. The documentation brson linked you to contains an example no_std executable.
- deleted 11y ago
  [deleted]
mindslight 11y ago
FWIW, the stable release purposely having this functionality removed is pretty annoying. Using periodic versioned releases is much nicer than sporadic snapshots (I've avoided the issue by not mucking with STM32 stuff in a while). A flag like #![use_unstable_features] would be friendlier.
- steveklabnik 11y ago
  The stable release does not have functionality removed, only deprecated. As in, this functionality was never present in a previous stable release, and now is. That flag you refer to exists, it's #![feature].
  - mindslight 11y ago
    Sure, but the functionality was present back when snapshots were the only game in town. I'd hope progress to versioned releases meant that users could make their life easier by using them rather than having to stay using snapshotted nightlies. I'm glad now libraries are at least supported, which is good enough for my purpose (linking done with gcc, no idea if that's still state of the art for rust-on-stm32 or what), but it had been an annoyance. But I believe procedural macros are still in the same boat. Somewhat tangential, this is the kind of blind spot encouraged by the rustup.sh degeneracy.
    - steveklabnik 11y ago
      When snapshots were the only game, it was all unstable. There's no difference from today. EDIT: sorry, it seems I've mis-read you. I get it now. Unfortunately, we have a strong compatibility story, and so must take strong measures to enforce it. You can use the nightly released on the same night to get a build that's like a particular stable, but allows features.
      - mindslight 11y ago
        Sure, that is simply stating a different way. With the resulting implication that if one wants procedural macros, the stable 1.x releases have unfortunately been empty progress. Breakage from forwards-incompatibility isn't my problem, it's potentially having to tackle it every morning rather than in batch mode when there's a new release. edit: If this compatibility story really dictates that releases can't contain beta features, even with a #![unstable_beta_features_1_6] directive, then a separate beta release would be nice. But now it looks like I'm asking for something additional.