@j`ey I don't think this is going to work :/

theemathas: I have no idea about codeblocks

tbh I thought most of the IDEs were just a UI over gdb

Ehhh…

I guess.

BTW, is gdb supposed to break on panic?

(I'm not sure if the warnings meant that gdb isn't going to work)

breakpoint on rust_begin_unwind

j`ey: Doesn't work

I can set a breakpoint at main though

rbreak panic

Although it says that main doesn't have line number information

theemathas: `main` is not the `main` you write in Rust IIRC

_habnabit: I'm trying that and it's very weird

insaneinside: Whoops

theemathas, weird?

_habnabit: "Thread 2 hit Breakpoint 8, __rde_realloc () at liballoc_jemalloc/lib.rs:162"

_habnabit: bt yields: #0 __rde_realloc () at liballoc_jemalloc/lib.rs:162 #1 0x00007ffeefbff728 in ?? () #2 0x0000000000000005 in ?? () #3 0x00007ffeefbff700 in ?? () #4 0x00000001000a4fe6 in __rde_usable_size () at liballoc_jemalloc/lib.rs:152 Backtrace stopped: previous frame inner to this frame (corrupt stack?)

neat

(But with newlines)

_habnabit: I actually fixed it by wrapping all (also UnsafeCell) with a Mutex. I need UnsafeCell to trick the compiler with the lifetime thing. Now everything works. :)

I tried breaking at cargo_clippy::main

"Single stepping until exit from function _ZN12cargo_clippy4main17h71690b95c701d32aE, which has no line number information."

D:

Something's definitely wrong here.

zucchini, you don't need the UnsafeCell; the Mutex is already providing you interior mutability

yeah I know but without unsafe cell it didnt work

due to the lifetime problem

you might as well have casted to mut pointer and back

zucchini, sure, and i said you can already unsafely erase that lifetime without UnsafeCell

with UnsafeCell I have the get() method that returns a raw-pointer that can trick the lifetime checker

zucchini, &str coerces to *const str

oh

i will give it a shot :)

you don't need UnsafeCell to get a raw pointer. I'm not sure one ever needs UnsafeCell.

XD

albel727, you do if you're implementing Mutex

well I initially copied the code from "cargo-tally"

and Cell

_habnabit zucchini insaneinside: help meeeeee TT_TT

but that's not what most people need to do.

theemathas: well the problem is that cargo_clippy isn't being compiled in debug mode I think?

insaneinside: the command I used to run rust-gdb was "rust-gdb ../target/debug/cargo-clippy"

I think that's debug mode

zucchini, but, doing work like this (a whole mutex lock!) in a Deref impl strikes me as strange

theemathas: yeah it ought to be.. but that's a binary, yes? I assume the binary's source has `extern crate cargo_clippy;` in it somewhere?

I wonder if the actual lib is *not* being compiled with debuginfo

insaneinside: The source has "extern crate clippy_lints" somewhere, I think.

since gdb complains about corrupt stack, I wonder if it's actually a real bug with stack overflow, and reverse debugging can undamage the stack.

"reverse debugging"? Insert Soviet Russia joke here.

hey, it's a thing in gdb.

albel727: I inserted "panic!()" and attempted to break on that.

It's not a stack overflow bug.

Oh.

The "rbreak panic" thing caused a SIGSEGV

D:

I'm getting a segfault in rust D:

theemathas: unsafe code?

I'm gonna assume that gdb messed around jemalloc somehow

never happened to me

though I never did break on panic

well, one can try to switch the allocator to system anyway.

It segfaulted from std::sys_common::backtrace::demangle

I'm gonna assume that's not my fault.

The main problem is that I can't break on a function in an extern crate.

And I can't run the code line-by-line when I break on cargo_clippy::main

TT_TT

Maybe I should just do println!() debugging

I've got my first real rust app together (trivial CRUD with rocket and diesel), and the debug build runs fine, but the release build exits immediately. Anyone have any advice on diagnosing this?

My main() is just a call to setup and launch rocket.

It doesn't appear to be crashing; it's exiting successfully.

Tene: Are you seeing any log messages?

No output at all.

Which version of Rocket?

println time!

Rocket doesn't do anything differently on debug/production.

debug/release*

not even run quicker? :P

Heh

Functionally*

:)

rocket 0.3.6

