profile
viewpoint
Jonas Schievink jonas-schievink @ferrous-systems Berlin, Germany compilers; embedded systems; emulators; Linux; everything Rust. please do not send me blockchain recruiting emails

dac-gmbh/serde_postgres 48

Easily Deserialize Postgres rows.

dac-gmbh/golomb-set 27

A Golomb Coded Set implementation in Rust

dac-gmbh/mail 18

mail, facade for a number of mail related crates for creating and sending mails

dac-gmbh/derefable 15

Automatically derive Deref/DerefMut implementations in Rust.

dac-gmbh/asn1 10

An implementation of the ITU ASN.1 (X.680–X.699) specifications in Rust.

dac-gmbh/new-tokio-smtp 7

extendible SMTP (Simple Mail Transfer Protocol) implementation using tokio

dac-gmbh/hyperdrive 5

Declarative HTTP request routing, guarding and decoding

dac-gmbh/gbl 4

GBL firmware file manipulation library

dac-gmbh/Variation 4

A procedural macro to generate variant based methods.

dac-gmbh/mail-chars 3

provids lookup table based char classification for mail related grammars

push eventjonas-schievink/rubble

Travis CI User

commit sha 4830050998cac60194f1ec53d00c0858c8527175

Update documentation

view details

push time in 36 minutes

Pull request review commentrust-embedded/r0

Readme update

