I’d love to see built-in coverage support as well, to go with the built-in test support; a binary built with rustc --test could include built-in coverage analysis. That would make it easy to analyze the coverage of tests written using #[test] methods.
Built-in coverage analysis could do a much more accurate job than external coverage analysis, since it could work by statements/expressions rather than by lines.
I very much agree that Rust programs need to be able to recover from OOM. Returning Result from any function that may allocate would both have terrible ergonomics and massively break backwards compatibility, so the only reasonable thing to do in such circumstances is to panic. That, in turn, means that unwinding must never itself allocate.
It is expected that these panics, like any other, would be caught at rather high levels in the program, and handled generically, like any other unexpected error.
Or that unwinding must allocate a bounded total amount of memory, which Rust could reserve for that purpose.
User defined hooks can be registered which will run when a panic happens.
Not to mention that user-defined Drop impls are called during unwinding.
A band-aid for that would be a lint that triggers if any function is called that may allocate. There has been some work on a #[deny(allocations)] lint by @llogiq
I like this idea. I think it should be Warn-by-default for destructors, but Allow-by-default elsewhere.
Note that if the issue is formatting the message, it is perfectly okay to give a generic message like “Out of memory when formatting panic message” (which can be in static storage) in that case.
Rust should have basic IDE support
I know that when I was first learning computer science having a working debugger in an IDE than I could step through my code and watch variables change over time really helped things "click" for me. As an intellij-rust user, there's not yet debugger integration.
I'm curious if any of the planned work in the Rust community would make it easier for IDEs to have first-class debugging support or if at this point the work is mostly on the individual IDEs?
One thing that could help “boost productivity” or “learn faster” would be a kind of interpreter, dont know if miri will cover all aspects of it, but I think that having introspection like dir(mything) and things like that could help a lot to not go to documentation even do a doc(mythin.y) will help I guess.
ALso debugging and tracing (maybe) could help… well maybe not, but I think that things like http://www.rubyinside.com/ruby-unroller-a-ruby-script-execution-tracer-521.html are nice to have at hand if needed.
After writing code, I've realized that the link_llvm_intrinsics feature is not a feature I want to use. Rather, I'd like to see explicit SIMD (internally based on the platform_intrinsics feature) stabilized instead.
The reason why I'd like to see explicit SIMD stabilized in 2017 (hopefully early 2017) is that I'd like to land encoding_rs in Firefox sooner rather than later, but the most performance-sensitive conversion pair, decoding 100% ASCII or almost 100% ASCII labeled as UTF-8 to UTF-16 (affects the Firefox startup path as well as CSS and JS on the Web even if the content isn't English), would regress in performance without explicit SSE2. (Look for row "English, UTF-8" column "uconv" under "Decode" in the second table of the linked doc: only 63% of Gecko's current decode speed if explicit SSE2 isn't used by encoding_rs but over twice as fast as the current code if explicit SSE2 is used.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.