j`ey: Yeah. println! time.

Tene, my guess is you're running the wrong binary

theemathas: Don't you mean dbg!(expr) time?

centril: What?

Tene: Is your code up somewhere?

That's really weird.

Are you running it with `cargo run --release`?

centril: lol

!rfc 2173 @ theemathas

!crate dbg

I just added a println!() before and after the rocket call, and those aren't running either. It's got to be something weird in my environment.

Yeah.

centril: Thanks

Tene, what's the mtime on the binary you're running

theemathas: =)

Tene: comment out evrything but println

Tene: `cargo clean` and rebuild

Tene: And `rustup update`

might as well do just that

and turn pc off and on

Lol

(because the new compiler is going to be rebuilding everything anyway)

and turn your lights off and on. put your head on your pillow in between. stay that way for 8 hours or more.

centril: I don't think dbg! is going to be of much use right now though.

albel727: lol

theemathas: granted =)

I'm building in the rustlang/rust:nightly docker container, on a windows host. I've done clean builds here.

theemathas: you can introduce the crate for the rfc as a temporary dependency and use it instead of println! if that helps you

Or, at least I thought I was. Time to clean everything.

centril: I'm just gonna do printlns

:D

but do you actually use cargo run --release

or how do you run your binary?

I was running it with cargo run --release, although I've just edited it in the running container and rebuilt, and it's working fine now apparently.

gremlins

This is my first time trying any real development on Windows. I'm not sure how much of my pain here has been just due to unfamiliarity.

Tene: welcome to the club; membership brings a lot of pain.

Tene: it's a PITA

even worse outside of rust

emerentius: Haskell development is not so bad on Win tho =)

relative to haskell itself windows seems easy

kidding, I don't actually know haskell

hey guys im doing "cargo build --target i686-unknown-linux-gnu --release" on a project with reqwest support, but it's complaining about not finding any openssl libs. also if I execute my previous native binary on another machine i get missing lib error. any way to statically link it?

badmann: I would suggest trying to build it as musl.

badmann: musl will have it statically linked.

Aaronepower: doesn't that deal only with C std libraries?

maybe sfackler knows?

i think the issue is one of the dependencies is dynamically compiling openssl

badmann: I don't think so?

pastebin.com/0LcDbLy8 here are all the dynamic libs in my exe

hi, if i mark an enum, MyEnum, with "#[repr(u32)]" and then i expose a fn via FFI with a signature "my_fn(my_enum: MyEnum)", and the C header for it is "my_fn(uint32_t my_enum)", will that work?

compiling with musl fails, since it says "Could not find directory of OpenSSL installation..."

badmann: Do you not have the openssl env variables set?

no

sfackler/rust-openssl #183 using these flags i get "error: could not find native static library `ssl`, perhaps an -L flag is missing?"

github.com/sfackler/rust-openssl this seems to suggest only setting a variable is sufficient, but unfortunately it does not work for OPENSSL_STATIC=yes

Does anyone know why this really short code doesn't compile? play.rust-lang.org/?gist=d509c2ab1a…58d9bf70770b7c12a100&version=stable

hey

I need to put a value in some kind of a box so that I can “take it out”, move it to a function (that returns the same type), and get that result and put it in the box again

theemathas: Good question!

is there such a thing despites raw pointers?

phaazon: Option

Box doesn’t have a “map”-like function

Icefoz: I ran into this while troubleshooting a problem on #rust-beginners

sfackler: what do you mean?

Option<T> is a type that will let you do that

well, I’m “sure” I have someting

something

I don’t want to pattern match on Some(_)

something*

theemathas: It works when you remove the type annotation from x and let it figure it out on its own...

what happens if your function panics?

my current version is to do something with ptr::null_mut() + deref_mut + ptr::read + deref_mut back again

phaazon, why does it have to be the same box?

sfackler: well, having to pattern match against None => unreachable!() is meh

_habnabit: it’s in a FnMut closure

phaazon, how about &mut T?

Icefoz: Odd

muvlon: you cannot move out of that

it sounds like you just want to borrow your thing to the function

phaazon: crates.io/crates/take_mut is an option

but not the caveats around panics

muvlon: no, the closure has ownership over it

phaazon, then why do you have to move it?

theemathas: That's a very odd case. I think it's having problems figuring out that the returned type's lifetime is connected to the input type's.

because I must pass it to a function that needs to move it

*note

phaazon, ah, it needs ownership

phaazon, wait, so, does it just want to have an FnMut closure moved into it?

theemathas: It works if I define a type for foo as well.

Icefoz: I actually ran into that before.

_habnabit: I’ll recap

Icefoz: You cannot have a closure with generic lifetimes.

phaazon, maybe some example code

Icefoz: What about this one? play.rust-lang.org/?gist=a539eb58d5…a4b20df65a1812ea81f8&version=stable

I have an FnMut closure that needs to take ownership of a value (because that FnMut closure will call a Fn(A, _, _, _) -> A function

I just need to find a way to retrieve the value

give it to the Fn function

and have it back in the FnMut

so that next time I call the FnMut object, the value is changed

is it clear enough now? :)

phaazon, would still like example code

I’ll show you some code yeah

Does anybody know why this short code doesn't compile? play.rust-lang.org/?gist=6fea7fd9d8…7c25bb6ffa7b3e708445&version=stable

theemathas: Okay, I'm stumped.

Haha

theemathas: It does not compile to prevent you from having 2 mutable references to foo

stephaneyfx: How?

theemathas: If it did compile, you could call f twice to get 2 such mutable refs

stephaneyfx: FnOnce are a thing though

theemathas, trying to get implement reborrowing yourself?

emerentius: Ran into this while troubleshooting someone else's code on #rust-beginners

ah, not even re

not even what?

yeah, I’ll use an Option

the pointer stuff is too boring.

stephaneyfx: Also, commenting out the "f()" line gets rid of the error.

not even reborrowing because foo isn't a borrow yet

theemathas: Good points

I believe the issue is that you're creating a temporary &mut

emerentius: Nope play.rust-lang.org/?gist=e995ae7160…39f318c18c8f71a905cb&version=stable

tldr: closures in rust are useless, unless passed as function arguments

lol

albel727: that's not exactly untrue :P

talchas: I was about to say the same :P

closure inference with lifetimes is Hard, because it's basically rank-2 inference

wtf play.rust-lang.org/?gist=34d20cbfeb…5280d420dc1c0ff5d642&version=stable

albel727 talchas scottmcm ^

so iirc rust never tries to infer a for<'a> without a signature, and there's some hacks to try to make things useful in some cases without

theemathas: This works too... play.rust-lang.org/?gist=ddb290ecf9…b522b20d064e3ea7e1fd&version=stable

theemathas: and not only what I just said, it only looks for the signature within like the statement or something

stephaneyfx: WHYYYYYYYYY

Why is that "let bar = bar" required???

theemathas: so the `move` picks up the right thing

ok, it should work

I used Option::take

thanks peeps

scottmcm: It actually works without `move`

wtf play.rust-lang.org/?gist=fc96739242…b4166a7c711bc106d104&version=stable

theemathas: the former forcibly moves `bar`, the latter reborrows it

SpaceManiac: Why?

SpaceManiac: oddly move || go({foo}) also seems to reborrow

oh hm

I'm tempted to file a bug now

talchas, can you post link? I was trying to get that to do it

go({bar}) doesn't work so it's not strictly a move issue

emerentius: I'm saying that it doesn't work

which is odd, because in most cases that's a move just like let bar = bar;

err yeah, I meant move

(fn id<T>(x: T) -> T { x } and foo(id(x)) also fails here when it usually works)

in short: define the signature you want for your closure, every time

(it's too bad let x: impl Trait; was deferred)

talchas: What?

Should I file a bug?

it's known

theemathas: fn fix_closure<F:FnOnce()-> &mut Foo>(x: F) -> F { x } ... let f = fix_closure(go(bar));

Huh?

should work

and yeah, it's known that closure inference just falls over in weird ways all the time

talchas, it was failing because it tried to make FnMut out of it?

Oh

The "you cannot make a closure generic over lifetimes" thing

Wait, no

emerentius: that might be part of it sometimes, mostly it's "you can't make a closure generic over lifetimes without a signature"

I'm confused now

I ran into it before

theemathas: the F signature I wrote there is the same as in your call() with the explicit 'a

actually, wait no

it's totally not

and maybe mine won't work and you need yours for this

I'm confused

yeah, I forgot that here you'd need the explicit 'a

talchas: So why did we need "let bar = bar"?

theemathas: I'm really not sure why there

:closure inference:

I'm really tempted to file a bug

feel free, I just doubt it'll go anywhere

the let bar = bar thing seemed particularly odd

hey guys, does Rust have the concept of a property? or it's just functions all the way?

sssilver: No such thing as a property.

Just methods.

sfackler/rust-openssl #604 i finally figured it out. it looks like the environment variables are treated in an inconsistent fashion across operating systems, and in order for static to work a few others must be set (only on linux)...

talchas: Possibly relevant issue I filed a long time ago rust-lang/rust #22557

That one is actually probably not relevant

properties are nice though, they add important semantics and readability

I'm sure someone has suggested this before

Sometimes they're nice; often they're a waste of time; occasionally (especially when writable) they're extra confusing

sssilver: A quick google search yields 3 instances of people suggesting that.

Rust generally tries not to have things unless they're particularly helpful.

programming language communities are fascinating. For every feature there's always a million people who will vehemently oppose implementing it

I was reading a thread on golang mailing list the other day where someone suggested the idea that enums are good and useful

opposition is the correct default response, sssilver

and a million people attacking the poor soul about how enums are useless

a language with all possible features would be terrible

and how "I have been programming for X years and never once needed an enum in my life"

I was bewildered that there are so many real programmers who never felt like they needed an enum

I think part of the reason is that the full usefulness of enums doesn't become apparent until you have algebraic datatypes and compiler support for checking that you've covered every case

which then sort of requires pattern matching

scottmcm: "a language with all possible features" aka c++ haha

many of these features seem unimpressive in isolation

sssilver: There are a ton of features that C++ doesn't have.

sssilver: For example, green threads and garbage collection

sssilver: neither of which is fundamentally bad, but would both be poor choices for C++

ehh you can define a garbage collector, and allocate all the memory through it

sssilver: and if you look at how go has apparently decided to do error handling, I'm not surprised it doesn't want sum types, since doing them properly would lead to changing everything that does error handling

you're saying like it's a bad thing -- error handling in go is super clumsy imo

Oh, I don't like Go at all. But not having sum types is consistent with their past choices.

I'm all for returning a result type, but most go error handling in the wild makes me cringe

And I applaud Go for sticking carefully to its goals.

in particular here, simplicity and only one way to do anything

even if it's an objectively bad way :P

<3 talchas

also I don't understand how they can state they're statically typed and then go on to say

> func ResolveIPAddr(net, addr string) (*IPAddr, os.Error) where net is one of "ip", "ip4" or "ip6".

(this is a stdlib function)

but anyway, this is pretty offtopic at this point

yeah, properties would be nice :)

sssilver: more concretely, In C# I usually see properties overused, with everything always being a property, even when doing so provides no advantage

scottmcm: properties are a semantic thing. IMO Swift gets it right, at least as far as the standard library and common popular libs

And things like `whatever.Length = 4;` is usually more confusing than helpful, in my experience

"semantic"? They seem fully syntactic, to me -- just omitting `()`s

I disagree; to me it's more reasonable then whatever.setLength(4)

scottmcm: yeah the semantics is what defines the choice of a property vs a function, that's what I mean

perhaps I'm not using the right word

Eng is not my native language

sssilver: see, I think if there's any useful invariant involved, then different methods like `.truncate(n)` or `.resize(n, x)` or `unsafe .set_len(n)` (see Vec) are better

sssilver: and if there isn't an invariant, then it should just be a field :P

:) I see your viewpoint

getters though -- those are less ambiguous

talchas: Filed the issue rust-lang/rust #47478

anyway, great chatting -- gotta walk to the hotel. Have a good one!

sssilver: sure, but then it's just whether you can omit the `()`s, which is convenient, but clearly not necessary

sssilver|away: and in Rust might have implications on what is held borrowed, for example.

Manishearth: I don't want to derail your RFC more; so I'll reply here instead =)

Manishearth: I'm not sure which you are referring to with "the proposals"

centril: theres an ongoing internals thread about this

Manishearth: sure; I've participated in that one =)

plus, historically this has always been about a generic framework

it doesnt focus on testing . nor does it constrain the output

Manishearth: What I am saying is that it shouldn't be a generic framework, as testing and benchmarks provide so fundamentally different forms of outputs

and trying to fit them into one will just make both worse, I think

could be wrong of course =)

centril: the framework doesnt constrain outputs at all

centril: the focus is on making it possiblr to have cargo orchestrate the build

Manishearth: Are we talking about the formatters of the output or the test runners producing the outputs?

testing, bench, cargo fuzz, examples -- they all need a way to take tagged code from foo/ or src/ amd do stuff with it getting all the right args from cargo

centril: what

the frameworl literally lets you generate arbitrary harness code. output whatever you want

Manishearth: I thought we were talking about this: github.com/Gilnaa/rust/blob/dcd49b9…b6af92/src/libtest/lib.rs#L216-L221

thats an impl detail of the builtin runner

it doesnt impose anything on other harnesses

yeah, that wouldn't be mandated by libtest 2.0, whatever it ends up being

again, the proposals just give you a way to do codegen

yup, basically

jonhoo: btw might flesh my proposal out into an erfc, are there any missing/unaddressed concerns?

its a bit different from yours but not in any major ay i think

aside from the fact that mine focuses on the cargo side

which i think is really the core of this feature

centril: if libtedt 2.0 provides anything it would be proc macro tools for collecting attributes etc

sorry for a dumb question, but rust makes me feel dumb sometimes. Can I (reasonable w/o extern crate) modify orig vec from a slice? gist.github.com/4fa2749a780f1b9c66440191bfc29739

not TestDesc

I think the biggest restriction of your proposed design is that I don't think having an "iterate over things with this annotation" is sufficient for test frameworks that are sufficiently different from xUnit-style specifications

but I might be wrong and not have thought enough about your design

thiygh it may eventually also provide tools for various formatters but you can use your own

jonhoo, Manishearth: that's fine - but if we want custom test runners to output their final results and events into a machine readable format that supports multiple different output formats, test runners need some type definitions or traits to provide values which can then be serialized to human readable strings, json, xml, <insert your format>

jonhoo wait, thags not a constraint of my system?

values for*

jonhoo: mine lets you run arbitrary proc macro code, and may have helpers for collecting attrs/etc

wait maybe i wrote the original one that way

in which case my bad

centril: a test runner is free to use println!() *instead* of outputting through a standardized interface if its properties are such that they don't fit well with standardized formats

PappyFlaps: play.rust-lang.org/?gist=482ced15ec…09a26b4346a570860000&version=stable

"collect all attrs" and "remove main()" are supposed to

centril: I don't think we want to design that interface to take basically whatever, because then the formatters will not be able to do anything useful

jonhoo: it may be free to use println!(), but it shouldnt...?

be helper apis that you can use if tou want

PappyFlapps*: play.rust-lang.org/?gist=482ced15ec…09a26b4346a570860000&version=stable

centril: for example, consider the case of the output formatter being TAP

jonhoo imo the interface shouldnt be stabilized

jonhoo however exposing libtests formstter is good

Manishearth: I think it's useful to have at least some very common events that are shared by most consumers of test output

jonhoo: testanything.org ?

sorry, i mean that there shouldnt be pressure to use the interface

my bad

ah, yes, agreed

as in, it would eb a convention basically

Manishearth: I guess my observation is that it's not sufficient to just be able to iterate over functions

cobrand : ah i see, create a scope ... thanks

Manishearth: there are good arguments for some test runner wanting to annotate, say, a module, or a var

yeah

but apart from that I think what you propose could work just fine

jonhoo in ehich case they have to build their own proc macro stuff for that

yes, but they won't be able to do that without compiler support

the "find test functions" would be a helper api

because there needs to be a way to *find* the annotated things

which is basically what my proposal is

jonhoo sure they would. its a prpc macro

so I think some combination of the two is the way to go

prpc?

mine gives you a proc macro running on the entire crate

*proc

ah

im on ssh and a phone

hehe, np

jonhoo: The runner being able to classify itself and provide extra data in the form of some object-notation string isn't whatever

centril: I don't see why there's any advantage to that though?

mine is just a proc macro that takes in the lib and outputs the binary

what would a TAP formatter do with that information?

within this framewoek it can have helpers that do some of the work

Manishearth: yes, but we don't want to have test runners need to parse the entire crate? that's seems super inconvenient, even if it is flexible

also, relatedly, this is basically what matklad proposed in the last meeting I think

a whole-crate macro

jonhoo: The TAP formatter can ignore it... this is the first I've heard of TAP tho..

The alternative is that the runner can't provide it at all other than with println or logging to a file

centril: I think the very narrow interface that we'd encourage would just have "success"/"failure" type things, and nothing else, because it's most likely that most formatter will be able to do something useful with that

anything else there isn't really any advantage to forcing through the same interface

jonhoo: The most common formatter will probably be JSON and human readable output

it's not about the "wrapping"

like whether it's JSON or human readable

but about *standardized* output

the human readable format can just dump the extra JSON if you do something like --verbose

or --extra

TAP for example is a protocol that is supported by lots of IDEs + other tools for consuming test output

and there are others

and having "extra" information isn't something that is a part of that

there's nothing useful for the formatter to do

and if you're *not* conforming to a standard, then println! is fine, right?

the interface is solely about making it easy to conform to a wide range of testing format standards

jonhoo: println! has bunch of concurrency and readability issues...

so that most runners will work with most standardized formats

centril: ah, but that the runner could manage internally

by using a logger or a lock or whatever

Manishearth: I think a separate concern I have with your proposal, but that may not be warranted, is that it's so broad that it'll be hard to then standardize anything about testing. such as a test output formatter interface. but maybe that's a silly objection

jonhoo: Is the set of #[my_runner::test]s handled by the runner, or does cargo handle executing each #[my_runner::test] by spawning the runner, etc.?

jonhoo: well your concern here is my concern also...

Manishearth: I also worry that because it's such a "large" feature at that point, it'll be hard to get buy in for implementing it in a reasonable timeframe

Manishearth: I'd almost prefer something more scoped at first, and then see if for example your proposal could later be used to *implement* that first scoped step down the line

centril: in my proposal (and in Manishearth's), cargo basically doesn't handle anything

all it really does is pick which main() to run

and each main() is generated by the test runner, and it can do whatever it wants to

jonhoo: but is that main() for each #[my_runner::test] fn my_important_test() {..} or one main() {..} for __all__ the #[my_runner::test] in the crate?

there's a single main() that's managed by the runner

it decides what tests it wants to run from that main

the test runner decides the entire contents of main

which may include spawning threads, may include importing all the tests and running them sequentially, may include forking off into different processes

it's entirely up to the test runner

the annotations are essentially just for the runner to help find tests and other functions/bits

sec, reading your proposal again

hum, I have a crate which is a lib, whenever I try to "cargo test" it says "error[E0601]: main function not found"

is this normal?

do you have a file called src/main.rs by any chance?

nope

just a src/lib.rs, I have a few main in examples/ but that's it

It worked like 10 minutes before that, and now i get this

oh that's because one of my files in examples/ is empty, so it doesn't have a main

jonhoo: "Note that this would select the indicated test runner for the entire crate." <-- I find this bit problematic... What if I want to use unit tests some places and proptest some other places and something else for integration testing..?

jonhoo: also; why not a TestEvent::Ignored(String) variant?

centril: see the parenthetical -- cargo already compiles integration tests as separate crates

so while you could only use on test runner inside src/

you could use different test runners in different test files under tests/ for example

jonhoo: I read the parenthetical, and I don't think it is sufficient... I want to use different runners inside src/ for each module

it's true that it's a limitation of that design, but it's not quite as big as it may seem

unit tests for one module, property based for another

centril: that will be very tricky with *any* design

because there is only one main

though I think *maybe* you could do it with Manishearth's

but you would need to compile src/ multiple times

there's also subcrating, though that may be a bit extreme

as for the TestEvent enum, I haven't fleshed it out at all -- that was just a very brief example to show what I was thinking

jonhoo: you could have multiple mains, but call different runners one after the other and use different attributes such as #[proptest::test], #[test], #[othertest::test]

that post is not anywhere close to an RFC -- it was more a proposal for how we might go about this

jonhoo: I understand that fully ;)

centril: no, there can be only one main() in a program. in theory the compiler could generate a main that calls out to lots of other test runner functions (like my proposed main() already does to TestRunner::run)

the only issue is how the crate author specifies the test runner

that's the hard part in a sense

finding a nice API for that that's still feasible to implement

jonhoo: what I meant by multiple mains is that you have one real main that just call other "mains"

obviously an executable program can only have one entry point

yes, that's what my design already does. except it's limited to calling just one

because it's not clear how you even declare that there are many

in theory it should be doable -- you'd just have to find a nice interface for it

jonhoo: I think #[proptest] having registering to one place and #[test] registering to another is nice

jonhoo: you'd have to complicate things a bit to have a list of runners, and for each runner registered_test_components!(runner)

well, registered_test_components! is one thing -- in theory that should just work as already proposed

though you do run into issues like what if two test runners declare the same keywords/attributes?

but the bigger issue is how you add a test runner in the first place. you can't just extern crate it with an annotation. it needs to be "selected" somewhere

jonhoo: a hard error =) and the runners ecosystem will have to be nice and not be greedy about attributes

centril: it's hard to make it a hard error given that they are just procedural macros. the whole intention of this design is to introduce as little extra stuff/knowledge into the compiler as possible

so the user would end up with some really weird errors in that case

not being greedy is weird

who gets to have #[test] ?

jonhoo: #[use_test_runner(MyTestRunner)] extern crate test_runner_proptest; #[use_test_runner(DefaultTestRunner)] extern crate test_runner_default; The #[use..] invocation registers an attribute, if two invocation registers the same you get a hard error - simple and not weird at all; The runners are executed in order of #[use..] and are only given the tests annotated with attributes they

registered - #[test] is reserved for the built in default runner which you don't have to do #[use..] for

what do you mean "registers the same"?

the registration isn't per runner

that would be super complicated

"registration" is just the ability to have a set of symbols available to query at runtime

that way the compiler basically doesn't need to know about any of this

it's just a minor hook to register symbols that can later be iterated over

jonhoo: an attribute #[foobar] has a name "foobar" - if a runner reserves #[foobar] through some API the compiler provides, and some other runner also reserves "foobar", then you get an error

that's not the proposed API in my post at all

jonhoo: it is not, i know

#[foobar] would be a procedural macro that generates whatever code it wants to

jonhoo yes, this is exactly my point, they should be a hole crate proc macro

*whole

Manishearth: so, I don't think going to whole-crate is necessary

I think that makes it more complicated than it needs to be

jonhoo: IMO cargo is the hardest part

jonhoo : why though?

I think being able to register symbols (basically functions, variables, types, modules, or whatever) is the only thing that's needed

the rest is fully covered by procedural macros

no

why it's more complicated?

you need te ability to generate and replace main

and also inject imports

jonhoo: #[proc_macro_test(proptest)] fn my_runner(..) {..}

i find the whole crate macro thing to be *simpler*

it doesnt need anything on top of what exists

and we can expose common ops as APIs

Manishearth: it is simpler, but it is too simple and blocks use cases that are necessary imo

Manishearth: it's more complicated in that you have to walk the source tree of the crate

like "remove main" and "find attr functions"

centril: I don't think it blocks anything?

centril what dies it block?

Manishearth's proposal is by far the most general one

jonhoo proc macrocalready knows how to do that

Manishearth: yes, I know, I'm saying I think the interface is too painful to use :)

jonhoo: fwiw this is what tge current test runner does anyway

jonhoo: not if we expose helper apis

jonhoo basically

Manishearth: true, though then we need lots of helpers, which seems unfortunate

assuming that the "whole-crate" idea is jonhoo's "we can have one #[use_test_runner]" approach it blocks combining different runners inside src/

its either expose a restricted api, or expose a general thing *and* that api

jonhoo: i see two apis we need

I'd prefer to start with something that is geared specifically towards testing, and then potentially replace it down the line with something that can still maintain the same neat interface

like, its not more work in eitger way, but the general api gets it to us for free

jonhoo: i think that kinda sucks for bench and fuzz and other use cases

I think you could still do bench and fuzz in my proposal

yeah

but nit test frameworks that work differently

*not

jonhoo: regarding TAP; you can just linearlize the JSON into the TAP format and dump it there, no?

Manishearth: there would be some restrictions of course, but I think that's okay for a first iteration if it opens up for most of what we want with a very targeted interface

jonhoo: anyway, ill write up an erfc and include this concern

:+1:

because its an erfc we can implement the general thing and make a decision on not exposing that lwter

*later

Manishearth: I'm not really opposed to your way of doing things. I only worry that it's biting off a lot of work, and aiming to be so general as to be hard to deal with and manage.

jonhoo: got an email address?

jonhoo: the way i see it its exactly the same amount of work

Manishearth: jon + thesquareplanet com

its going to be a proc macro anyway, either we expose a restricted API or we expose the underpinning and that api

yup

*underpinnings

well, sort of. I think the restricted API may be less work

but I could easily be wrong

everything is already there, its a question of exposing

heh sure

anyway ill sketch it out and email it to you pls devtools

it also means that we are opening up a huge API surface, which then needs to be supported

*plus

rather than something smaller which we can see how pans out

sounds good

jonhoo: nah. its the same surface as proc macro

On the extra data thingy... I guess any extra data can be injected into the String - but it would be nice for the runner to know if verbose or non-verbose data is requested

my proposal is literally to make it a whole crate proc macro and let it do whatever it wants

that does block us on proc macros but i think thats ok

oh, yeah, blocking on proc should be fine

just more incentive to have that completed

Manishearth: elaborate on "whole crate proc macro"? is the whole-crate bit for the proc macro that defines the runner, or for the whole crate that is using the runner ?

and yeah, I realize that's the proposal, but that's giving away a lot of power vs. something that doesn't let you do whole-crate macros :p

centril: I don't understand why you want to use standardized output formatters for a non-standard output? why is println!() not sufficient for specialized testers?

centril: the harness is generated by running a special proc mscro on the whole crate

jonhoo: centril: ill also include a vague thing about outputs

centril: as for things like verbose, the runner can parse that from command-line flags?

centril: email?

Manishearth: twingoow⊙gc

thanks

Manishearth: haha, "a vauge thing about outputs" :p

=)

vague*

jonhoo: println doesn't go to IDEs - it only goes to the terminal

yeah no spell check on ssh on phone

no no, wasn't complaining about spelling

and im terrible at phone keyboards

just found the phrasing entertaining

heh

I think output formatting is very much a secondary concern

its an erfc

it's a nice-to-have for integration with standardized testing protocols

but can probably be handled independently

so i can say "we want to have some output formatters that folks can use if they wish, and we should figure one out"

sort of like an opt-in for test runners

yeah

essentially, "if you can provide these events, that buys your runner some integration for free"

jonhoo: so the runner can parse command-line flags passed to cargo, like cargo test --extra ?

the runner fully dictates main()

yep

it can do whatever it wants

including parsing arguments

we dont constrain it all

right; but cargo passed on --extra to the main() of the harness

the test support is literally "gimme a file and ill give you a new file" followed by "caego knows how to build this"

passes* on - my spelling is shite too

yep

dont run cargo test --runner foo -- randomflags unless those flags actually work

yeah, I think we'll want to stipulate that all arguments to cargo test are passed on to the test runner

it's pretty annoying to have to do the split with --

jonhoo: oh. btw. forgot to mention, we need a concept of generated code deps

jonhoo: if you depend on manishtest, manishtests deps will be build deps, BUT your generated test may have its own dependencies

i.e. deps on clap or libfuzzer or ...

hmm

OK; Cool. You've addressed all my concerns (save for being able to use different runners in 'src/')... #[proptest] can just do one of: 1. save extra data to file, 2. dump to terminal via println! 3. just inject all extra data as a json string inside the TestEvent::Success/Failure String

either have a way for the crate to output dep info or include it in the cargo.toml of manishtest

hmm, I have half a mind to just say that test runners should be declared as regular dependencies, but that probably isn't feasible

[harness-dependencies]

it *could* be that we want [harness-dependencies]

jonhoo: they are, kinda

haha, yeah

well, it dependa actuslly

[harness-dependencies] sounds lovely

the alternative would be to say that [dev-dependencies] are considered regular dependencies of binaries generated by harnesses

if we have #[proc_macro_test(testname)] and a harness=testname key then no need to specially declare it in Cargo.toml

The "using multiple custom runners inside 'src/'" is a big concern of mine tho

however for keeping things easy to grok id prefer thdy be explicitly declared

centril yeah ...

centril: also not all runners make sense inside src

Manishearth: granted =)

eg fuzzing needs separate targets

but test, proptest, quickcheck, .. those kind of testing frameworks do

yep!

the ability to say "dont run on src" suffices

Manishearth: I don't think having multiple runners per crate is insurmountable tho; you could easily just have them register their own attribute and then run the runners in the order defined in Cargo.toml [harnesses]

yeah, though I think it'd also be perfectly fine to have cargo generate multiple binaries

and then run those in sequence

[harnesses] proptest = "1.0.0" \n quickcheck = "1.5.0" \n ...

jonhoo: totally; but you have to still deconflict attributes so that multiple proc macros cant reserve the same attribute

so you know which one belongs to which runner

yup

and I think that's something we'd have to deal with in Manishearth's design too

somehow

if two harnesses want to use the same keyword

but (obviously) in different ways

#[test] and #[bench] are strong candidates here

Tho I think #[test] should be reserved for the default runner we have today for simplicity

What do people normally use, syntax-wise, for macros that generate impls? I've tried (<T>, Foo<T>), (<T> Foo<T>), and (Foo<T> where <T>), and all have ambiguities...

no-one but the compiler gets it, so there are no squabbles over it

there isn't a good reason for that if a crate doesn't use the default runner though

and the problem still doesn't go away

jonhoo: crates.io harmony is the good reason ;)

this is different though. this is like saying no two crates can have a type with the same name

sort of

we wouldn't want community fights about which one of jonhootest and centriltest got to be '#[test]'

Also, I haven't been following along, but #[test(name_of_test_crate)] ?

jonhoo: hmm... not really; crate types are namespaced by the crate, and you can always rename them with 'use..'

no, but who gets, say #[test::setup] ? what about #[benchmark] ? or #[skip] ?

remexre: I think that nests badly if you have #[test(proptest(runs = 100))]

centril: yes, I'm not saying that's the case today

I'm comparing the proposed "just say no-one can use #[test]" doesn't solve the problem -- it'd be the same as saying there can be no duplicates

#[test(proptest)] #[proptest(runs = "100")] fn asdf() {} ?

#[proptest(runs = 100)] is simpler

remexre: #[proptest(runs = 100)] fn foobar() {}

it's more like "no two crates can have a macro with the same name"

short and sweet

But then the compiler's prevented from adding new attributes, no?

remexre: how so?

I think both of those proposals are a little too simple. There are testing frameworks that have significantly different ways of specifying tests. Requiring that format for attributes would be way too limiting

let's say the compiler adds a proptest attribute; now what happens?

yeah, that also true remexre

remexre: that is already true of attributes and custom derive

though we sort of already have this problem with procedural macros

but this would likely make it worse

I thought derives "got to" the attrs before the parser proper?

remexre: yes, but the trait... ;)

Oh, right

not sure about that. but regardless, proc macros can do arbitrary attributes

#[derive(Arbitrary)] <-- who gets Arbitrary?

yeah, sure, that makes sense. Why aren't those paths again? :P

remexre: +1 ;)

remexre: and why can you custom derive non-traits ?

or at least #[derive(crate_name::Type)], even if it's fakey

idk, I like the vulkano shader derive

(over writing shader loading logic myself :P)

yup

and again, proc macros can make arbitrary attributes

like #[foobar]

remexre: you could just scope it like 'use proptest::arbitrary::Arbitrary; #[derive(Arbitrary)] struct FooBar;'

so we already have a namespacing problem there

the particular issue with test harnesses is that they are *likely* to pick overlapping names

jonhoo: its a good thing they are unstable so we can break the lot of it

centril: A use could be present below the derive expansion, no?

remexre: below = ?

#[derive(Arbitrary)] pub struct Asdf; use proptest::arbitrary::Arbitrary;

Or even expanded to by another custom derive

#[derive(Arbitrary)] struct qwertz; #[derive(ExpandToQuickcheckOrProptestArbitraryUseBasedOnThePhaseOfTheMoon)] struct bar;

remexre: the compiler could simply add a rule that says that derive can only see uses before - and uses inside derive do not expand into the module directly

or one of those

this sounds very hacky

muvlon: less hacky than not namespacing custom derive :P

it is a workaround for not namespacing custom derive (or macros in general)

idk, gtg tho; bye all

and it might put off the *actual* work to namespace macros

muvlon: I'm certainly open to more general ideas

Yeah, I'm with muvlon here

this problem is not becoming better with time, and will come back to bite us

it was an OTOH thought ;)

i like the "use proptest::arbitrary::Arbitrary; #[derive(Arbitrary)] struct FooBar" idea best

but then i'd also want `use error_chain::bail; bail!("foo")`

instead of the odd #[macro_use]

jonhoo: on #[test] and who gets to use it.. you can do #[mytest] mod foobar { #[test::setup] fn setup() {..} fn mytest(..) {..} .. }

#[macro_use] is so weird

or just #[mytest::setup]

the entire macros-not-being-namespaced issue is weird

yeah

On a separate note... There needs to be more focus on property based testing in Rust in general

so i'm against any sort of bandaids for now

and with proc macros, it's just become worse

muvlon: I thought failure was all the rage now what with error_chain being sorta deprecated :P

because now we can have collisions on arbitrary attributes too

i used failure for a crate recently

but then went back to error_chain because i didn't find a way to match against failure::Error

jonhoo: this is a real problem for quickcheck and proptest if you want to combine them cause they both will have traits Arbitrary

and deriving for that

i know i'm supposed to write custom error types and impl Fail for them but really I just want a single error type like error_chain! generates for me

muvlon: the single error type should be failure::Error

and then you use .downcast_ref()

if you need to introspect it

is at least the impression I've gotten

downcasting :(

rewrite it in java

haha

nice

albel727: you run a lot :P

jonhoo, yes, that is a solution

but matching is far more ergonomic

I agree

muvlon: +1 million

I guess one observation is that callers often don't care exactly what the error was

I'm told that often. not as often as I run though. :>

like with io::Error

you can still make a one-error-to-rule-them-all when using Failure. it just doesn't implement one for you by default

think you'd hjave to do it yourself, which if that's the pattern you want i guess it makes sense to use the tool that just does it for you

The thought of dynamic dispatch makes me uncomfortable in general; I need to be more OK with it

failure::Error is only supposed to be for "high-level errors", i.e. when it's probably too late to handle anything anyway and you just want to alert the user/log it

so you maybe won't need to match against it as much if you write another error that impls Fail

muvlon: my largest problem with Fail(ure) is that it has 'static + Send + Sync directly and no tower of traits

but i want that crispy error_chain macro that eliminates that sort of boilerplate

so it is unusable for error types with lifetimes

that too

centril: how many of those have you seen?

sfackler: they are clearly in the minority; but for lexers (which are common), it is useful to have an MyError::Unknown enum MyError<'a> { Unknown(&'a str), .. }

saving the span is also a viable option

why is it bad for that to not implement Fail?

sfackler: it can't implement Fail

afaik

I know. Why is that a bad thing?

sfackler: cause the failure crate brings with a common and useful API for custom deriving stuff

which you don't get by not being able to impl Fail

but when are people going to be using the MyError<'a> as a normal Fail error that's propagated around? you can't really since it holds a borrow

What is very appealing to me about failure is the custom deriving stuff

sfackler: its not the propagating-around that I am after, it is the conversions (From impls, etc.) and what is offered by quick-error that I am after

I guess I could fork failure and have an identical interface save for the trait name to support lifetimes and piggyback on the work done there

but that bifurcates a bit, which I would be happy to avoid

i see no reason *not* to stick with error_chain for the time being

i think the rust ecosystem has a tendency to move super fast instead of letting things mature

error_chain isn't even 1.0 yet and it's already considered "old and busted"

muvlon: quick-error for me =)

haven't used that one yet, i'll give it a look

^,-

muvlon: I could be wrong; but I think the great appetizer of failure was custom derive

custom derive is cool and all but with the downcasting it feels a bit like going back to good ol Box<Error>

well, when error-chain was created custom derive wasn't stable

and i think error_chain does fine without it so far

since then, custom derive became stable so a new, "easier" library came to life

i guess you could rewrite error_chain to have #[derive(ChainedError)] or something but that wouldn't even gain that much

We clearly need #[derive(ErrorTheCentrilWay)] that I will implement at a time of my choosing :D

i think i don't even want a custom-derive-based thing

because that will always give you a trait, not a magic gargantuan enum you can match against

muvlon: nope; custom derive can give you arbitrary code that totally does not impl any trait back

wait what

^-- exactly

muvlon: this is how you can do things like docs.rs/derive_is_enum_variant/0.1.1/derive_is_enum_variant

i mean, i knew about the proc macro hack

but i just assumed it was still generating trait impls in the back

lol

that wait what though

oh, the nightly book is actually upfront about this

hmm or not

"Today, the only thing you can define procedural macros for is to allow your traits to be implemented on a type by specifying the trait name in a derive annotation."

I'm not sure it was a good idea, but well... it is stable now and with us to the very end

oh, i'm looking at it now

@centril probably will be fixed wayyyyy later.

when someone isn't afraid to touch it

you actually have to output the `impl Trait for Type {` yourself in the proc macro

so nothing stops you from emitting anything else

also weird: in every custom derive i've seen, you take a token stream as input, convert that to a string, then parse that string using syn or whatever

_including_ supposedly lexing it back into tokens, no?

muvlon: was this stabilization by accident?

groks: it's on stable; can't be fixed

bah

stabilization by serde-really-needs-this-lets-get-it-out-the-door

:)

centril that'll be a fun one years from now

you can't break anyone's code on stable except for in very very minor cases

don't get me wrong, i love to derive (De-)Serialize

What's bad about this being stabilised?

(And what is the bad bit of the proc_macro_derive system?)

Mutabah "magic arbitrary crap" being returned

Ah, being able to return anything from the derive handler?

Mutabah: what is bad is that 1. you can emit non-impl items in #[derive(..)] , 2. there is no namespacing, if two crates use the same trait, you are effed

specifically non-trait-impl-items

yep

the whole thing about it having to be its own crate is weird as well

muvlon: I thought that was a technical temporary restriction?

muvlon: That's a technical issue mostly

but that one's fine since you can lift that restriction without breaking any code

I wonder how much breakage (which we won't do..) would be hypothetically caused by requiring the emitting of a single impl-of-trait item which is named the same as the trait the custom derive macro registered for

centril: a lot.

Have to realize a lot of people are throwing that impl out w/out realizing it's mostly a hack

centril: serde_derive emits something that is not an impl block

just to make it float by, and also, I hate puppies, they fart too much

Gotta find a diet for this dog that is rust compliant lol

dtolnay: oh :/

i guess i'm just a bit salty that custom derive got stabilized in no time but i'm still waiting for slice patterns

did any of you get the plush ferris crustacean from kickstarter?

muvlon good luck.

groks: no; link?

Gotta have someone with some pull

totally adorable

muvlon: honestly, I can live w/o slice patterns - custom derive is so important tho

my dog tried to steal it

hello, question: how should one import an external crate for use in a module?

ie: i have a function in a module that uses yaml_rust to read a config file

centril, yeah, it's 100% QoL, whereas custom derive is essential

marmalade_ pull it in on main and use ....;

groks, sorry, ....;?

specifically the calls you're trying to use

marmalade_, all "extern crate" declarations need to go in the crate root

muvlon thank you

muvlon: custom derive is also about QoL - just that it improves it so much for a bunch of traits

for clarifying

muvlon: "need"? Not "need"! That's the convention though.

muvlon, the crate root meaning main.rs?

yes

tytyty

insaneinside, really? it just errors when i put it anywhere else

where the main part of the application lives

main, default, core, blah blah blah

okay that makes a lot more sense lol

oh it's the mount point thing rearing its ugly head again

i took it out of that and put it in the mod and got a crap ton of errors

muvlon you're hitting that?

thx muvlon, groks

not a problem

`extern crate foo;` brings the name `foo` into scope at the current location

i guess i must have been, since apparently it's fine to have "extern crate" in a submodule

it's like mounting that namespace at the current node in the namespace tree

but in `use PATH`, `PATH` is *always* relative to the crate root!

im sitting here watching how engines are fabricated

muvlon ohhhh

insaneinside also good points

insaneinside, yes, very weird

some of that stuff drives me bonkers coming from other languages

it drives me less bonkers than having to deal with headers

ugh

don't get me started on that

lol

but when i started out i flat out gave up on modules for like 3 months and put everything into lib.rs

I've done linux kernel patching in the past and making patchsets in my less sane gentoo days

rust makes me feel at home

C has no namespacing at all though

it's like macros but for everything

groks: PS: torvalds doesn't hate Rust unlike Java & C++; so RIIR linux?

if there was an MTG card for it, it'd be STRESS -10 tap for stress defence

centril lol

centril, [citation needed]

if he hasn't said anything yet, he hasn't looked at it.

and when he does, oh god will he light up the ML

lol

linus always has a hot flick to throw out, comment wise

i will continue believing torvalds hates anything but C and perl until shown otherwise

muvlon i sort of agree

let's move to #rust-offtopic?

I love C and ASM

centril sounds good

perl?

that seems so weird

On windows do people typically use powershell for rust work?

I'm prodding vscode to get rls working, but it's not seeing my nightly toolchain. Not clear where logs are stored yet

that varies quite a bit probably, I used bash that git installed

hallo is me again, what is the best way to get sort of like - a multiple return situation from a function

ie: i have a function which reads from a yaml file which is a config file

and i want to be able to pull things from that function, so like - for example say a server name, a port number, etc etc

make a struct that stores those things and return that?

like `struct Config { server_name: String, port: u16, ... }`

ah seems like my nightly lacks rls right now

muvlon, oh yeah, that makes way more sense lol ty

ah there we go, got vscode using rls stable and now I can see types and such

That's a great help with learning

when i type in "elf" into docs.rs, my crate, goblin, which has elf in keywords, as well as description, doesn't even rank. however, many completely unrelated projects do. its kind of annoying. similarly for pe and mach-o; it looks like the search is literally doing string submatches in the crate name which is... not great?

so as awesome as docs.rs is, it's in no way an official rust thing

it's merely implemented by the community

crates.io however if official

is*

err sorry could anybody maybe take a look at glot.io/snippets/exenx3o6o2 and tell me how i should be returning this information, or if i'm doing this all back asswards?

its the config file function setup i was talking about earlier

right now the only thing being returned is a token, which is a string, but i'm going to likely add more things later

but basically in main.rs i want to be able to pull that data like config.token or whatnot

if that makes a lick of sense

marmalade_: Shouldn't `read_config` return `Config`?

Mutabah, isn't it?

No, it isn't

how should it be written so it does?

marmalade_: you need to specify in the function defintion/signature what it returns - in this case `fn read_config(filename: &str) -> Config`

ahhhhhhhh

ty ill try that right now

what in the world does `match self.0 {}` do in a function that returns an Option<>?

And then where you have `let result = Config { ... }` you can do `return Config { ... }` (or, since it's the last statement, just `Config { ... }`

(I'm specifically looking at wasm32's fs libstd impl for Iterator

thenewwazoo: Depends on what `self` is?

thenewwazoo: The .0 is "tuple indexing" - Most likely the type is something like `struct Foo(Bar);`

it's kind of a weird scenario

thenewwazoo: In that case, `match self.0 { ... }` is matching the first (and only) field in the struct

right, the type here is, I think, something like `struct Bar(Void)` where Void is `enum Void{}`

thenewwazoo: Aaaah :) So, that type can never actually exist

(because Void can't exist at runtime, it has no variants)

right

so what's the objective?

The match is the way you write a function that operates on that non-existent value (which should never be able to be called, because that would require that non-existent type to exist)

It's a trait impl, right?

yeah

for Iterator, in this case

So, it's implementing that trait on this non-constructable type. I don't know _why_ it is, but odds are something needs it

the answer might be "because an attempt at instantiation should fail spectacularly"

which makes it hard to follow :D

this is, specifically, in src/libstd/sys/wasm/os.rs

okay so i'm now running into an issue trying to pull that data in main - the compiler is complaining that "field token of struct Config is private"

marmalade_: You can make a field public by putting `pub` before the name in the struct definition

oic so i have to explicitly define the uh

fields within a pub struct as pub?

Yes.

hm, so why does `match self.0 {}` as the only statement in a function that returns an Option still compile?

awesome thanks!

wouldn't that return ()?

marmalade_: because although the struct is pub, it might have something private

thenewwazoo: it compiles because it's effectively a diverging statement - like an infinite loop

curious.

thenewwazoo: every arm of the match returns an Option :P

Mutabah, i see

sfackler: Good way of putting it :)

well damn its workin now!

sfackler: I suspect your answer is deeper than I'm grokking

thenewwazoo: That match has no arms, which is ok, because the type it's matching has no alues

thenewwazoo: Since there's no arms, it doesn't return a value (not that it returns no value - aka ())

oh right I guess that's true

this is like a Rust koan

what Option do you get when you match no arms? mu.

`!`

Well.., it's !

thenewwazoo: This isn't just something for Option, it works for _anything_

oh, so when you're implementing a trait you can't redefine the signature, so that's a way to force it to !?

you can't say impl Iterator for Foo { fn next(&mut self) -> ! ... because Impl requires next() to return an Option, for example?

Kinda

so if I manage to try to call that code (which I can't even replicate in the playground :D), do I get an abort or a panic?

the other day i talked with some folks about if requiring Copy was the only way to check for !Drop

but it seems that's not the only way, doc.rust-lang.org/1.10.0/core/intrinsics/fn.needs_drop.html

thenewwazoo: If you soemhow manage to call taht code, you get UB

Mutabah: iiiiiinteresting

thenewwazoo: if you make a value of a type that has no valid values, you invoked UB somewhere

and if I try to instantiate a `struct Foo(Void)`, I should get a compiler error?

thenewwazoo: try it out.

thenewwazoo: How would you do that? :D

Lokathor: that's not part of the type system, though; you can't bound your generic on it

hahah well, yes, how would I? but there it is in libstd :D

sure, you'd have to assert on it at runtime

thenewwazoo: It exists as a type... but that type has no values

(and also it says that if it's non-Copy and non-Drop it can pick either answer)

this is as close as I can get, and it predictably fails

fails to compile, I mean

so in the context of libstd, this looks like a way to say "you cannot create a Bar for this target, even though you can elsewhere"

a way to force that to indeed be true

that's cleverer than returning None and hoping someone notices

thanks for the insight, Mutabah and scottmcm :)

okay, now that I understand this, this is a _super_ nice solution

`!` is an awesome thing to have in the type system :)

well, my early attempts at "you cannot have an AnonPipe", for example, was to always return an Err or None, and occasionally panic

but being able to say "AnonPipe is not a thing that can exist" whilst still defining it is _reeeally_ clean

scottmcm: Yeah. It's a pain in the rump to make work with typecheck (because ! can become anything), but it's a wonderful feature for a user

is there a way to make error output from compilation more compact?

ideally, "filename:line:col: error: message", one per line, none of that code block stuff to show a preview

Lokathor: What for/

i want to see more errors at once and i don't want to make my terminal taller?

Mutabah: it's harder than the other random coercions? Interesting.

Mutabah, the preview is usually useless except with specific kinds of errors

ditto with warnings

is there a way to figure out why rust can't find a file?

scottmcm: Plays in with inferrence to a greater degree

marmalade_: rustc? or user code?

erm - not sure, all i know is that the config file is in the same directory as the binary file, and when i run it it says it cant find it even though in the code it's pointing to ./config.yaml

"thread 'main' panicked at 'Couldn't open ./config.yaml: entity not found', /home/marmalade/Documents/discord-qdb/src/yconfig.rs:18:19

"

thats the full error

marmalade_: That's relative to the directory in which you run the binary, not nessesarily the directory of the binary

i'm also running it from that directory

is there a better way to reference it, maybe?

^ the code

the reading is done from that code, which is a module

So if you do `ls` it shows `config.yaml`?

yeah

And then you do `./discord-qdb` and you get that error?

yeah

the only thing i can think is that i've messed up with the string or something

because i'm hopping back and forth between String and &str i think

"glot.io/snippets/exepgfrsuf"

whoops

"let config = yconfig::read_config("./config.yaml");"

thats in the main.rs

then

" let mut client = serenity::Client::new(&config.token, Handler);"

try with `strace ./discord-qdb` just as a quick check

Maybe something is changing the directory?

However, that should work. The string stuff shouldn't be a problem

the strace

uhh the error also says to run it with ah

RUST_BACKTRACE=1

yes, that's because you used panic! (which is intended for fatal program errors that require a backtrace)

ahh

The path looks sane in the strace and there' no mention of changing directory... are you sure you're running from the right place?

and right capitalisation?

i mean ill check again

if you can't find it, run the following : `ls` `./discord-qdb` and paste the entire shell output (including the commands)

okay so it looked identical, so i tried changing the file to configuration.yaml and the call to ./configuration.yaml and now it seems to see the token but crashed with a diff exception

which is weird

maybe its because i use "config" in the code or something?

not sure

although looking at this exception it doesnt make much sense either, because the println i have to confirm it pulled the token string prints the right thing

No, but might have been capitalisation or a space or something similar

i mean its possible i moved the file around a couple of times

oh my od

god

i have brain damage

i totally just dumped the string into the yaml file

and didnt write Token: <token>

laugh at me

Hello :) How can I dereference i32? In the past I just used the `.abs()` fn for ids, but that, for sure, will not work with negative numbers. So any suggestions? :)

hi sbl, I don't quite understand your question. Are you asking how to use an i32 as an index?

or do you have references to i32? &i32

cjm: emerentius: I have structs in a BTreeMap and I need to dereference an i32 value of a referenced struct.

dereferencing is an operation you do on pointer types so I'm still not sure what you want

can you show code?

Sorry, I will write a playground. Just a mom

easy: don't

those are values already

sbl: If you remove the * your code works. i32 is Copy, so you get the value for free just by referring to the field

Argh. Yes. That's strange. Not really strange. But I have to check, why this is in my local code not the case.

Hmm. Just works. Dunno, what I wanted to do in that parts of code and why I called the `.abs()` fn there. Thanks so far, @emerentius @cjm

hi, I want to call the same instruction n times and get the value returned by the last iteration. I could solve this problem with an iterable function, is there another way ?

kiuma: std::iter::repeat(()).take(n).map(|()| instruction()).last().unwrap() // there's probably a more sensible way

kiuma: I'd personally write `for _ in 1..n { instruction() } let value = instruction()`

0..n

or you'll have n-1 iterations

emerentius: no, that's one too many

n is not included

n times, value of the last iteration

1..n runs n-1 times

right, didn't read properly

then again... trying to be overly clever is a recipe for disaster

maybe not use the 1..n thing

expected saving into a variable inside the loop

oli_obk_, oh thanks I like the for trick, I didn't think about that trick

kiuma - repeat_call(instruction).nth(n)

(Needs itertools)

tilpner, thx but I need it just for wring my tests

Your tests can be pretty too :c

:)

yep, sold

Is it possible to pre-compile a crate, and point cargo to that precompiled crate, but only for a specific target?

(i.e. precompile openssl-sys for ARM, then if any dependencies need openssl-sys for ARM, they use that precompiled crate?)

hi, I can't figure out how to write this play.rust-lang.org/?gist=a9cd9a4870…ec0ac89dc1ba71618a49&version=stable with a loop. Can anybody help me please ?

kiuma: you want to use MyStruct in `for item in my_struct {..}` ?

kiuma: like this? play.rust-lang.org/?gist=9648d602f1…dba7382bde41e1e698ed&version=stable

killercup, thx I try this in my test

i'm confused about parsing syn::TypeTuple; say i have parsed one from this exact string "(A, B, C)" .. what operations are needed to get each referenced type?

i'm already iterating over syn::TypTuple.elems, but i don't get the correct way of parsing the syn::Type enum

also, i'm trying to print typetuple through the Debug impl, but it tells me Debug is not implemented.. but the docs say it is (i'm already compiling with 'full' feature)

it looks like doctests ignore RUSTFLAGS envvar, is it intended?

There's apparently still some stuff I don't understand about `&'a mut`.

Could someone tell me what I'm doing wrong here? play.rust-lang.org/?gist=e204744427…9a3c73a4dd579d433a5f&version=stable

Yoric: &mut T isn't Copy, Self is &mut T, so &self is &&mut T, a reference to a non-copy type, which you cannot dereference

Ah, right, it itn't copy.

It isn't even Clone, I assume.

Ok, that makes sense.

SpaceManiac: Thanks.

pnkfelix: Would you remember where the AST-walking macros are defined in the compiler?

Yoric: github.com/rust-lang/rust/blob/master/src/librustc/mir/visit.rs#L80

Yoric: and then invoked here: github.com/rust-lang/rust/blob/master/src/librustc/mir/visit.rs#L812

pnkfelix: Thanks.

Why does the Read trait so much? I mean shouldn't it just read some bytes and that's it. Why things like `read_to_string`, `by_ref`, `chain`, `chars` etc. Feels like these things ought to be a higher level. Lots of convenience fluff to impose on someone trying to fulfill the trait, no?

algesten: those all have default implementations

oooooh :D

@SpaceManiac thanks! I totally forgot you can do that in Rust xD... Rust is awesome!

Does Rust tie in with any functions-as-a-service frameworks at the moment? There's a discussion at news.ycombinator.com/item?id=16157430 about a new framework called 1backend, but it looks like it has support for Go and Javascript right now.

What's functions-as-a-service..?

nox: Very simple/stripped down backend services.

nox: i imagine something like awe lambda, it basically starts a process whenever something like "http request" happens

CGI, but with containers instead of processes :/

(And apparently a need to add support for every language individually?)

I'm not sure if it's necessary--OpenFaas seems to use STDIN/STDOUT for process intercommunication. But maybe some frameworks offer things like type safety with language integration?

What

I mean, I guess that could work.

Pipe 1/2 of a child process into something in our process

Mutex<RefCell<Option<Box<

lol why do I need so many levels of nesting ./

my fault

RefCell seems redundant

Mutex<RefCell<>> looks like the first thought attempt to wrongly invent RwLock

oh nice

thanks for that

there is a difference though

RwLock only impls sync if the inner type is sync

but luckily my type is sync

well of course

but it's either plain RwLock or plain Mutex. RefCell is redundant either way.

how so? I've thought mutex doesnt let you mutate the inner value

why wouldn't it?

hmm wrong

holding a lock means you're the exclusive owner. so there's DerefMut of course.

(well, one could imagine in general some convoluted cases when you actually do need Mutex<RefCell<>> but I'd find it hard to come up with one.)

Wasn't there a way to go from `Iterator<Item=Result<A, B>>` to `Result<Iterator<Item=A>, B>`, somehow

or am I thinking about something else?

rubdos: collect

it doesn't go to result<iterator though

it gives

result<collection<A>, b>

that'd require O(n) storage, no?

or can I somehow collect into an iterator? :'-)

(I find this difficult to search on Google)

dunno

Since it needs to return Err if any element is Err, but also needs to yield all the values of the iterator if they're all Ok, there is no way to avoid the buffering

sounds fair, yes

Then, is there some way to go from `Iterator<Item=Result<A, B>>` to `Iterator<Item=A>`, *returning* in the function when something goes Err(.)?

Possibly, depending on what semantics you want for sequences like OK, Err, OK, Err, ...

Right, I get that what I'm after has no generic implementation, thanks :-)

I'll have to call collect at the end of the thing in any case, so I'll go with that

I can just defer Result to the very end

Yeah usually it doesn't matter

i have a large enum with associated data in another crate that i'm trying to write a match statement for. is there a way to have something similar to a macro that reads the source and generates the match arms without having to write each by hand?

Hi guys, i have a question for you

so ask

I'm trying to do callback with C library

But they are async

I'm registering them but they a never triggered

I read that they maybe on another thread so they have to "join" the current channel

In the rust book, in the FFI section they say that I should use channels

But I can't find a decent example on the internet

if the callbacks are never triggered then it's not a problem of threads or whatever.

at the very least, a println!() in callback should print in any case. don't bother with channels or anything until you have at least that.

Hm. Is there a way to achieve this? play.rust-lang.org/?gist=daeb68f61e…5c76eba5fc85e99deb8c&version=stable

Rantanen: unfortunately no

Having a trait define a default implementation for a function and then calling that default implementation from the impl of a struct.

:<

except pulling out the default impl to a method or something

Unfortunately that default impl is in syn.

dtolnay: Bad! *Hides*

Time to copy paste it I guess. :)

dtolnay: (On the other hand, <3 for having the visitor traits built in)

well one can always implement a newtype delegate, I guess, that would have the unoverriden method() but call out for other methods in your struct.

hi. i'm trying to return string from function, and I fail. what did I screw up: share.riseup.net/#X_y3E8kaQ7pfaKQIEiEcZg ?

hey depesz1, you want to return &'static str (if it's always a string literal) or String (if it can be generated at runtime)