-[![Build status](https://travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0)+# r0++[![Build status](https://api.travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0) [![crates.io](https://img.shields.io/crates/d/r0.svg)](https://crates.io/crates/r0) [![crates.io](https://img.shields.io/crates/v/r0.svg)](https://crates.io/crates/r0) -# `r0`+Memory initialization code **crt0** written in Rust. This crate is for bare metal systems where there is no ELF loader or OS to take care of initializing RAM for the program. Is also provides an API to add «life before main» functionality to bare metal systems.

https://github.com/rust-embedded/r0/blob/master/CHANGELOG.md#unreleased

arrowcircle

comment created time in 3 hours

Pull request review commentrust-embedded/r0

Readme update

-[![Build status](https://travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0)+# r0++[![Build status](https://api.travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0) [![crates.io](https://img.shields.io/crates/d/r0.svg)](https://crates.io/crates/r0) [![crates.io](https://img.shields.io/crates/v/r0.svg)](https://crates.io/crates/r0) -# `r0`+Memory initialization code **crt0** written in Rust. This crate is for bare metal systems where there is no ELF loader or OS to take care of initializing RAM for the program. Is also provides an API to add «life before main» functionality to bare metal systems.++This project is used by other crates, like:++* [cortex-m-rt](https://github.com/rust-embedded/cortex-m-rt)+* [riscv-rt](https://github.com/rust-embedded/riscv-rt)+* [msp430-rt](https://github.com/rust-embedded/msp430-rt) -Memory initialization code ("[crt0]") written in Rust.+Wiki quote:++> crt0 (also known as c0) is a set of execution startup routines linked into a C program that performs any initialization work required before calling the program's main function.+> It generally takes the form of an object file called crt0.o, often written in assembly language, which is automatically included by the linker into every executable file it builds.++Read more about [crt0](https://en.wikipedia.org/wiki/Crt0).  This project is developed and maintained by the [Cortex-A, Cortex-M, Cortex-R, MSP430, and RISCV teams][teams]. -[crt0]: https://en.wikipedia.org/wiki/Crt0- ## [Documentation](https://docs.rs/r0)  ## License  Licensed under either of -- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or-  http://www.apache.org/licenses/LICENSE-2.0)-- MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)+* Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or [http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0))+* MIT license ([LICENSE-MIT](LICENSE-MIT) or [http://opensource.org/licenses/MIT](http://opensource.org/licenses/MIT))

These changes are not necessary

arrowcircle

comment created time in 3 hours

Pull request review commentrust-embedded/r0

Readme update

-[![Build status](https://travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0)+# r0++[![Build status](https://api.travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0) [![crates.io](https://img.shields.io/crates/d/r0.svg)](https://crates.io/crates/r0) [![crates.io](https://img.shields.io/crates/v/r0.svg)](https://crates.io/crates/r0) -# `r0`+Memory initialization code **crt0** written in Rust. This crate is for bare metal systems where there is no ELF loader or OS to take care of initializing RAM for the program. Is also provides an API to add «life before main» functionality to bare metal systems.++This project is used by other crates, like:++* [cortex-m-rt](https://github.com/rust-embedded/cortex-m-rt)+* [riscv-rt](https://github.com/rust-embedded/riscv-rt)+* [msp430-rt](https://github.com/rust-embedded/msp430-rt) -Memory initialization code ("[crt0]") written in Rust.+Wiki quote:++> crt0 (also known as c0) is a set of execution startup routines linked into a C program that performs any initialization work required before calling the program's main function.+> It generally takes the form of an object file called crt0.o, often written in assembly language, which is automatically included by the linker into every executable file it builds.++Read more about [crt0](https://en.wikipedia.org/wiki/Crt0).

The wiki quote also makes it sound like this is a crt0 implementation. I'd prefer to just link there, maybe with an explanation like

This crate provides similar functionality to [crt0](https://en.wikipedia.org/wiki/Crt0) in the C runtime.
arrowcircle

comment created time in 3 hours

Pull request review commentrust-embedded/r0

Readme update

-[![Build status](https://travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0)+# r0++[![Build status](https://api.travis-ci.org/rust-embedded/r0.svg?branch=master)](https://travis-ci.org/rust-embedded/r0) [![crates.io](https://img.shields.io/crates/d/r0.svg)](https://crates.io/crates/r0) [![crates.io](https://img.shields.io/crates/v/r0.svg)](https://crates.io/crates/r0) -# `r0`+Memory initialization code **crt0** written in Rust. This crate is for bare metal systems where there is no ELF loader or OS to take care of initializing RAM for the program. Is also provides an API to add «life before main» functionality to bare metal systems.

This is not a C runtime, which is why "crt0" is in quotes in the lib.rs documentation.

Also, all the life before main stuff has been removed.

arrowcircle

comment created time in 3 hours

pull request commentrust-lang/rust

perf: Unify the undo log of all snapshot types

@bors try @rust-timer queue

Marwes

comment created time in 15 hours

pull request commentrust-lang/rust

Cherry-pick the LLVM fix for #69225

@bors retry

cuviper

comment created time in 16 hours

pull request commentrust-lang/rust

perf: Unify the undo log of all snapshot types

(feel free to ping me when this builds so I can run perf)

Marwes

comment created time in 16 hours

startedHeroicKatora/ethox

started time in 16 hours

issue closedrust-lang/rust

`noreturn` on diverging functions makes LLVM trash the link register on thumb targets

Downstream issue: https://github.com/rust-embedded/cortex-m-rt/issues/139

It looks like LLVM is extremely eager to overwrite the Link Register without saving it as soon as noreturn is put on a function. Since rustc does that for any -> ! function, which includes many parts of the panic machinery, this effectively makes obtaining a backtrace on panic on embedded systems impossible.

This is somewhat analogous to omission of frame pointers on x86, so maybe -Cforce-frame-pointers can be repurposed to prevent this behavior on Thumb/ARM targets? I'm not sure there's even an LLVM feature to control this specifically, but I suppose rustc could always omit the noreturn.

Since this is only important in debug builds (that may be optimized, however), it might make sense to couple this behavior to whether debug assertions are enabled, but I'm not sure about that. What do you think? Would a patch doing something of this sort be accepted?

closed time in 17 hours

jonas-schievink

issue commentrust-lang/rust

`noreturn` on diverging functions makes LLVM trash the link register on thumb targets

I have not, but #69248 seems to fix this perfectly (with a cost in binary and stack size, of course), so closing this as fixed.

jonas-schievink

comment created time in 17 hours

issue commentmciantyre/teensy4-rs

Certain sub-PAC crates build slowly

Just to clarify (as someone who isn't using these crates actively at the moment), do the graphs above mean that rustc takes over a minute to build a PAC for a single peripheral?

mciantyre

comment created time in 17 hours

pull request commentrust-lang/rfcs

RFC: Existential types with external definition

If this feature would be slightly extended by allowing the crate to define a default type, this would effectively give us type-checked language-level weak linkage. This would help the embedded ecosystem tremendously, since there are a lot of things that could be expressed in terms of this feature (eg. bare-metal chip initialization code that could be customized downstream to support "weird" chips, exception handlers with reasonable zero-cost defaults, etc.).

Ericson2314

comment created time in 17 hours

issue commentrust-lang/rust

Re-land "add IntoFuture trait and support for await"

It has been reopened as https://github.com/rust-lang/rust/pull/68811. According to perf there's still a compile time regression of up to ~6% present.

tmandry

comment created time in 18 hours

pull request commentrust-lang/rust

perf: Unify the undo log of all snapshot types

@bors try-

Marwes

comment created time in 18 hours

pull request commentrust-lang/rust

perf: Unify the undo log of all snapshot types

@bors try @rust-timer queue

Marwes

comment created time in 19 hours

push eventjonas-schievink/rubble

Travis CI User

commit sha b80f0ff40ff2a06c37ebf740066786bc5aef2be3

Update documentation

view details

push time in a day

issue closedrust-lang/rust

`impl From<Infallible> for MyType` does not solve coercion problems

playground link with all the impls and functions in example usage The gist is that I have an impl impl TryFrom<usize> for InvariantType and function signatures with TryInto<InvariantType, Error = MyErrorType>. This enables many ergonomics, but trying to input a plain InvariantType into the function conflicts with the blanket impl TryFrom<T> for T which has a return type ! instead of Error = MyErrorType.

Since ! can and will coerce into anything through a future impl<T> From<!> for T , and there is a current workaround:

impl From<Infallible> for MyError {
    fn from(_: Infallible) -> Self {
        unreachable!()
    }
}

it should work, but adding this to the playground link does not change the error message at all.

Also in the playground link, there is a nearly identical error related to a From<NonZeroUsize> for BitWidth and its blanket impls. In that case, I can't even apply the attempted workaround because of orphan rules.

closed time in 2 days

AaronKutch

issue commentrust-lang/rust

`impl From<Infallible> for MyType` does not solve coercion problems

Adding the From impl does not create a TryFrom impl for an unrelated type. Change typical_function to take a generic error E instead and add where MyError: From<E> to its bounds.

AaronKutch

comment created time in 2 days

push eventjonas-schievink/rubble

Travis CI User

commit sha c7696bb4dfdd3cdae186cf5366b6a92bad921d9b

Update documentation

view details

push time in 2 days

issue closedrust-lang/rust

Is it a desirable behavior?

I tried this code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6bd7b465cf1b76c355e4792768ecd8cb

#![feature(generic_associated_types)]
#![feature(const_generics)]

trait Test {
    type T: std::ops::Add;
    const C: Self::T;
    fn lower<'a>()-> &'a dyn Test<T=Self::T,C={2+2}>;
}

I expected to see this happen: Actually i wanted to blow up compiler (to see, where it blows) =).

Instead, this happened: But things didn't go further from parsing stage.

From playground: rustc --version --verbose:

1.43.0-nightly 2020-02-22 436494b8f8008b600d64

P.S Maybe its still too early for that...

closed time in 3 days

tema3210

issue commentrust-lang/rust

Is it a desirable behavior?

This has nothing to do with const generics or GATs, it's just that you can't specify associated constants in trait objects, which is intended (they are not object safe).

tema3210

comment created time in 3 days

push eventjonas-schievink/rubble

Travis CI User

commit sha 1387ddc018c017cfbd82e5e4f3a18fc28e63835e

Update documentation

view details

push time in 3 days

issue commentrust-lang/rust

Miscompilation with clashing symbol fn names of different types

cc https://github.com/rust-lang/rust/issues/28179

jumbatm

comment created time in 3 days

pull request commentrust-lang/rust

perf: Only process changed obligations in ObligationForest

@bors try @rust-timer queue

Marwes

comment created time in 3 days

issue commentrust-lang/rust

Single file takes 30 minutes to compile at opt-level=3, regression from <1 sec

Marking needstest to add a test to https://github.com/rust-lang-nursery/rustc-perf/

dabek

comment created time in 4 days

delete branch jonas-schievink/bare-metal

delete branch : mutex-utils

delete time in 4 days

issue commentrust-embedded/cortex-m

`interrupt::free` does not disable all exceptions, which breaks critical sections

One of the consequences of this is that registering HardFault to use hprintln! is never sound since that calls interrupt::free internally. Since this seems to be a common use case of HardFault, this is very unfortunate.

jonas-schievink

comment created time in 4 days

issue openedrust-embedded/cortex-m

`interrupt::free` does not disable all exceptions, which breaks critical sections

It calls interrupt::disable, which uses cpsid i, which disables interrupts and exceptions that have configurable priority by setting PRIMASK. Notably, this does not affect (on thumbv6) the NMI and HardFault exceptions since they have fixed priorities.

This means that interrupt::free is unsoundly creating a CriticalSection token when it's not allowed to do so.

Note that it is impossible to fully fix this just in the cortex-m crate, since NMI is always enabled and can not be masked (which is its entire point, I suppose). Also, FAULTMASK could be used to also disable HardFault, but that only exists on thumbv7+ from what I can tell.

Our options here are:

  • Change cortex-m-rt to require unsafe to register HardFault, NMI, etc. handlers
  • Use FAULTMASK / cpsid f when targeting thumbv7+, which could allow safe registration of fault handlers except NMI on thumbv7+ (note that FAULTMASK has somewhat subtle behavior that differs from PRIMASK, so this needs some extra care to make sure it's sound)
  • Make interrupt::free an unsafe fn and document that it's only safe to call when not in one of the non-maskable fault handlers

We should probably change the docs of bare_metal::CriticalSection to reflect semantics when NMIs are present.

This issue is somewhat thorny since 3 crates rely on properties of each other for soundness (cortex-m, cortex-m-rt, and bare-metal).

(thanks to @japaric for noticing this)

created time in 4 days

push eventjonas-schievink/rubble

Travis CI User

commit sha 5112d4bb7532c28f2120a05cb8e04afdc373cbe1

Update documentation

view details

push time in 4 days

PR opened rust-embedded/bare-metal

Add `Mutex::{get_mut, into_inner}`

These mirror the API of std::sync::Mutex (modulo poisoning) and can be pretty helpful sometimes.

+13 -2

0 comment

1 changed file

pr created time in 4 days

create barnchjonas-schievink/bare-metal

branch : mutex-utils

created branch time in 4 days

issue closedrust-lang/rust

HIR item node was not preallocated

I replaced a type variable with a concrete type across my

I tried this change: https://github.com/xurtis/autumn/compare/e0554e8...00f2386

I expected the code to compile.

Instead, the compiler produced this error:

error: internal compiler error: src/librustc/dep_graph/graph.rs:680: DepNode Hir(autumn[d837]::location[0]::Location[0]::character[0]) should have been pre-allocated but wasn't.

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:905:9

Meta

rustc version

  • rustc 1.41.0 (5e1a79984 2020-01-27)
  • binary: rustc
  • commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
  • commit-date: 2020-01-27
  • host: x86_64-unknown-linux-gnu
  • release: 1.41.0
  • LLVM version: 9.0

Backtrace

stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:475
  12: std::panicking::begin_panic
  13: rustc_errors::HandlerInner::bug
  14: rustc_errors::Handler::bug
  15: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  16: rustc::ty::context::tls::with_opt::{{closure}}
  17: rustc::ty::context::tls::with_opt
  18: rustc::util::bug::opt_span_bug_fmt
  19: rustc::util::bug::bug_fmt
  20: rustc::dep_graph::graph::DepGraph::try_mark_previous_green
  21: rustc::dep_graph::graph::DepGraph::try_mark_green
  22: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
  23: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  24: <rustc_typeck::outlives::implicit_infer::InferVisitor as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  25: rustc::hir::Crate::visit_all_item_likes
  26: rustc_typeck::outlives::inferred_outlives_crate
  27: rustc::ty::query::__query_compute::inferred_outlives_crate
  28: rustc::dep_graph::graph::DepGraph::with_task_impl
  29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  30: rustc_typeck::outlives::inferred_outlives_of
  31: rustc::ty::query::__query_compute::inferred_outlives_of
  32: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::inferred_outlives_of>::compute
  33: rustc::dep_graph::graph::DepGraph::with_task_impl
  34: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  35: rustc_typeck::collect::predicates_defined_on
  36: rustc::ty::query::__query_compute::predicates_defined_on
  37: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::predicates_defined_on>::compute
  38: rustc::dep_graph::graph::DepGraph::with_task_impl
  39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::force_query
  40: rustc::ty::query::plumbing::force_from_dep_node
  41: rustc::dep_graph::graph::DepGraph::try_mark_previous_green
  42: rustc::dep_graph::graph::DepGraph::try_mark_green
  43: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
  44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  45: <rustc_typeck::collect::CollectItemTypesVisitor as rustc::hir::intravisit::Visitor>::visit_item
  46: rustc::hir::map::Map::visit_item_likes_in_module
  47: rustc_typeck::collect::collect_mod_item_types
  48: rustc::ty::query::__query_compute::collect_mod_item_types
  49: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::collect_mod_item_types>::compute
  50: rustc::dep_graph::graph::DepGraph::with_task_impl
  51: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  52: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::ensure_query
  53: rustc_typeck::check_crate::{{closure}}::{{closure}}
  54: rustc::util::common::time
  55: rustc_typeck::check_crate
  56: rustc_interface::passes::analysis
  57: rustc::ty::query::__query_compute::analysis
  58: rustc::dep_graph::graph::DepGraph::with_task_impl
  59: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  60: rustc::ty::context::tls::enter_global
  61: rustc_interface::interface::run_compiler_in_existing_thread_pool
  62: std::thread::local::LocalKey<T>::with
  63: scoped_tls::ScopedKey<T>::set
  64: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.41.0 (5e1a79984 2020-01-27) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [type_of] processing `location::Location::character`
#1 [inferred_outlives_crate] computing the inferred outlives predicates for items in this crate
#2 [inferred_outlives_of] processing `combinators::Multiple`
#3 [predicates_defined_on] processing `combinators::Multiple`
#4 [predicates_of] processing `combinators::Multiple`
#5 [collect_mod_item_types] collecting item types in module `combinators`
#6 [analysis] running analysis passes on this crate
end of query stack

closed time in 4 days

xurtis

issue commentrust-lang/rust

HIR item node was not preallocated

Duplicate of https://github.com/rust-lang/rust/issues/62649

xurtis

comment created time in 4 days

pull request commentnrf-rs/nrf52-hal

Implement a polling async SPI interface

I think this looks basically fine now. Have you tested this on real hardware?

dflemstr

comment created time in 5 days

push eventjonas-schievink/rust

Oliver Middleton

commit sha 84f3356e0dffc36f57d9be7902822db5d362e24f

Simplify `Skip::nth` and `Skip::last` implementations The main improvement is to make `last` no longer recursive.

view details

Michael Bradshaw

commit sha 348278a7fd5fd459f555dd763e71e12c23c1661a

Stabilize Once::is_completed

view details

Dylan MacKenzie

commit sha c981d67b509f1ba16c97683ad6dc430429899e49

[!] Use `rustc_inherit_overflow_checks` in `next_power_of_two` I believe the previous code was calling `ops::Add::add` instead of the `+` operator to get this behavior.

view details

Dylan MacKenzie

commit sha 2afa99379d9623e50efd290e609447bdc5059af8

Use bespoke macro instead of `?` inside const fns

view details

Dylan MacKenzie

commit sha 269bf89865536964546242589bb186a8a7e3c566

Make integer power methods const

view details

Dylan MacKenzie

commit sha 7fe5eaf7d8cb23ceb71d8e509be13d20ef836114

Test integer exponentiation in a const context

view details

Esteban Küber

commit sha 683ebc2dec0a5b88eb3eaf146e6855ea299d17b8

On mismatched argument count point at arguments

view details

Dylan MacKenzie

commit sha fc5c2956b11e29f931cec010e3f38461ec4ac309

Impl `GenKill` for old dataflow framework's `GenKillSet` This impl is temporary and will be removed along with the old dataflow framework. It allows us to reuse the transfer function of new dataflow analyses when defining old ones

view details

Dylan MacKenzie

commit sha 7d9dadcccca9efc63f30fa1c9adee00effb860d4

Implement `Maybe{Mut,}BorrowedLocals` analyses

view details

Dylan MacKenzie

commit sha 34783b73bd891a66fb2af613fef7492376fc7c8a

Remove outdated `IndirectlyMutableLocals` `MaybeMutBorrowedLocals` serves the same purpose and has a better name.

view details

Dylan MacKenzie

commit sha 9972502bafab062b06ef04c02c653f1b868937bd

Reenable peek test for indirect mutation analysis This uses the new `MaybeMutBorrowedLocals` pass but we keep the `rustc_peek_indirectly_mutable` since the two are interchangable except when inspecting a local after it has been marked `StorageDead`.

view details

Dylan MacKenzie

commit sha 1d737fb032b762e69e8d809c0e042d45e08b457d

Use `MaybeBorrowedLocals` for generator analyses It should have the same semantics as `HaveBeenBorrowedLocals`

view details

Dylan MacKenzie

commit sha d045a17c4b032a858323f6c9bea698ee2e5920b7

Use `MaybeMutBorrowedLocals` for const-checking

view details

Dylan MacKenzie

commit sha 6f167e9c5f421613ff3de37771b1352cd98dd4f7

Remove ignore and add explanation of indirect mutation peek test

view details

Eric Huss

commit sha 4810c4712f9edc4c378142ace1b868fc2fd1eeea

Add shared script for linkchecking books.

view details

Matthew Jasper

commit sha cd9f5ff2a1c50a5af94ad1dd1c976f631b9f19a6

Check `Copy` lifetimes bounds when copying from a projection

view details

Matthew Jasper

commit sha ddc25456c5945457ba86cb60994ce9872bd98edd

Check types of statics in MIR typeck

view details

Dylan MacKenzie

commit sha 15a5382ef1115ff11c1357fd21ab4aa12626efee

Rename `MaybeBorrowedLocals` constructors

view details

Dylan MacKenzie

commit sha 0984639348c2fc98389746f6815e576cfcaacda8

Ignore mut borrow from drop terminator in const-eval

view details

Dylan MacKenzie

commit sha 668d2fe807068073647f9c92d81ff0e7b9ab8486

Update line # in test output

view details

push time in 5 days

Pull request review commentnrf-rs/nrf52-hal

Implement a polling async SPI interface

 where     } } +impl<'a, T> SpiTransaction<'a, T>+where+    T: Instance,+{+    fn new(spim: &'a mut T, chip_select: &'a mut Pin<Output<PushPull>>) -> Self {+        chip_select.set_low().unwrap();+        Self { spim, chip_select }+    }++    /// Read and write from a SPI slave, using a single buffer.+    ///+    /// This is an async polling version of `transfer()`.  You need to call+    /// `.poll_complete()` on the returned object until it returns `true`.  A+    /// good time to do that would be after receiving a SPI interrupt, for+    /// example.+    ///+    /// This method implements a complete read transaction, which consists of+    /// the master transmitting what it wishes to read, and the slave responding+    /// with the requested data.+    ///+    /// Uses the provided chip select pin to initiate the transaction. Transmits+    /// all bytes in `buffer`, then receives an equal number of bytes.+    pub fn transfer_polling<'b>(+        &'b mut self,+        buffer: &'b mut [u8],+    ) -> Result<SpiTransfer<'b, T>, Error> {+        SpiTransfer::new(self.spim, buffer)+    }++    /// Read and write from a SPI slave, using separate read and write buffers+    ///+    /// This is an async polling version of `transfer_split_even()`.  You need to+    /// call `.poll_complete()` on the returned object until it returns `true`.+    /// A good time to do that would be after receiving a SPI interrupt, for+    /// example.+    ///+    /// This method implements a complete read transaction, which consists of+    /// the master transmitting what it wishes to read, and the slave responding+    /// with the requested data.+    ///+    /// Uses the provided chip select pin to initiate the transaction. Transmits+    /// all bytes in `tx_buffer`, then receives bytes until `rx_buffer` is full.+    ///+    /// If `tx_buffer.len() != rx_buffer.len()`, the transaction will stop at the+    /// smaller of either buffer.+    pub fn transfer_split_even_polling<'b>(+        &'b mut self,+        tx_buffer: &'b [u8],+        rx_buffer: &'b mut [u8],+    ) -> Result<SpiEvenTransfer<'b, T>, Error> {+        SpiEvenTransfer::new(self.spim, tx_buffer, rx_buffer)+    }++    /// Read and write from a SPI slave, using separate read and write buffers+    ///+    /// This is an async polling version of `transfer_split_uneven()`.  You need to+    /// call `.poll_complete()` on the returned object until it returns `true`.+    /// A good time to do that would be after receiving a SPI interrupt, for+    /// example.+    ///+    /// This method implements a complete read transaction, which consists of+    /// the master transmitting what it wishes to read, and the slave responding+    /// with the requested data.+    ///+    /// Uses the provided chip select pin to initiate the transaction. Transmits+    /// all bytes in `tx_buffer`, then receives bytes until `rx_buffer` is full.+    ///+    /// This method is more complicated than the other `transfer` methods because+    /// it is allowed to perform transactions where `tx_buffer.len() != rx_buffer.len()`.+    /// If this occurs, extra incoming bytes will be discarded, OR extra outgoing bytes+    /// will be filled with the `orc` value.

Looks good, thanks!

dflemstr

comment created time in 5 days

Pull request review commentnrf-rs/nrf52-hal

Implement a polling async SPI interface

 use embedded_hal::digital::v2::OutputPin; /// - The SPIM instances share the same address space with instances of SPIS, ///   SPI, TWIM, TWIS, and TWI. You need to make sure that conflicting instances ///   are disabled before using `Spim`. See product specification, section 15.2.+#[derive(Debug)] pub struct Spim<T>(T);

Ah, that sounds really useful actually!

dflemstr

comment created time in 5 days

pull request commentrust-lang/rust

perf: Only process changed obligations in ObligationForest

@bors try @rust-timer queue

Marwes

comment created time in 5 days

push eventjonas-schievink/rubble

Travis CI User

commit sha 258d2e895a68935b78d17516da56708e32beeff9

Update documentation

view details

push time in 5 days

create barnchjonas-schievink/nrf52-hal

branch : usb

created branch time in 6 days

create barnchjonas-schievink/usb-device

branch : inhibit-setaddr-resp

created branch time in 6 days

fork jonas-schievink/usb-device

Experimental device-side USB framework for microcontrollers in Rust.

fork in 6 days

issue closedrust-lang/rust

rustc 1.43.0-nightly (7760cd0fb 2020-02-19) static builds on alpine throw compiler error on building any orjson/maturin

Rust compiler states this is a bug and should be reported, so I'm listening to the compiler 😂

I use orjson in an alpine environment for fast json parsing in python. Unfortunately, the latest release and its dependencies have learned how to provoke a bug in rustc! 😮

Output:

Building wheels for collected packages: orjson
  Created temporary directory: /tmp/pip-wheel-puew_nt4
  Destination directory: /tmp/pip-wheel-puew_nt4
  Building wheel for orjson (PEP 517): started
  Running command /usr/local/bin/python3 /usr/local/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /tmp/tmp7cas0fmw
     Compiling proc-macro2 v1.0.8
     Compiling unicode-xid v0.2.0
     Compiling syn v1.0.14
     Compiling cfg-if v0.1.10
     Compiling ryu v1.0.2
     Compiling libc v0.2.66
     Compiling serde v1.0.104
     Compiling memchr v2.3.2
     Compiling typenum v1.11.2
     Compiling getrandom v0.1.14
     Compiling lazy_static v1.4.0
     Compiling autocfg v1.0.0
     Compiling regex-syntax v0.6.14
     Compiling itoa v0.4.5
     Compiling bitflags v1.2.1
     Compiling byteorder v1.3.4
     Compiling lexical-core v0.7.4
     Compiling unindent v0.1.5
     Compiling ppv-lite86 v0.2.6
     Compiling version_check v0.9.1
     Compiling scopeguard v1.1.0
     Compiling packed_simd v0.3.3
     Compiling smallvec v1.2.0
     Compiling encoding_rs v0.8.22
     Compiling arrayvec v0.5.1
     Compiling stable_deref_trait v1.1.1
     Compiling static_assertions v1.1.0
     Compiling heapless v0.5.3
     Compiling rand_core v0.4.2
     Compiling associative-cache v1.0.1
     Compiling inlinable_string v0.1.11
     Compiling thread_local v1.0.1
     Compiling lock_api v0.3.3
     Compiling wyhash v0.3.0
     Compiling c2-chacha v0.2.3
     Compiling num-traits v0.2.11
     Compiling aho-corasick v0.7.8
     Compiling hash32 v0.1.1
     Compiling quote v1.0.2
     Compiling parking_lot_core v0.7.0
     Compiling rand_core v0.5.1
     Compiling generic-array v0.12.3
     Compiling generic-array v0.13.2
     Compiling parking_lot v0.10.0
     Compiling rand_chacha v0.2.1
     Compiling regex v1.3.4
     Compiling as-slice v0.1.3
     Compiling rand v0.7.3
     Compiling pyo3-derive-backend v0.9.0-alpha.1
  thread 'rustc' panicked at 'Box<Any>', <::std::macros::panic macros>:2:4
  stack backtrace:
     0: backtrace::backtrace::libunwind::trace
               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
     1: backtrace::backtrace::trace_unsynchronized
               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
     2: std::sys_common::backtrace::_print_fmt
               at src/libstd/sys_common/backtrace.rs:78
     3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
               at src/libstd/sys_common/backtrace.rs:59
     4: core::fmt::write
               at src/libcore/fmt/mod.rs:1052
     5: std::io::Write::write_fmt
               at src/libstd/io/mod.rs:1428
     6: std::sys_common::backtrace::_print
               at src/libstd/sys_common/backtrace.rs:62
     7: std::sys_common::backtrace::print
               at src/libstd/sys_common/backtrace.rs:49
     8: std::panicking::default_hook::{{closure}}
               at src/libstd/panicking.rs:204
     9: std::panicking::default_hook
               at src/libstd/panicking.rs:224
    10: rustc_driver::report_ice
    11: std::panicking::rust_panic_with_hook
               at src/libstd/panicking.rs:474
    12: std::panicking::begin_panic
    13: rustc_errors::HandlerInner::span_bug
    14: rustc_errors::Handler::span_bug
    15: rustc::util::bug::opt_span_bug_fmt::{{closure}}
    16: rustc::ty::context::tls::with_opt::{{closure}}
    17: rustc::ty::context::tls::with_opt
    18: rustc::util::bug::opt_span_bug_fmt
    19: rustc::util::bug::span_bug_fmt
    20: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
    21: rustc_codegen_ssa::mir::block::<impl rustc_codegen_ssa::mir::FunctionCx<Bx>>::codegen_call_terminator
    22: rustc_codegen_ssa::mir::block::<impl rustc_codegen_ssa::mir::FunctionCx<Bx>>::codegen_block
    23: rustc_codegen_ssa::base::codegen_instance
    24: <rustc::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::define
    25: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
    26: rustc::dep_graph::graph::DepGraph::with_task
    27: rustc_codegen_llvm::base::compile_codegen_unit
    28: rustc_codegen_ssa::base::codegen_crate
    29: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
    30: rustc_session::utils::<impl rustc_session::session::Session>::time
    31: rustc_interface::passes::QueryContext::enter
    32: rustc_interface::queries::Queries::ongoing_codegen
    33: rustc_interface::interface::run_compiler_in_existing_thread_pool
    34: scoped_tls::ScopedKey<T>::set
    35: syntax::attr::with_globals
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

  note: the compiler unexpectedly panicked. this is a bug.

  note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

  note: rustc 1.43.0-nightly (7760cd0fb 2020-02-19) running on x86_64-unknown-linux-musl

  note: compiler flags: -C opt-level=3 -C panic=abort -C codegen-units=1 -C target-feature=-crt-static --crate-type lib

  note: some of the compiler flags provided by cargo are hidden

  query stack during panic:
  end of query stack
  error: could not compile `encoding_rs`.

  To learn more, run the command again with --verbose.
  warning: build failed, waiting for other jobs to finish...
  error: build failed
  💥 maturin failed
    Caused by: Failed to build a native library through cargo
    Caused by: Cargo build finished with "exit code: 101": `cargo rustc --message-format json --manifest-path Cargo.toml --lib --release -- -Zmutable-noalias -C target-feature=+sse2 -C link-arg=-s`
  Running `maturin pep517 build-wheel -i python --manylinux=off --rustc-extra-args=-Zmutable-noalias -C target-feature=+sse2 --strip=on`
  Error: Command '['maturin', 'pep517', 'build-wheel', '-i', 'python', '--manylinux=off', '--rustc-extra-args=-Zmutable-noalias -C target-feature=+sse2', '--strip=on']' returned non-zero exit status 1.
  Building wheel for orjson (PEP 517): finished with status 'error'
  ERROR: Failed building wheel for orjson

Here's how I caused it (I use osx as a main development machine so all my linux builds are through docker 🙃

Dockerfile:

FROM python:3.7-alpine
ENV PIP_NO_CACHE_DIR=off \
    PIP_DISABLE_PIP_VERSION_CHECK=on \
    RUSTUP_HOME=/usr/local \
    CARGO_HOME=/usr/local \
    RUSTFLAGS="-C target-feature=-crt-static" \
    RUST_BACKTRACE=1
RUN apk add --no-cache build-base libffi-dev openssl-dev curl && \
    (curl https://sh.rustup.rs -sSf | sh -s -- -y --no-modify-path) && rustup install nightly && rustup default nightly && \
    python3 -m ensurepip && \
    pip3 install --upgrade pip setuptools wheel && \
    if [[ ! -e /usr/bin/python ]]; then ln -sf /usr/bin/python3 /usr/bin/python; fi
RUN python3 -m pip install --verbose orjson

Trigger the build via: docker build -f Dockerfile . and watch it explode

Just tried an earlier orjson. Same error 😳

closed time in 6 days

autumnjolitz

push eventnrf-rs/nrf91

Jonathan 'theJPster' Pallant

commit sha 2b765ffa4a9d471cbb55e6c9831fa1dce060330d

Renamed to nrf9160-pac. Also noted you probably want the HAL rather than this crate.

view details

Jonas Schievink

commit sha d820dd9f94613ea79727a66e24564a41e6f41d2a

Merge pull request #9 from thejpster/rename_crate Rename crate

view details

push time in 6 days

PR merged nrf-rs/nrf91

Rename crate

Fixes #4.

We'd also need to rename the repo, and perhaps do a 0.1.1 push to the old crate updating the README with the new name.

+12 -10

0 comment

3 changed files

thejpster

pr closed time in 6 days

issue closednrf-rs/nrf91

Rename to nrf9160-pac

We should rename this in advance of any new members of the nRF91 family appearing.

closed time in 6 days

thejpster

push eventnrf-rs/nrf91

Jonathan 'theJPster' Pallant

commit sha 042597ff5a2e93c8f473a4e2f4a0a656488d2630

Remove the lints that 1.41 stable complains about.

view details

Jonas Schievink

commit sha e23dec200b35c802cc6c94c01f7a3583bd13b43a

Merge pull request #8 from thejpster/remove_unknown_lints Remove the lints that 1.41 stable complains about.

view details

push time in 6 days

issue closednrf-rs/nrf91

Builds with warnings

arning: lint `legacy_directory_ownership` has been removed: `converted into hard error, see https://github.com/rust-lang/rust/issues/37872`
 --> src/lib.rs:5:9
  |
5 | #![deny(legacy_directory_ownership)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(renamed_and_removed_lints)]` on by default

warning: lint `plugin_as_library` has been removed: `plugins have been deprecated and retired`
  --> src/lib.rs:12:9
   |
12 | #![deny(plugin_as_library)]
   |         ^^^^^^^^^^^^^^^^^

warning: lint `safe_extern_statics` has been removed: `converted into hard error, see https://github.com/rust-lang/rust/issues/36247`
  --> src/lib.rs:14:9
   |
14 | #![deny(safe_extern_statics)]
   |         ^^^^^^^^^^^^^^^^^^^

warning: unknown lint: `unions_with_drop_fields`
  --> src/lib.rs:16:9
   |
16 | #![deny(unions_with_drop_fields)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unknown_lints)]` on by default

Should we worry about this?

closed time in 6 days

thejpster

delete branch nrf-rs/nrf91

delete branch : update

delete time in 6 days

pull request commentnrf-rs/nrf91

Regenerate with svd2rust 0.17.0

Looks like there's no CI on any of the PACs

jonas-schievink

comment created time in 6 days

push eventnrf-rs/nrf91

Jonas Schievink

commit sha d225c251402368cbbcdcc9d8d3cf5f768f3d0684

Add regeneration instructions

view details

Jonas Schievink

commit sha 0155ad82adb1fbfa58ae8a892ca89f4920ce5388

Regenerate with svd2rust 0.17.0

view details

Jonas Schievink

commit sha 67d1fc154130461946b82dd1c11f41cde1d8eb61

Manually fix some paths

view details

Jonas Schievink

commit sha f2fd67c5ce2644abafc89b7e4e679874611cb47b

Update repo URL

view details

Jonas Schievink

commit sha 87d68a2c6502abb12248ff848b1deadabb9ba6d8

Merge pull request #6 from nrf-rs/update Regenerate with svd2rust 0.17.0

view details

push time in 6 days

PR merged nrf-rs/nrf91

Regenerate with svd2rust 0.17.0

It looks like Nordic added more things to the SVD since the last version of this crate was generated?

Also adds readme instructions and updates the repo link.

Looks like the version was already bumped in the manifest, so a new release can probably be published immediately after this?

+7540 -10555

3 comments

580 changed files

jonas-schievink

pr closed time in 6 days

issue closedrust-lang/rust

Parsing inconsistencies (lambda, proc, return)

I found more inconsistencies between rustc and parser-lalr.

I also noticed that Rust allows return expressions and lambda expressions to end with a struct literal, even when they're in a nostruct context. This seems inconsistent to me.

Lambdas (the two parsers disagree):

struct A { a: i32 }
fn lambda_expr_nostruct() -> A {
    // rustc accepts this, but parser-lalr does not.
    match || A { a: 123 } {
        f => f()
    }
}

Return expressions (the two parsers agree):

struct A { a: i32 }
fn return_ambiguity_1() -> A {
    match A { a: 1 } { x => x } // rejected by rustc and parser-lalr
}
fn return_ambiguity_2() -> A {
    match return A { a: 1 } { _ => A { a: 1 } } // accepted by rustc and parser-lalr
}

The rustc and parser-lalr parsers disagree about whether a bare return expression can be cast:

fn cast_of_return() {
    // rustc rejects, parser-lalr accepts
    // error: expected identifier, found keyword `as`
    return as ();
    (return as ());

    return == (); // rustc accepts, parser-lalr accepts
    loop {
        continue as (); // rustc accepts, parser-lalr accepts
        continue == (); // rustc accepts, parser-lalr accepts
        break as ();    // rustc accepts, parser-lalr accepts
        break == ();    // rustc accepts, parser-lalr accepts
    };
}

Finally, I also noticed these two differences, which seem much less interesting to me. The grammar is probably just out-of-date or buggy:

lambda sometimes requires braces:

fn lambda_braces() {
    // parser-lalr accepts this, but rustc does not.  I think this is an
    // obvious bug in the parser-lalr.y grammar.  If there is a return type,
    // then curly braces are required.
    let _x = || -> i32 10;
}

proc is obsolete:

fn proc_syntax() {
    // parser-lalr also accepts this.  I think the proc syntax is obsolete, and
    // the {proc_expr, proc_expr_nostruct} non-terminals could be removed from
    // parser-lalr.y.
    let _x = proc() {};
}

closed time in 6 days

rprichard

issue commentrust-lang/rust

Parsing inconsistencies (lambda, proc, return)

parser-lalr has been removed in https://github.com/rust-lang/rust/pull/64896. Closing in favor of the work done by the grammar working group in https://github.com/rust-lang/wg-grammar/.

rprichard

comment created time in 6 days

push eventnrf-rs/nrf52-hal

Jonas Schievink

commit sha 6e364666e420094e91f0d32e7f124bf9d56f9cf4

Add a demo for the nRF5340

view details

push time in 6 days

PR opened nrf-rs/nrf91

Regenerate with svd2rust 0.17.0

It looks like Nordic added more things to the SVD since the last version of this crate was generated?

Also adds readme instructions and updates the repo link.

Looks like the version was already bumped in the manifest, so a new release can probably be published immediately after this?

+7540 -10555

0 comment

580 changed files

pr created time in 6 days

push eventnrf-rs/nrf91

Jonas Schievink

commit sha f2fd67c5ce2644abafc89b7e4e679874611cb47b

Update repo URL

view details

push time in 6 days

create barnchnrf-rs/nrf91

branch : update

created branch time in 6 days

fork jonas-schievink/nrf91

Device support crate for nRF9160/Alta

fork in 6 days

pull request commentnrf-rs/nrf52-hal

Update to svd2rust 0.16-based PACs

The nRF52 PACs are now at 0.9.0, which is generated by svd2rust 0.16 or 0.17 (they should be compatible). I don't have access to fix the nrf91 crate though.

JJJollyjim

comment created time in 6 days

created tagnrf-rs/nrf52840-pac

tagv0.9.0

Peripheral access API for nrf52840 microcontrollers

created time in 6 days

created tagnrf-rs/nrf52832-pac

tagv0.9.0

svd2rust bindings for the nrf52 (nrf52832) platform

created time in 6 days

issue commentrust-lang/rust

ICE in GeneratorSubsts / clippy

Does not happen on nightly-2020-02-17, so that confirms rust-lang/rust-clippy#5181 as the most likely candidate

Hirrolot

comment created time in 6 days

issue commentrust-lang/rust

ICE in GeneratorSubsts / clippy

Actually https://github.com/rust-lang/rust-clippy/pull/5181 looks like a more likely candidate. cc @daxpedda

Hirrolot

comment created time in 6 days

issue commentrust-lang/rust

ICE in GeneratorSubsts / clippy

Does not happen on nightly-2020-01-27, so might be caused by one of my PRs

Hirrolot

comment created time in 6 days

issue commentrust-lang/rust

ICE in GeneratorSubsts / clippy

Interesting backtrace parts:

  21: rustc::util::bug::bug_fmt
  22: rustc::ty::sty::GeneratorSubsts::split
  23: rustc::ty::sty::GeneratorSubsts::return_ty
  24: clippy_lints::doc::lint_for_missing_headers
  25: <clippy_lints::doc::DocMarkdown as rustc_lint::passes::LateLintPass>::check_impl_item
  26: <rustc_lint::late::LateLintPassObjects as rustc_lint::passes::LateLintPass>::check_impl_item
Hirrolot

comment created time in 6 days

issue commentrust-lang/rust

Feature request: From<&[T]> for NonNull<T>

Ah, I see

tspiteri

comment created time in 6 days

issue commentrust-lang/rust

Feature request: From<&[T]> for NonNull<T>

It implements <'a, T: ?Sized> From<&'a T>, so this should already work, right?

tspiteri

comment created time in 6 days

pull request commentstm32-rs/stm32l0xx-hal

Add an API for temporary GPIO reconfiguration

Yeah you can still do that, but it's not entirely backwards-compatible due to the new PinMode bounds.

Did you release a new version recently? I can't find one. If https://github.com/stm32-rs/stm32l0xx-hal/pull/72 is part of the next release then that's a breaking change anyways.

jonas-schievink

comment created time in 6 days

issue commentrust-lang/rust

const generic ICE on *stable*

Hmm, to my knowledge we've usually applied them whenever the feature in question was involved. For things that only occur on nightly, we have the additional requires-nightly label.

DutchGhost

comment created time in 6 days

push eventjonas-schievink/rubble

Travis CI User

commit sha db67527d8e3a493a67c1730e9fdce8b5307b1586

Update documentation

view details

push time in 6 days

issue commentrust-embedded/cortex-m-rt

Infinite backtrace, odd backtrace behavior and "corrupted stack?" in GDB

This should be fixed on the current nightly

japaric

comment created time in 6 days

startedCryZe/WindWakerDebugMenu

started time in 6 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

  //! Asynchronous values. +#[cfg(not(bootstrap))]+use crate::{+    ops::{Generator, GeneratorState},+    pin::Pin,+    ptr::NonNull,+    task::{Context, Poll},+};+ mod future; #[stable(feature = "futures_api", since = "1.36.0")] pub use self::future::Future;++/// This type is needed because:+///+/// a) Generators cannot implement `for<'a, 'b> Generator<&'a mut Context<'b>>`, so we need to pass+///    a raw pointer.+/// b) Raw pointers and `NonNull` aren't `Send` or `Sync`, so that would make every single future+///    non-Send/Sync as well, and we don't want that.+///+/// It also simplifies the HIR lowering of `.await`.+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[derive(Debug, Copy, Clone)]+pub struct ResumeTy(pub NonNull<Context<'static>>);++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Send for ResumeTy {}++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Sync for ResumeTy {}++/// Wrap a generator in a future.+///+/// This function returns a `GenFuture` underneath, but hides it in `impl Trait` to give+/// better error messages (`impl Future` rather than `GenFuture<[closure.....]>`).+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[inline]+pub fn from_generator<T>(gen: T) -> impl Future<Output = T::Return>+where+    T: Generator<ResumeTy, Yield = ()>+{+    #[derive(Copy, Clone, Debug, Eq, PartialEq, Ord, PartialOrd, Hash)]+    struct GenFuture<T: Generator<ResumeTy, Yield = ()>>(T);++    // We rely on the fact that async/await futures are immovable in order to create+    // self-referential borrows in the underlying generator.+    impl<T: Generator<ResumeTy, Yield = ()>> !Unpin for GenFuture<T> {}++    impl<T: Generator<ResumeTy, Yield = ()>> Future for GenFuture<T> {+        type Output = T::Return;+        fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {+            // Safety: Safe because we're !Unpin + !Drop mapping to a ?Unpin value+            let gen = unsafe { Pin::map_unchecked_mut(self, |s| &mut s.0) };++            // Resume the generator, turning the `&mut Context` into a `NonNull` raw pointer. The+            // `.await` lowering will safely cast that back to a `&mut Context`.+            match gen.resume(ResumeTy(NonNull::from(cx).cast::<Context<'static>>())) {

I'm not sure what poll_fn is in this example, it doesn't seem to exist.

My idea was that the only way to get the waker back out of the generator is via poll_with_context below, which only calls Future::poll. That only takes a &mut Context with a fully generic lifetime, so at that point the 'static lifetime gets demoted back to 'a.

jonas-schievink

comment created time in 6 days

issue commentrust-embedded/wg

Push foundational crates to 1.0

@arrowcircle Let's move that discussion somewhere else, I don't think this tracking issue is the right place. I don't disagree about the readme situation by the way, not sure why you think that. I just have limited time and energy to improve them.

jamesmunns

comment created time in 6 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

 symbols! {         target_has_atomic_load_store,         target_thread_local,         task,+        _task_context,

It's there because it suppresses the unused lint. I found that much easier than trying to create an #[allow(unused)] attribute in the HIR lowering code, but can do that if it's preferred.

jonas-schievink

comment created time in 7 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

  //! Asynchronous values. +#[cfg(not(bootstrap))]+use crate::{+    ops::{Generator, GeneratorState},+    pin::Pin,+    ptr::NonNull,+    task::{Context, Poll},+};+ mod future; #[stable(feature = "futures_api", since = "1.36.0")] pub use self::future::Future;++/// This type is needed because:+///+/// a) Generators cannot implement `for<'a, 'b> Generator<&'a mut Context<'b>>`, so we need to pass

Generator literals don't support that at the moment, see https://github.com/rust-lang/rust/issues/68923

jonas-schievink

comment created time in 7 days

push eventjonas-schievink/rust

Jonas Schievink

commit sha fc2702c96c0db560f55683e4cd33075c054ed062

Add regression test

view details

push time in 7 days

Pull request review commentrust-lang/rust

Fix generator miscompilations

 macro_rules! make_mir_visitor {                         resume_arg,                         drop: _,                     } => {+                        self.visit_operand(value, source_location);

It doesn't seem to matter from what I've seen, but it aligns the order of Yield with the one for Call. That seems less surprising to me.

jonas-schievink

comment created time in 7 days

issue commentrust-lang/rust

Using a String as a generator resume argument causes a segfault

@cynecx That's a great start! I've opened a fix (+ cleanup + more docs) based on the same idea in https://github.com/rust-lang/rust/pull/69302

shepmaster

comment created time in 7 days

PR opened rust-lang/rust

Fix generator miscompilations

Fixes https://github.com/rust-lang/rust/issues/69039

r? @Zoxc

+107 -22

0 comment

5 changed files

pr created time in 7 days

create barnchjonas-schievink/rust

branch : yield-needs-storage

created branch time in 7 days

delete branch jonas-schievink/rust

delete branch : thumb-fp

delete time in 7 days

issue commentrust-lang/rust

Generators can't have HRTBs on resume argument.

No worries!

kyren

comment created time in 7 days

issue closedrust-lang/rust

Generators can't have HRTBs on resume argument.

It seems as though it's not possible currently to write a generator that satisfies this bound:

fn accept<G: for<'a> Generator<&'a ()>>(g: G) {}

Trying something like this:

accept(|r| {
    let r = yield;
});

Gives:

5  | fn accept<G>(g: G)
   |    ------
6  | where
7  |     G: for<'a> Generator<&'a ()>,
   |        ------------------------- required by this bound in `accept`
...
12 |     accept(|r| {
   |     ^^^^^^
   |     |
   |     expected signature of `for<'a> fn(&'a ()) -> _`
   |     found signature of `fn(_) -> _`

I realize that generators are very unstable right now so I doubt this is high priority, but hopefully something like this could work eventually? I think it might be useful for generators to accept something like a temporary buffer as a resume argument that should only be valid until the next call to yield.

Incidentally, I didn't run into this problem legitimately, I ran into it trying to abuse generators to enable automatic garbage collection ala https://github.com/kyren/gc-arena, but I think that there are also valid reasons to want this to work as well 😛

closed time in 7 days

kyren

issue commentrust-lang/rust

Generators can't have HRTBs on resume argument.

Yeah, this would be nice to have. This seems like a duplicate of https://github.com/rust-lang/rust/issues/68923 though, so closing in favor of that.

kyren

comment created time in 7 days

pull request commentrust-lang/rust

Use generator resume arguments in the async/await lowering

@CryZe I've started to write a test that should provide an answer to that, but I also plan to look into #69039 regardless. I hope to find some time to finish this off in the next couple of weeks.

jonas-schievink

comment created time in 7 days

issue commentrust-embedded/wg

Push foundational crates to 1.0

I don't really have much to do with either of those crates, but CI badges are at best useless for rust-embedded crates (CI always passes since we use bors), and at worst misleading (the link always points to the state of master, even when on a maintenance branch), so I don't think we should add them.

jamesmunns

comment created time in 7 days

push eventjonas-schievink/rubble

Travis CI User

commit sha a37a8fc7deca10a77d4229ec503995b576f19d3b

Update documentation

view details

push time in 7 days

pull request commentrust-lang/rust

prepare_relocation_copy: check for integer overflow in the multiplica…

with_capacity is just an optimization that preallocates memory. It doesn't really matter much if this overflows, since the loop below would simply run out of memory (which might have already happened at that point).

saaramar

comment created time in 7 days

issue closedrust-lang/rust

Not optimized codegen with NonZeroI32

This code:

use std::num::NonZeroI32;

pub fn div(a: i16, b: NonZeroI32) -> (i32, i32) {
    let a = a as i32;
    let b = b.get();
    (a / b, a % b)
}

should have no possibility of panicking by "divide by zero", however, it seems related check and panicking code is still generated.

closed time in 7 days

crlf0710

issue commentrust-lang/rust

Not optimized codegen with NonZeroI32

Closing in favor of https://github.com/rust-lang/rust/issues/49572

crlf0710

comment created time in 7 days

pull request commentrust-lang/rust

Querify object_safety_violations.

The is_object_safe query can probably be removed then, and replaced with a method on TyCtxt

cjgillot

comment created time in 8 days

issue closedrust-embedded/wg

Agenda for 2020-02-18 meeting

8-9 PM CET (Berlin time) on #rust-embedded:matrix.org

Public Google calendar that includes these weekly meetings

Agenda

  • Move smoltcp to rust-embedded?
  • https://github.com/rust-embedded/cortex-m/issues/195 – UB in inline-asm implementation of cortex_m::asm::delay. Audit all inline asm in the wg for similar issues?
  • Multi-Core RFCs status update
    • https://github.com/rust-embedded/wg/pull/388
    • https://github.com/rust-embedded/wg/pull/419
  • Which MSRV policy should we use for core crates like r0?

Announcements:

  • (your announcement here)

This meeting is open for anyone to attend. If you'd like to bring up any issue / topic related to embedded Rust leave a comment in this issue so we can add it to the agenda.

closed time in 8 days

jonas-schievink

issue closedrust-embedded/r0

Review against the API guidelines

https://rust-lang.github.io/api-guidelines/

Part of #9. This should be pretty easy since after #11 the API consists of only 2 functions and a trait.

Checklist:

  • Naming (crate aligns with Rust naming conventions)
    • [x] Casing conforms to RFC 430 ([C-CASE])
    • [x] Ad-hoc conversions follow as_, to_, into_ conventions ([C-CONV])
    • [x] Getter names follow Rust convention ([C-GETTER])
    • [x] Methods on collections that produce iterators follow iter, iter_mut, into_iter ([C-ITER])
    • [x] Iterator type names match the methods that produce them ([C-ITER-TY])
    • [x] Feature names are free of placeholder words ([C-FEATURE])
    • [x] Names use a consistent word order ([C-WORD-ORDER])
  • Interoperability (crate interacts nicely with other library functionality)
    • [x] Types eagerly implement common traits ([C-COMMON-TRAITS])
      • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Display, Default
    • [x] Conversions use the standard traits From, AsRef, AsMut ([C-CONV-TRAITS])
    • [x] Collections implement FromIterator and Extend ([C-COLLECT])
    • [x] Data structures implement Serde's Serialize, Deserialize ([C-SERDE])
    • [x] Types are Send and Sync where possible ([C-SEND-SYNC])
    • [x] Error types are meaningful and well-behaved ([C-GOOD-ERR])
    • [x] Binary number types provide Hex, Octal, Binary formatting ([C-NUM-FMT])
    • [x] Generic reader/writer functions take R: Read and W: Write by value ([C-RW-VALUE])
  • Macros (crate presents well-behaved macros)
    • [x] Input syntax is evocative of the output ([C-EVOCATIVE])
    • [x] Macros compose well with attributes ([C-MACRO-ATTR])
    • [x] Item macros work anywhere that items are allowed ([C-ANYWHERE])
    • [x] Item macros support visibility specifiers ([C-MACRO-VIS])
    • [x] Type fragments are flexible ([C-MACRO-TY])
  • Documentation (crate is abundantly documented)
    • [x] Crate level docs are thorough and include examples ([C-CRATE-DOC])
    • [ ] All items have a rustdoc example ([C-EXAMPLE])
    • [x] Examples use ?, not try!, not unwrap ([C-QUESTION-MARK])
    • [x] Function docs include error, panic, and safety considerations ([C-FAILURE])
    • [x] Prose contains hyperlinks to relevant things ([C-LINK])
    • [x] Cargo.toml includes all common metadata ([C-METADATA])
      • authors, description, license, homepage, documentation, repository, readme, keywords, categories
    • [x] Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" ([C-HTML-ROOT])
    • [x] Release notes document all significant changes ([C-RELNOTES])
    • [x] Rustdoc does not show unhelpful implementation details ([C-HIDDEN])
  • Predictability (crate enables legible code that acts how it looks)
    • [x] Smart pointers do not add inherent methods ([C-SMART-PTR])
    • [x] Conversions live on the most specific type involved ([C-CONV-SPECIFIC])
    • [x] Functions with a clear receiver are methods ([C-METHOD])
    • [x] Functions do not take out-parameters ([C-NO-OUT])
    • [x] Operator overloads are unsurprising ([C-OVERLOAD])
    • [x] Only smart pointers implement Deref and DerefMut ([C-DEREF])
    • [x] Constructors are static, inherent methods ([C-CTOR])
  • Flexibility (crate supports diverse real-world use cases)
    • [x] Functions expose intermediate results to avoid duplicate work ([C-INTERMEDIATE])
    • [x] Caller decides where to copy and place data ([C-CALLER-CONTROL])
    • [x] Functions minimize assumptions about parameters by using generics ([C-GENERIC])
    • [x] Traits are object-safe if they may be useful as a trait object ([C-OBJECT])
  • Type safety (crate leverages the type system effectively)
    • [x] Newtypes provide static distinctions ([C-NEWTYPE])
    • [x] Arguments convey meaning through types, not bool or Option ([C-CUSTOM-TYPE])
    • [x] Types for a set of flags are bitflags, not enums ([C-BITFLAG])
    • [x] Builders enable construction of complex values ([C-BUILDER])
  • Dependability (crate is unlikely to do the wrong thing)
    • [ ] Functions validate their arguments ([C-VALIDATE])
    • [x] Destructors never fail ([C-DTOR-FAIL])
    • [x] Destructors that may block have alternatives ([C-DTOR-BLOCK])
  • Debuggability (crate is conducive to easy debugging)
    • [x] All public types implement Debug ([C-DEBUG])
    • [x] Debug representation is never empty ([C-DEBUG-NONEMPTY])
  • Future proofing (crate is free to improve without breaking users' code)
    • [x] Sealed traits protect against downstream implementations ([C-SEALED])
    • [x] Structs have private fields ([C-STRUCT-PRIVATE])
    • [x] Newtypes encapsulate implementation details ([C-NEWTYPE-HIDE])
    • [x] Data structures do not duplicate derived trait bounds ([C-STRUCT-BOUNDS])
  • Necessities (to whom they matter, they really matter)
    • [x] Public dependencies of a stable crate are stable ([C-STABLE])
    • [x] Crate and its dependencies have a permissive license ([C-PERMISSIVE])

closed time in 8 days

jonas-schievink

issue commentrust-embedded/r0

Review against the API guidelines

Yeah, nobody in the meeting had any objections to this, so closing.

jonas-schievink

comment created time in 8 days

issue closedrust-lang/rust

Cross compiling from x64 Linux to SPARC Solaris

It has been suggested to me that all that is needed to produce a rust compiler for SPARC Solaris is

x.py --target sparcv9-sun-solaris

However, this is getting me nowhere:

michele@michele-VirtualBox:~/rust$ ./x.py --target sparcv9-sun-solaris
Updating only changed submodules
Submodules updated in 0.04 seconds
    Finished dev [unoptimized] target(s) in 0.16s
Usage: x.py <subcommand> [options] [<paths>...]
...
failed to run: /home/michele/rust/build/bootstrap/debug/bootstrap --target sparcv9-sun-solaris
Build completed unsuccessfully in 0:00:00

I have already done 

$ rustup target add sparcv9-sun-solaris
$ ./configure --host=sparcv9-sun-solaris

This is in Ubuntu x64. What am I doing wrong?

closed time in 8 days

Michele31415
more