These are chat archives for rust-lang/rust

29th
Jul 2018
Matthias Berndt
@mberndt123
Jul 29 2018 00:02 UTC
@omni-viral , thanks. But that forces me to make foo an Option, which makes an illegal state representable. I'd rather avoid that
How can I go back from "*mut u32" to "u32" ?
Andrey Lesnikov
@ozkriff
Jul 29 2018 06:43 UTC
unsafe { *mypointer } (if you are sure it's not a null pointer)
@ozkriff and how can I check handle Nulls/
?
Isee there is a method > is_null(
tnx

@trsh
Hey. Im working on this proc macto (derive)
And getting an error on compile

#[derive(json_fedex_bind)]
   |          ^^^^^^^^^^^^^^^ expected *-ptr, found u32

Any change to get some code line ? To see the foulty code line generated?
@trsh
Something like stack?

Should a 37k generated code kill the compiler and OS.. or is it more something with the code?
Zakarum
@omni-viral
Jul 29 2018 12:58 UTC

unsafe { *mypointer } (if you are sure it's not a null pointer)

Not this simple. You must ensure that the pointer is valid.
1usize as *mut X is not valid pointer to X although it is not null.
In let z = { let mut x: X = ...; let y: &mut X = &x; y }; pointer z is also invalid

@omni-viral can u comment on a 37k line code?
Zakarum
@omni-viral
Jul 29 2018 14:31 UTC
Probably
To much? Can it kill the OS? Or i need to paste example?
It compiles, spits out warnings and the tries and dies. :/
Zakarum
@omni-viral
Jul 29 2018 14:35 UTC
What do you mean? rustc dies when you compile big generated code chunk?
My ram goes to max usagr and the whole OS becomes unusable. I waited for half hours and it didnt finish
Zakarum
@omni-viral
Jul 29 2018 14:37 UTC
Linux?
Ubuntu, yes
Zakarum
@omni-viral
Jul 29 2018 14:38 UTC
I had a similar problem with rustc about a year ago.
It was something with enormous function generated by deriving trait for big enum
rustc ate all available memory and everything got frozen
I have a lot of scopes inside scopes, maybe thats a memory killer?
Like let x
Zakarum
@omni-viral
Jul 29 2018 14:40 UTC
Ah. No. it was a macro thing
Ups
Zakarum
@omni-viral
Jul 29 2018 14:41 UTC
Anyway. I think that it is possible that your generated code makes rust to get all memory and freeze without any real nasty bug in rustc
Like x = { let y = A; y }
But a lot nested
Zakarum
@omni-viral
Jul 29 2018 14:42 UTC
Do you really need it?
Could you refactor it to be flatter?
I did this way, so that namings do not clash
Zakarum
@omni-viral
Jul 29 2018 14:43 UTC
If you generate code you can prefix names instead
@omni-viral but should i. Is heavy scope nasting a problem?
Zakarum
@omni-viral
Jul 29 2018 14:46 UTC
This I cannot say for sure.
But you can try :smile:
I will paste an example of generated in an hour, when i get to my pc. I hope someone can take a look.
As for now i do not understand the diff between code that is split into files and objects etc and huge code in one piece. Why should the one peace it up more ram on compile.
if I have an instance that is owned by an owning struct, is it possible to call a method on that instance passing in a mutable reference to the owning struct?
I can see why it doesnt work but is there a way around it ?
hmm pretty clear its not possible
Zakarum
@omni-viral
Jul 29 2018 16:14 UTC
It doesn't work because you can't borrow something mutably more than once
So if you borrow field of the struct - you can't borrow whole struct because there is no guarantee that field won't be accessed through struct reference
The workaround is to split struct so that you borrow one field and pass reference to another field into method
Can't paste example, as it exceeds Pastebin limit
Ghh
But it goes something like this > https://pastebin.com/fWkBcBkp
Is this compiler killing code?
Michal 'vorner' Vaner
@vorner
Jul 29 2018 18:42 UTC
Hello. What am I doing wrong and what is rustc trying to tell me? I believe this should work, shouldn't it? https://play.rust-lang.org/?gist=cd58f7855d0b6a884f0c7053dce9c308&version=stable&mode=debug&edition=2015
@vorner
I think it was not aware what i presents
Hi @vorner , @tanriol , @dpogretskiy , @RReverser, @omni-viral, @ozkriff . I know it's late Sunday, but maybe someone can help me tomorrow early morning with a problem that I'm really stuck. I created a custom Derive (proc macro), that generates mapping code from a JSON schema to generated pointer Structs. So far so good - the code get's over the errors, spits outs warning, but Then the memory goes to the roof and the OS (linux) dies. Here is a code snippet https://pastebin.com/fWkBcBkp.. and it goe's like this for ~20k formated code lines. I have no idea right now, how to get around this problem. Is it because so much code in one .rs? Or because so much code in one Function body? Or the problem is in the scope inside scopes and so on? Ideally 20k lines shouldn't be a killer, as a project with lots of imports can sum up in much more..!?
And here is abit larger example > https://pastebin.com/3qnabF3w
Any advice appricated
:/
Denis Lisov
@tanriol
Jul 29 2018 19:38 UTC
@trsh Unable to check myself, but I'd suggest that 20k lines in one function is way too much. I really won't expect, for example, borrow checking to work with any reasonable performance on this scale.
@tanriol possible solutions? Splitting in multiple fn's, or files?
Actually it feels indeed like it handles well the syntax and type errors (even warnings), and then dies on the Barrow, Lifetime (etc.) check cycle, as it's, I think, last in the row.
Denis Lisov
@tanriol
Jul 29 2018 20:03 UTC
I'd split into separate functions/methods. Probably one per type if you're dealing with nested data structures.