depesz1: did you save?

look at the error vs the text

they have different signatures

the text looks like it fixes the error

if I tried to return String, I'm geting: expected struct `std::string::String`, found &strm on the line that returns value.

yes

what can I do about that?

well

you can do what durka42 said

and return &'static str

or, you can add .to_string() calls on the end of each of those string literals, and return String

sweet, thanks a lot.

some reading on the difference: ameyalokare.com/rust/2017/10/12/rust-str-vs-String.html hermanradtke.com/2015/05/03/string-vs-str-in-rust-functions.html

I guess I will get to it - i'm reading doc.rust-lang.org/book/second-edition/ch03-05-control-flow.html

but thanks for the links anyway

dtolnay: Actually a real question concerning syn. parse_str( "#[attribute]" ) doesn't seem to work as Attribute doesn't impl Synom. Is there a way to generate 'Attribute' other than building it as a struct by hand?

depesz: ah, chapter 4 digs into the differences here!

so you're close :)

I guess parsing "#[attribute] fn foo() {}" and just stealing the attribute from it would work, but that sounds a bit cludgy. :)

yeah, i figured, but wanted to do something "cooler" than simple loops and printing integer.

Rantanen: I think you could generate the bits you need seperately (as a syn::Path, syn::ExprParen), then just `let attr: syn::Attribute = parse_quote!(#[#path#paren])`

