4 ms·

Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the

Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the thousands of ways in which GCC Rust is not conforming with Rust. I'm not sure what this tells you about Rust. By definition, it is conforming with itself.

steveklabnik 5y ago
Things that have been declared stable do not "change on a daily basis" though.
- volta83 5y ago
  When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?
  - steveklabnik 5y ago
    It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so. That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.
    - pjmlp 5y ago
      In any case, one could consider the Rust epochs as main synchronization points anyway.
      - steveklabnik 5y ago
        I would not, because new things land in most editions, so it’s not like a particular edition refers to a stable subset of the whole language.
        deleted 5y ago
        [deleted]
        pjmlp 5y ago
        True, however with the enterprise hat I see epochs as LTS versions worthy to be the ones on CI/CD pipeline.
        steveklabnik 5y ago
        I think LTS versions are great, but see them as something very distinct from editions. It is something I would like to see us have eventually.
thesuperbigfrog 5y ago
>> Given that "Rust is the spec" . . . >> By definition, it is conforming with itself. If the implementation is the specification, then how do you know what is a bug and what is a feature?
- steveklabnik 5y ago
  The root answer is the same as with a specification, which can also have bugs: the authors make this determination.
- volta83 5y ago
  If you think you found a bug: you just open it. Reviewers / authors / community determine whether its a bug in the compiler or in the spec or both, or not. - How do you know that's something is a compiler bug? Compiler writers typically know. - How do you know that's something is a spec bug? All Rust spec changes go through the RFC process. If the proposal doesn't mention the issue, then its probably a bug. There are also many people maintaining the Rust spec. These people usually know. If nobody knows, you submit an RFC, explaining why you think is a bug. The community can then reading, and the appropriate teams can decide, and if it is merged, then it is a bug. The fix lands at some point, and the fixed Language / standard library / implementation becomes Rust 1.X.Y. Done. --- This is much simpler than in C++, where if you think you found a bug... you could open it in clang or gcc, but if its a spec bug, then that's the wrong place, and it might get closed with "not a bug". Ok so you need to open it in the spec, which you can do, but without you being an ISO member (and paying) there is little on your hand to push this forward.... Anyways supposed this is fixed in the spec, you then re-open it in the implementation you cared about. This might be fixed, or not. Probably not, because it would make this implementation incompatible with another existing one (e.g. clang incompatible with GCC), and that other one could say "fixing this breaks too much code, we won't fix it", so.... now you need to coordinate a bugfix deployment across multiple implementations. Even if you manage that, most fixes get backported, so that means these things introduce breaking changes in, e.g., old C++ standard versions, breaking old code that assumed those to be "stable", etc. And how these fixes are backported differs from compiler to compiler, so now you get a new set of incompatibilities. Some compilers like clang, have flags to configure which fixes get applied and which aren't (e.g. -fabi-compat=...) so that the user can choose which versions with which specification patches of which other compilers the generated code should be compatible with. How many bugs does the C++ spec have? Thousands: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html What happens if you screw your C++ compatibility settings when mixing code from different toolchains (e.g. a library compiled with clang on linux with a binary compiled with gcc or viceveersa) ? Undefined behavior.
nextaccountic 5y ago
The implementation shouldn't be the spec. Rust has a reference.

steveklabnik 5y ago

Things that have been declared stable do not "change on a daily basis" though.

volta83 5y ago
When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?
- steveklabnik 5y ago
  It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so. That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.
  - pjmlp 5y ago
    In any case, one could consider the Rust epochs as main synchronization points anyway.
    - steveklabnik 5y ago
      I would not, because new things land in most editions, so it’s not like a particular edition refers to a stable subset of the whole language.
      - deleted 5y ago
        [deleted]
      - pjmlp 5y ago
        True, however with the enterprise hat I see epochs as LTS versions worthy to be the ones on CI/CD pipeline.
        steveklabnik 5y ago
        I think LTS versions are great, but see them as something very distinct from editions. It is something I would like to see us have eventually.

thesuperbigfrog 5y ago

>> Given that "Rust is the spec" . . . >> By definition, it is conforming with itself. If the implementation is the specification, then how do you know what is a bug and what is a feature?

steveklabnik 5y ago
The root answer is the same as with a specification, which can also have bugs: the authors make this determination.
volta83 5y ago
If you think you found a bug: you just open it. Reviewers / authors / community determine whether its a bug in the compiler or in the spec or both, or not. - How do you know that's something is a compiler bug? Compiler writers typically know. - How do you know that's something is a spec bug? All Rust spec changes go through the RFC process. If the proposal doesn't mention the issue, then its probably a bug. There are also many people maintaining the Rust spec. These people usually know. If nobody knows, you submit an RFC, explaining why you think is a bug. The community can then reading, and the appropriate teams can decide, and if it is merged, then it is a bug. The fix lands at some point, and the fixed Language / standard library / implementation becomes Rust 1.X.Y. Done. --- This is much simpler than in C++, where if you think you found a bug... you could open it in clang or gcc, but if its a spec bug, then that's the wrong place, and it might get closed with "not a bug". Ok so you need to open it in the spec, which you can do, but without you being an ISO member (and paying) there is little on your hand to push this forward.... Anyways supposed this is fixed in the spec, you then re-open it in the implementation you cared about. This might be fixed, or not. Probably not, because it would make this implementation incompatible with another existing one (e.g. clang incompatible with GCC), and that other one could say "fixing this breaks too much code, we won't fix it", so.... now you need to coordinate a bugfix deployment across multiple implementations. Even if you manage that, most fixes get backported, so that means these things introduce breaking changes in, e.g., old C++ standard versions, breaking old code that assumed those to be "stable", etc. And how these fixes are backported differs from compiler to compiler, so now you get a new set of incompatibilities. Some compilers like clang, have flags to configure which fixes get applied and which aren't (e.g. -fabi-compat=...) so that the user can choose which versions with which specification patches of which other compilers the generated code should be compatible with. How many bugs does the C++ spec have? Thousands: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html What happens if you screw your C++ compatibility settings when mixing code from different toolchains (e.g. a library compiled with clang on linux with a binary compiled with gcc or viceveersa) ? Undefined behavior.

nextaccountic 5y ago

The implementation shouldn't be the spec. Rust has a reference.