callym: 'parse_quote!' return type must implement Synom trait. syn::Attribute doesn't do that.

Rantanen: I think there's a special case for syn::Attribute? I'm doing `item_impl.attrs.push(parse_quote!(#[attribute]));` and it's working here

I've got a proc macro that goes on a impl block and rewrites some types, but if the type exists in a attribute that's handled by a different proc macro, I get "cannot find attribute macro in this scope"?

if I change the second macro to not be touched by my macro, then it works fine

Is there a standard pattern for passing something mutable into a Rayon parallel iterator? I feel like what I want here is an Arc<RwLock<_>>, but Google is failing me: play.rust-lang.org/?gist=7cd464bd36…78f70c90fccc27a0d1b&version=nightly

Is it legal to use trait associated consts off of a generic like this? play.rust-lang.org/?gist=de458028c5…33da316b071d0c6cd922&version=stable

urschrei: if you're only using a counter, you may be better off with an AtomicUsize/AtomicIsize or the like

urschrei: otherwise yeah, you probably need a Mutex which you send a & of into the per-item closure

napoleon: relevant rust-lang/rust #42863

!gh 42863

albel727 beat me to it :p

:P

Thanks.

simple profiling tools?

what about them?

perf

hi, is there something like setup and teardown for tests in rust? I need to start an hyper sever and stop it when all tests are terminated

misdreavus: I really do just need a simple counter. Will have a look at Atomic{U, I}size. Thanks!

kiuma: nothing built in. one trick is to use a lazy static and do your setup there. on nightly you can use {!crate stainless} (dunno if it's updated lately)

Rantanen: the default implementations for visitor methods are exposed in docs.rs/syn/0.12/syn/visit/index.html

urschrei: cool! once you get your atomic ready, you can just send a & of it to your per-item closure, since all the update functions only need &self

Rantanen: this page covers parsing attributes docs.rs/syn/0.12/syn/synom/index.html

Rantanen: but it is something like Attribute::parse_outer.parse_str(s)

Yaniel: i'm looking for them

durka42, it seems a bit tricky to test things like http servers

agreed

dtolnay: Might follow with a PR to include that in the Attribute docs as well. Would neve never thought to look up something specific like attribute parsing from the synom docs.

badmann: AFAIK you can just use the same ones as you'd use for C

and then there's stuff like the flamegraph crate

And same concerning the visitor default methods. The trait docs could use an example for delegating to the default methods.

thanks Rantanen, i filed issues to follow up

dtolnay: Now that you're there.. maybe.. you might be able to tell me what's going on and how to fix it.

dtolnay: This fails: #[my_attribute] fn foo() {}, where my_attribute is quote!( #[test] fn foo() {} )

This succeeds: quote!( #[test] #orig_fn )

So I'm guessing this has something to do with the call_site/def_site hygiene?

Er. Now quote_spanned!(span=>, where span is ::call_site() works too.. :|

are you building with --features proc-macro2/nightly?

Yeah

yes it is a span difference

`quote!( #[test] fn foo() {} )` exposes foo to the "def site" only meaning nothing from the call site can see it

My full example does some ident-switching and cloning, so that must be causing the difference.

Because the ::call_site() isn't working in the non-minimal example. Trying to reproduce it now.

`quote!(fn #ident() {})` will keep whatever the span is on `ident` so it's probably def_site

There we go. If I do test_fn.ident = new_ident, then it fails with unresolved bits and cannot find value in module errors.

So I need to set the new_ident (which is created with format!(..).into()) into call_site I guess.

use Ident::new to set the span docs.rs/syn/0.12/syn/struct.Ident.html#method.new

I'm pretty sure the span stuff and hygiene is one of the most complicated aspects of proc macros. :x

Mainly because it feels a bit arcane - especially the def_site in the context of proc macros.

Yaniel: do you have any suggestions apart from flamegraph? i tried cargo-profiler but the names from callgrind/cachegrind are all mangled. perf has much better output, but i still can't see any info about my rust functions. flamegraph is not that useful

you could do what xi does with chrome perf tracing

depends on what you want to profile though

just wanted some info on my simple command line program. I figured cargo test and cargo bench are great and I wanted to see if it was possible to gather some more info to have a complete overview of performance

is Xi usable yet as a daily driver

how long did you take to get mut right automatically? I always miss mut at fn parameters and pointers and the compiler complains

it was more or less easy for me, coming from c++

but some rules are weird

like when you say let foo = function_call();

then another_function_call(foo)

and another_function_call takes mut foo :Type

i.e. you calla function which has &mut self param and you call that function but you miss the mut on &mut self on the calling fn

then you dont need any mut here

hard af

I'm trying to run two very simple benchmarks in callgrind. The only difference between the two is that one of them has more samples in arena.c:je_arena_tcache_fill_small, but the difference is quite small. Howeverm the difference in the benchmark time is noticeable, being around 2x slower.\

I would guess that the culprit is some extra heap allocations.

dtolnay: Got it working, thanks for the help with the spans. \o/

Rantanen: which kind of pastebin is that

The issue is that I'm finding it very hard to find out where the difference lies in. I've tried flame graphs as well and I still can't figure it out. There seems to be no difference in heap allocation between the two benchmarks.

est31: It isn't. :|

est31: Pygmentize and my own server. It's not runnable anyway as it depends on extern crates so play.rust made no sense and didn't see the benefit of throwing it on an external service.

ok

(Plus I wrote it there so I could just run pygmentize -o ~/public_html from the command line. :p)

is there function or method to convert generator into iterator

forgottenone: github.com/tinaun/gen-iter

forgottenone: I hope, eventually, generators will automatically implement Iterator

Anyone with a bit of profiling experience?

there are at least two sane ways to implement iterator from a generator

(returning and not returning Complete as the last element of the sequence)

the crate above seems to choose "not returning".

and it only works for Generator<Return=()> so it won't silently drop a useful Complete value

I don't see any such condition there

hi, if i mark an enum, MyEnum, with "#[repr(u32)]" and then i expose a fn via FFI with a signature "my_fn(my_enum: MyEnum)", and the C header for it is "my_fn(uint32_t my_enum)", will that work?

albel727: github.com/tinaun/gen-iter/blob/master/src/lib.rs#L51

cahoots: Yes, but note that it is undefined behavior to call that function with an out-of-range value

I've been deceived by old docs. no such condition there. docs.rs/gen-iter/0.1.2/src/gen_iter/lib.rs.html#49

(one that doesn't match one of the enum variants)

mbrubeck, makes sense thanks

(and even then, what if your items are also () :P)

albel727: Ah, looks like it was a later change. tinaun/gen-iter #1

what's a simple 2d graphics & keyboard events crate for rust. piston requires compiling some silly amount of crates

mbrubeck: thanks, i hope so too, Python generator-iterator model feels so intuitive

bluss: github.com/ggez/ggez might be good if you want something that is somewhat "batteries included"

bluss: For something with fewer dependencies, you might need to put together your own combo of glutin + [2D rendering lib of your choice]

bluss: Or use sdl2, which ggez is built on top of.

so I conclude that it's better to simply have two explicitly different generator adapters. one that would discard the last value, no matter what it is, and one that wouldn't discard the last value, provided that Yield and Complete have the same type.

() limiting looks like half-measure.

maybe just have one generator adapter that would yield GeneratorState as items, and just filter that depending on what you need.

filter_map, even

mbrubeck: thanks for the suggestion, but yes, I'll look for something smaller than ggez

mbrubeck: does sdl2 have a safe API?

TyOverby: looks like it

that's neat; sdl2 was a pretty fun to play with when I was learning C

on the topic of sdl2: does it work out of the box for vulkan? I was trying to use it with vulkan, but was hitting issues and I couldn't tell if it was from lack of support in the rust sdl2 lib, or build system weirdness on my end.

I'm compiling sdl2 from scratch and not using cargo for various reasons

Uh. Is there a way to update README.md on crates.io without publishing a new package version? :|

no

releases are immutable

is there a way to debug deadlocks (when using tokio)? maybe with rust-gdb?

(mutex)

Not sure if the README.md should be immutable though. Fixing typos in the documentation shouldn't require a version increase in the actual package.

>tokio >mutex

But I can accept it being simpler with everything being immutable instead of making exceptions. :)

dbrgn: you can do that normally, yes

Rantanen: the same could be said for fixing typos in the documentation or fixing bugs in the program code :)

there isn't any special help for it in displaying suspended futures or anything though

Rantanen: typo fixes change the hash

if you want repeatable builds, you need immutability

(but if you're actually using std::sync::Mutex and tokio, unless you're careful or using the Mutex specifically between separate Cores on separate threads, it's likely "don't use Mutex with tokio")

Ah, true the readme is included in the downloaded package.

in theory, you could say that we'd store a mutable version of the metadata on crates.io

and have it differ from the downloadable version, but that has problems

I'm just sad, because I've now went for two version bumps, just to get rid of the scroll bar: crates.io/crates/ratcc D:

And I'm still failing. :x

it happens :)

albel727: huh?

.. it's not there on Firefox. :|

talchas: but those suspended futures should still be on the stack, right? so I should find them with "bt"?

(Mutex lock suspends the thread and the entire Core with it; if you're expecting it to suspend just the future, you'll lose)

tokio is fundamentally incompatible with anything blocking. with very high probablility if you use a mutex, you're doing it wrong.

talchas: ah, of course :)

it happens :)

oops

lol

dbrgn: no, "suspended" as I meant was more for "returned from and_then or something else like that and have not yet run"

albel727: the tokio based code might still have to interact with threads / pass values to other threads. of course, deadlocks are the consequence when not being careful.

that said, anything blocked on a Mutex will still show up

if they have to converse with other threads, then they should do it via future-ready channels.

perhaps more "suspended Tasks" is more to the point

albel727: through Remote, right?

(since channel::send returns a future)

is resuming to coroutines with value implemented, I mean equivalent of x=yield ... in python

doing it with the futures channels will avoid blocking all other futures while you wait for the other thread; if the other thread is in turn blocked on data coming from any other future, that's a deadlock source

if the other thread was just updating data entirely independently and the futures took whatever data was there via Mutex<Data>, that could be fine and less hassle than anything else

Remote is about spawning tasks on a core in a different thread. you can certainly do something like communication with that. but I had in mind something like using UnboundedSender from here alexcrichton.com/futures-rs/futures/sync/mpsc/index.html

forgottenone: I think it's planned but not yet implemented.

one can pass things into current generators via some shared variable, I guess.

but making resume take value seems like the obvious thing with a lot of prior examples. not sure why it wasn't implemented this way from the beginnig.

Would a normal proc macro attribute on a function, like: #[proptest] fn test_add(a in 0..1000i32, b in 0..1000i32) { .. } require that `test_add` parse as a valid Rust function before the macro doing its work?

Is there a way to make a Vec whose initial storage is stack-allocated?

Sergio: ^ maybe you know about the proc macro stuff?

What I'd like is a container that will not require a heap allocation unless the size grows too big, in which case it just does that

Yes

hdevalence: Not in libstd, but see github.com/bluss/arrayvec and crates.io/crates/smallvec

centril: yes

Sergio: oh that's a bit unfortunate :/ then that particular syntax wouldn't parse

hdevalence: (`smallvec` works as you describe, and allocates on the heap if it grows too big for its initial capacity. `arrayvec` can't grow beyond its stack capacity.)

cool, thanks for the pointer!

Sergio: hmm... what if the #[proptest] attribute is on the module enclosing the test_add function... could the proc macro be given the string for the module and do its macro on functions inside ?

No

crap :(

Arbitrary tokens are only allows in macro! { .. }

The rust source code must be rust source code

You cannot change the syntax of Rust

allowed*

Sergio: Right... was just thinking that mod tests { <-- delimiter delimiter --> } could let me get away with the lexer stopping at { and } and just give the attribute everything inside

hypothetically

centril: However "fn( a : foo!() ) { .. }" is allowed.

centril: "#[proptest] fn test(a: in!(0..1000i32)) { .. }" should go through I believe.

Rantanen: is the expansion of foo!() done before or after proc macros?

After I believe, as the #[proptest] proc macro can alter it.

mbrubeck: sdl2 seems like the winner. At least it's easy to get started.

centril: You can have any arbitrary tts inside the attribute itself if that helps

Rantanen: I guess #[proptest] fn test_add(a: in!(0..1000i32), b: in!(0..1000i32)) { .. } isn't as pretty, but it works at least

Arnavion: thanks for the reminder =) but not really ^,-

Rantanen: you could do things like #[proptest] fn test_add(a: usize, b: in!(0..1000i32)) { .. } which would be nice, then you can mix types and concrete strategies

centril: Yeah

Has anyone seen an example of integrating linefeed(preferably) or copperline with tui-rs? I don't really know where to start

is loop {} valid rust?

yup

I don't see why not

It's also sometimes how you implement panic_fmt for no_std

LLVM doesn't like it though, there's an issue open for it

yeah that can really bite you

I once spent three hours or so tracking down a bug in a no_std crate that turned out to be due to LLVM optimizing out loop {}

Heh

vurpo: in C, that's undefined behavior, hence Soni's question

loop { unsafe { asm!("nop") } }

actuallyl, is it UB, or just "can be optimized out"? i forget actually

what... `loop {}` in Rust code can be optmimized out ?

point is, in rust it's an actual inifite loop. or rather, once we got that bug fixed

centril: no

i was speaking of C

It's that the standard requires that every thread terminate, so infinite loops cannot exist

steveklabnik: but there's no loop{} in C ?

while(;;){}

oh, that

centril: "infinite loops with no side effects" is longer to type but teh same thing

which LLVM assumes is true of all languages it supports, not just C

Arnavion: ah, ty

steveklabnik: =P now I get it

it's all good :)

that while loop is crying, won't you save it from its plight

Y'all got me shit scared for a bit tho

steveklabnik: It's actual UB

it can't be optimized out in modern C either, but llvm doesn't handle it properly

( rust-lang/rust #28728 )

one of C or C++ has an exception for while(1) specifically so that's an LLVM bug

j`ey: you mean for(;;) {}

while(true) {} can work as well

KiChjang: ya

do {} while (1) for extra fanciness.

because everyone wants to do something while it's true

ah yeah here we go

it's defined since C11: stackoverflow.com/a/16436479

any loop that has a constant expression as its controlling expression should be handled "properly"

BTW, anyone else confused about this error every time?

16 | let x = [t, u]; | ^ expected type parameter, found a different type parameter

to me it reads that the compiler expects a literal type parameter there, not an expression of that type

Er, how do I access "static" (unsure about the terminology, not tied to an instance) methods of a type in a macro? E.g. something like: macro_rules! print_maxval { ($int:ty) => { println!("{}", $int::max_value()); } }

t needs to be a type parameter, yeah

Andlon: it doesnt work?

Sharlin: did you maybe mean [t; u]?

jey, is your name hard to autocomplete on purpose? :P

Andlon: yes

steveklabnik: no, I mean the array literal [t, u] where t: T and u: U

ah, huh

j_ey, heh, all right. Here's the playground link: play.rust-lang.org/?gist=5386215bf8…cb1494ce13ab4d7752f1&version=stable

well

yeah the error could be better

Andlon: it's possible it will instead work if it's <$int>::max_value()

steveklabnik: the problem is really that T != U

but like, arrays have to have the same type

so T would ne.... yes

right

if it's always one of the primitives then $int:ident will certainly work

talchas, you're right!

anywho yeah, seems good to improve that

talchas, oh, u8 is an identifier and not a type? I'm confused

or, er, both?

both

talchas seems to imply that only the primitives are both types and identifiers?

!u8

Andlon: it's just that ident::foo() will work

but ty::foo() doesn't for some reason

huh, I see

(because some types don't parse there? even though "but you know it's a type because MACROS" should really be sufficient disambiguation here)

yeah, it's a little confusing to me

but thanks for pointing me to the angle brackets! I tried all the other kinds of brackets before I asked here :P

yeah, <type>::foo is alternate syntax that you normally only use when type::foo would be ambiguous

(you can write things like <Vec<X>>::new() rather than Vec::<X>::new() and so on)

talchas, I did not know that. Interesting!

I mean, I've been using <Foo as Bar>::Something frequently, but never thought to use angle brackets without 'as'

I'm still not able to generate function names in macro_rules!, am I?

no

you could actually write concat_idents_cps!() now with proc macros

talchas, I see. Hmm, I just want to generate some identical tests for the built-in integer types though, i.e. something like impl_uint_test!(u8), and it would generate #[test] fn u8_test() { }

proc macro seems a bit overkill then..

concat_idents_cps!(macro:ident ! ( args:tt* ), x:ident,*) => macro!(xs_concatted, args*)

suggestions on play.rust-lang.org/?gist=e70d28855a…c437e571e32ede3ade2b&version=stable ?

error[E0277]: the trait bound `str: std::marker::Sized` is not satisfied

talchas, I am not really sure what I'm looking at here

ambaxter: T: Eq + ?Sized

Andlon: someone could write a proc macro crate concat_idents_cps that does that

and then macro_rules macros could use it for things like this

talchas, ah, I see. That... sounds useful?

talchas: will that also work for primitives? or do I need a separate function for that?

like &u8

yeah, someone wrote a compiler plugin that does it, but a quick crates.io search doesn't seem to show any others

ambaxter: that'll be fine

thanks!

(the compiler plugin used a very different syntax that's nicer but more fragile)

I see

steveklabnik: ticket'd :) rust-lang/rust #47499

well, it seems like a very useful feature. I don't feel quite ready to take on that responsibility since I'm not so well-versed in macros, but I'd be happy to use something like that if someone publishes a crate with this functionality

Sharlin: ty

related but a little bit different: what if I already have a function name in mind and I want to generate a function body for it? I.e. something like generate_func!(my_function_name) would expand to fn myfunction_name() { } Can one do this with macro_rules?

Andlon: yeah that works fine

macro_rules! foo { ($name:ident) => { fn $name() { /* code here */ } } }

ah, yeah, that worked directly

for some reason I didn't expect it to. I thought I'd tried but I just looked at my code again and I had some angle brackets there

sfackler, ok, that's great. Thanks!

is "0u8" and "0 as u8" the same?

specifically when used with numerical literals, I mean

Yes

it's possible the latter will complain when in a const on stable? I forget

but in general, yes

playbot: const FOO: u8 = 0 as u8;

talchas: How's that?

nah, even that works

Sergio: it's an expression, and I couldn't remember if as was on the whitelist without const_fn

I'd be *gasp* shocked if {lit}u8 and {lit} as u8 were different in any context aside from parsing

OK, thanks for confirming. I had a pretty hard time googling that

(as it happens, it works on 1.0, so yeah, it's always worked)

playbot: const FOO: u8 = 256 as u8;