profile
viewpoint

japaric/xargo 710

The sysroot manager that lets you build and customize `std`

Gilnaa/memoffset 65

offsetof for Rust

opatut/dudel 28

This used to be a webapp for scheduling meetings easily. Now it's no longer maintained. Have a look at Bitpoll instead:

Diggsey/rust-field-offset 19

Safe pointer-to-member functionality for rust

RalfJung/ansible 1

ansible playbooks for my servers

freifunk-saar/tunneldigger 0

Client and broker for our custom L2TPv3 NAT-traversing tunnel setup protocol based on L2TPv3 support in the Linux kernel.

hacksaar/Firmware 0

ESP32 firmware for the SHA2017 badge

hacksaar/micropython-esp32 0

MicroPython ported to the SHA2017 badge

Pull request review commentrust-lang/rust

Change const eval to just return the value

 impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {                 // potentially requiring the current static to be evaluated again. This is not a                 // problem here, because we are building an operand which means an actual read is                 // happening.-                return Ok(OpTy::from(self.const_eval(GlobalId { instance, promoted })?));+                return Ok(self.const_eval(GlobalId { instance, promoted }, val.ty)?);

I was about to ask for clarification, but I think a patch is indeed the best kind of clarification. ;)

skinny121

comment created time in 9 hours

Pull request review commentrust-lang/rust

tighten CTFE safety net for accesses to globals

 impl<'mir, 'tcx> interpret::Machine<'mir, 'tcx> for CompileTimeInterpreter {         static_def_id: Option<DefId>,         is_write: bool,     ) -> InterpResult<'tcx> {-        if is_write && allocation.mutability == Mutability::Not {-            Err(err_ub!(WriteToReadOnly(alloc_id)).into())-        } else if is_write {-            Err(ConstEvalErrKind::ModifiedGlobal.into())-        } else if memory_extra.can_access_statics || static_def_id.is_none() {-            // `static_def_id.is_none()` indicates this is not a static, but a const or so.-            Ok(())+        if is_write {+            // Write access. These are never allowed, but we give a targeted error message.+            if allocation.mutability == Mutability::Not {+                Err(err_ub!(WriteToReadOnly(alloc_id)).into())+            } else {+                Err(ConstEvalErrKind::ModifiedGlobal.into())+            }         } else {-            Err(ConstEvalErrKind::ConstAccessesStatic.into())+            // Read access. These are usually allowed, with some exceptions.+            if memory_extra.can_access_statics {+                // This is allowed to read from anything.

I can clarify to "this machine" or "this const evaluation", but I am not sure what kind of "example" you are asking for.

RalfJung

comment created time in 9 hours

Pull request review commentrust-lang/rust

Change const eval to just return the value

 impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {                 // potentially requiring the current static to be evaluated again. This is not a                 // problem here, because we are building an operand which means an actual read is                 // happening.-                return Ok(OpTy::from(self.const_eval(GlobalId { instance, promoted })?));+                return Ok(self.const_eval(GlobalId { instance, promoted }, val.ty)?);

Curiously, this is now using the use-site type instead of the def-site type, which leads to changing the way we ICE in https://github.com/rust-lang/rust/issues/70942 (we should be ICEing earlier, but after this PR we only ICE very late).

skinny121

comment created time in 10 hours

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

@steffahn thanks, that makes a lot of sense.

Hm, however, looking at @Centril's stack trace above, I do quite wonder how we are getting past the mir_assign_valid_types check.

Turns out the types on both sides are fine. It's just that the value returned by eval_operand does not match the type (we are getting a 32bit-value at type usize). So the type check is fine but the value sanity check later ICEs. Just like I was worried in #69181, that PR broke layer one of our safety net by throwing away some layout information; this ICE was triggered by layer two.^^

dwrensha

comment created time in 10 hours

Pull request review commentrust-lang/rust

Change const eval to just return the value

 impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {     pub(super) fn const_eval(         &self,         gid: GlobalId<'tcx>,+        ty: Ty<'tcx>,

@skinny121 did you ever get around to actually do this? Doesn't look like it, but I might have missed it.

skinny121

comment created time in 10 hours

Pull request review commentrust-lang/rust

rustc_session: forbid lints override regardless of position

 pub fn get_cmd_lint_options(     let mut describe_lints = false;      for &level in &[lint::Allow, lint::Warn, lint::Deny, lint::Forbid] {-        for (arg_pos, lint_name) in matches.opt_strs_pos(level.as_str()) {+        for (passed_arg_pos, lint_name) in matches.opt_strs_pos(level.as_str()) {+            let arg_pos = if let lint::Forbid = level {+                // forbid is always specified last, so it can't be overridden+                usize::max_value()

Btw, this could be usize::MAX now. :)

tobithiel

comment created time in 10 hours

PR opened rust-lang/rust

mark a temporary hack as such

This code was added in https://github.com/rust-lang/rust/pull/70918, but it should not be necessary any more once forbid works as expected for in-code attributes.

Cc @tobithiel @davidtwco

+3 -1

0 comment

1 changed file

pr created time in 10 hours

create barnchRalfJung/rust

branch : mark-cli-lint-hack

created branch time in 10 hours

pull request commentrust-lang/rust

bump Miri

Thanks. :)

RalfJung

comment created time in 17 hours

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

Hm, however, looking at @Centril's stack trace above, I do quite wonder how we are getting past the mir_assign_valid_types check. That one should not let types with different size pass through. We recently changed that check, which explains the nightly vs. stable difference, but this is an unexpected consequence of this change. Cc @eddyb

dwrensha

comment created time in 20 hours

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

@steffahn indeed, see my message above -- the message changed between stable and nightly. But I think the underlying issue is the same, we just changed the order in which a few assertions are checked.

https://github.com/rust-lang/rust/pull/60126 sounds like exactly the kind of thing that would lead to running Miri on ill-typed MIR.

dwrensha

comment created time in 20 hours

pull request commentrust-lang/rust

bump Miri

It's more like rollups overtaking toolstate fixes, given the priorities of the underlying PRs.

RalfJung

comment created time in 21 hours

pull request commentrust-lang/rust

bump Miri

With all this yielding going on, it looks like we no longer actually prioritize toolstate fixes after all? When can we expect this to land?

RalfJung

comment created time in 21 hours

push eventRalfJung/rust

Ralf Jung

commit sha d69c66811184707dfdb293673e58ce6121e3714f

tighten CTFE safety net for accesses to globals

view details

push time in 21 hours

PR opened rust-lang/rust

tighten CTFE safety net for accesses to globals

Previously, we only rejected reading from all statics. Now we also reject reading from any mutable global. Mutable globals are the true culprit here as their run-time value might be different from their compile-time values. Statics are just the approximation we use for that so far.

Also refactor the code a bit to make it clearer what is being checked and allowed.

r? @oli-obk

+23 -8

0 comment

1 changed file

pr created time in 21 hours

create barnchRalfJung/rust

branch : ctfe-no-read-mut-global

created branch time in 21 hours

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

So this looks like something is actually running Miri on this ill-typed code, and then doing a MIR assignment where source and target do not have the same size. Since array lengths are involved, I suspect this is similar to

https://github.com/rust-lang/rust/blob/11f6096a9ef6ad52de2956f4d2df200de7617077/src/librustc_mir/interpret/place.rs#L932-L942

I wonder if there is some way we can not run Miri on MIR like this that is broken beyond repair, to avoid accumulating such hacks?

dwrensha

comment created time in a day

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

@dwrensha do you have a backtrace with line numbers?

Curiously, on stable the ICE message is different:

thread 'rustc' panicked at 'Layout mismatch when copying!
src: OpTy {
    op: Immediate(
        Scalar(
            0x00000000,
        ),
    ),
    layout: TyLayout {
        ty: i32,
        details: <lots of stuff>
    }
}
dest: PlaceTy {
    place: Ptr(
        MemPlace {
            ptr: alloc0+0,
            align: Align {
                pow2: 3,
            },
            meta: None,
        },
    ),
    layout: TyLayout {
        ty: usize,
        details: <lots of stuff>
    }
}
dwrensha

comment created time in a day

issue commentrust-lang/rust

[trait constants] thread 'rustc' panicked at 'assertion failed: `(left == right)` ...'

Opsie, that ICE is a safety net that protects us against using constant values at the wrong type (and accidentally transmuting them). Looks like something here isn't aware that there was a type error and goes on using the wrong type for the wrong data.

dwrensha

comment created time in a day

issue commentrust-lang/rust

CTFE keeps values in padding, breaking structural equality of const generic args.

Sorry, unobservable by type equality.

Okay, so type equality has its own notion of equivalence, distinct from what CTFE can observe. Are there some crucial properties that relate the two, like one being strictly more fine-grained than the other or so? I suppose CTFE-observable-equal consts should always be type-equal (because why not), but I am not sure if that is crucial for soundness.

You seem to say that if CONST1 == CONST2 (in the sense of looking up the PartialEq instance and evaluating that code) then they must be type-equal. That seems sensible but I do not understand why it is crucial for soundness. Is this all written down somewhere?

If equality of references is defined by equality of the referent, then indeed a tree makes sense. I suppose raw pointers will not be permitted?

The typesystem does not admit such an approach for normalized types

So you are saying, for the type system we need to define equality by normalization, not via a comparison function. I can see how that helps with interning etc, but it is quite the complication here.

However, I think I'd be opposed to banning non-undef padding in "normal" CTFE results. That's a huge foot-gun, it would break consts like MaybeUninit::<(u8, u16)>::zeroed().assume_init(). And if we ban it just for consts used in types, that's still a big foot-gun as it means a random CONST I find somewhere could work fine for normal use until I try to put it into a type, and then the compiler complains about it having non-undef padding.

I suppose we could apply "typed copy" rules on the result of CTFE, and "reset" the padding on the final CTFE value, e.g. as part of interning. But this will be really hard to do for "nested" allocations where we might not have reliable type information, so that's not great either.

In that light, transforming the constant into some kind of tree representation designed specifically for this purpose makes a lot of sense indeed. Hopefully this can share at least something with ty::Const so we can avoid having three representations of constants in the compiler...

eddyb

comment created time in a day

pull request commentrust-lang/rust

bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds

On the next LLVM bump I am now seeing a partial rebuild, so the previous one I saw was probably a one-off hickup. Thanks!

tmiasko

comment created time in a day

issue commentrust-lang/const-eval

Why can consts not refer to statics?

@rpjohnst to be clear, your constants would not actually read from the static, they would just reference it?

I think that should be soundly possible. We even already should have the const-eval engine checks in place which ensure that you do not read through those references. The main problem however is that I do not see a good way to do such a more precise check (allow references but not reads from statics) pre-monomorphization -- so this would result in more post-monomorphization errors, which is not great.

RalfJung

comment created time in a day

issue commentether/ep_webrtc

Disabling WebRTC per default does not work as expected

I do not entirely remember what I did 6 years ago. ;) But I interpret my past self along the lines that I was unable to get the plugin version in my local installation to increase. Either this means displaying the version number is broken, or else the plugin did not update.

RalfJung

comment created time in a day

issue commentrust-lang/rust

"-Funused" is overwritten by later "-Aunused"

@AminArria thanks a lot! I would guess the most likely regression candidate is https://github.com/rust-lang/rust/pull/43522, then.

My guess would be that somewhere around here, lint groups are not handled properly. This code looks different from the previous forbid handling, though why one would treat lint groups properly and one would not is beyond me.

Cc @alexcrichton @michaelwoerister (PR author and reviewer)... but this is from 2017 so I doubt they will remember many details. ;) Cc @rust-lang/wg-diagnostics for people with lint knowledge.

RalfJung

comment created time in a day

pull request commentrust-lang/rust

rustc_session: forbid lints override regardless of position

TBH I think this is the wrong way to fix the problem. Given that the issue affects both in-code and CLI argument lint levels, I suspect that whatever fixes the former will also fix the latter. This PR adds a temporary hack that most likely can be removed again once in-code lint levels work as expected.

tobithiel

comment created time in a day

issue commentrust-lang/rust

Panic broken on Windows XP

On Linux I'd do ./x.py test --stage 0 --no-doc src/libstd. The --stage 0 avoids building the entire compiler, twice, just to run some libstd tests.

arcnmx

comment created time in a day

issue commentrust-lang/miri

Extend track alloc id to show deallocations

That's a good idea, I like it. :) Currently Miri does not necessarily know when memory gets deallocated, so this will require a new machine hook.

KrishnaSannasi

comment created time in a day

issue commentrust-lang/rust

"-Funused" is overwritten by later "-Aunused"

Note that there are two separate regressions going on:

  • The CLI argument regression in the original post, which I noticed first. I am reasonably sure that one stems from https://github.com/rust-lang/rust/pull/67885, though of course it can never hurt to double-check.
  • The regression in the handling of inline attributes that I described in https://github.com/rust-lang/rust/issues/70819#issuecomment-609450864. That one is somewhere between the 1.20 and 1.21 release, and pinning this down more precisely would be very useful indeed.
RalfJung

comment created time in 2 days

issue commentrust-lang/rust

Panic broken on Windows XP

Well as a start there is the RwLock test suite. Mutex also has one.

arcnmx

comment created time in 2 days

pull request commentwlanslovenija/tunneldigger

without automatic PMTU, tell client about static PMTU

We talked about this a while ago in https://github.com/wlanslovenija/tunneldigger/issues/62. Note that tunneldigger already has support for disabling auto-PMTU, this just improves that support.

I also think that for our use-case, automatic PMTU is rather useless: we are running a batman mesh network on top of tunneldigger, and the entire mesh is a single layer 2 domain. This means the entire mesh needs to have a single MTU. I do not see how determining precisely the MTU of each tunnel is useful when on top of that tunnel, we anyway need to work with a single MTU that works for everyone. That's why we statically configure a suitably small tunneldigger MTU in our network, which seems to work.

RalfJung

comment created time in 2 days

issue commentrust-lang/rust

CTFE keeps values in padding, breaking structural equality of const generic args.

It's a DAG (enforced by miri atm IIRC, or at least I remember @oli-obk implying that it is enforced), where sharing is an unobservable implementation optimization (same as with Ty). Therefore: tree.

Once const-code can mutate things, it's not a DAG any more but a general tree. Also, why is sharing unobservable, assuming CTFE allows raw ptr comparisons eventually?

Of course, const generics are at least as restrictive as pattern-matching, with its structural == requirement.

Oh I see, so I cannot use just any type in const generics, but only types that have certain properties? Okay that's a totally different game, then the "value domain" is even more restricted of course.

I enforcing via some validity checks that padding is "undef" is the wrong approach though. It seems much more sensible to me to have a smarter comparison function that takes the type of the to-be-compared values into account -- basically, an interpreter-level implementation of == for supported types.

eddyb

comment created time in 2 days

Pull request review commentrust-lang/rust

Use explicit promotion for constants in repeat expressions

 impl<'tcx> Visitor<'tcx> for Collector<'_, 'tcx> {     fn visit_rvalue(&mut self, rvalue: &Rvalue<'tcx>, location: Location) {         self.super_rvalue(rvalue, location); -        match *rvalue {+        match rvalue {             Rvalue::Ref(..) => {                 self.candidates.push(Candidate::Ref(location));             }-            Rvalue::Repeat(..) if self.tcx.features().const_in_array_repeat_expressions => {-                // FIXME(#49147) only promote the element when it isn't `Copy`-                // (so that code that can copy it at runtime is unaffected).-                self.candidates.push(Candidate::Repeat(location));+            Rvalue::Repeat(elem, n)+                if self.ccx.tcx.features().const_in_array_repeat_expressions =>+            {+                let is_copy = elem+                    .ty(&self.ccx.body.local_decls, self.ccx.tcx)+                    .is_copy_modulo_regions(self.ccx.tcx, self.ccx.param_env, self.span);+                let n = n.try_eval_usize(self.ccx.tcx, self.ccx.param_env);+                let length_requires_copy_or_promotion = match n {+                    // Unevaluable (e.g. too generic) -> assume > 1.+                    None => true,

So could this lead to a problem if we later figure out that actually, the constant is 1, and then we compile the program after a failed attempt to explicitly promote? (That would trigger the delayed_span_bug now.)

oli-obk

comment created time in 2 days

Pull request review commentrust-lang/rust

Use explicit promotion for constants in repeat expressions

 pub fn validate_candidates(             // and `#[rustc_args_required_const]` arguments here.              let is_promotable = validator.validate_candidate(candidate).is_ok();++            if validator.explicit && !is_promotable {+                ccx.tcx.sess.delay_span_bug(

I think we are having different views of the same thing here.

Re: your comment, I am not worried about the case where, if promotion analysis here fails, we ICE the compiler later. I am worried about the case where we do not ICE later. Because that means that, no matter whether promotion succeeds or fails, we produce a program, but the programs may do different things because we use the less conservative, "explicit promotion" rules. That is what I think this comment should explain.

oli-obk

comment created time in 2 days

issue commentrust-lang/rust

How to safely initialize an array of Vec with MaybeUninit doc example

AFAIK Rust has no guaranteed move elision, and I am afraid I don't know how well the optimizer can elide such moves in practice. This is below the layers of Rust that I am familiar with.

leonardo-m

comment created time in 2 days

Pull request review commentrust-lang/miri

More explicit build instructions

 install that exact version of rustc as a toolchain: ``` ./rustup-toolchain ```+This will set up a rustup toolchain called `miri` and set it as an override for+the current directory.  [`rustup-toolchain-install-master`]: https://github.com/kennytm/rustup-toolchain-install-master -### Fixing Miri when rustc changes+## Building and testing Miri -Miri is heavily tied to rustc internals, so it is very common that rustc changes-break Miri.  Fixing those is a good way to get starting working on Miri.-Usually, Miri will require changes similar to the other consumers of the changed-rustc API, so reading the rustc PR diff is a good way to get an idea for what is-needed.+Invoking Miri requires getting a bunch of flags right and setting up a custom+sysroot with xargo. The `miri` script takes care of that for you. With the+build environment prepared, compiling Miri is just one command away: -To update the `rustc-version` file and install the latest rustc, you can run: ```-./rustup-toolchain HEAD+./miri build ``` -Now try `./miri test`, and submit a PR once that works again.+Run `./miri` without arguments to see the other commands our build tool+supports. -## Testing the Miri driver-[testing-miri]: #testing-the-miri-driver+### Testing the Miri driver -The Miri driver in the `miri` binary is the "heart" of Miri: it is basically a-version of `rustc` that, instead of compiling your code, runs it.  It accepts-all the same flags as `rustc` (though the ones only affecting code generation-and linking obviously will have no effect) [and more][miri-flags].+The Miri driver in the `src/bin/miri.rs` binary is the "heart" of Miri: it is

I adjusted the wording, better like this?

The Miri driver compiled from src/bin/miri.rs is the "heart" of Miri:

RalfJung

comment created time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha fedca29e6979b77db1d4712dc62be041cf7f2d36

tweak wording

view details

push time in 2 days

issue commentrust-lang/rust

function pointers as match patterns have optimization-dependent behavior

I think this is basically a duplicate of https://github.com/rust-lang/rust/issues/54685, caused by unnamed_addr.

though the question of what to do about it w.r.t. patterns seems novel and worth tracking independently.

match with a constant and == are just two different ways to write a comparison. This definitely should be mentioned in the other issue but I feel separate tracking is confusing.

pnkfelix

comment created time in 2 days

issue commentrust-lang/rust

Some errors only show up with `cargo build` not `cargo check`

Or maybe it is a bad idea to emit lints during optimization, and we should move the lints from const-prop to elsewhere?

oli-obk

comment created time in 2 days

issue commentValveSoftware/steam-for-linux

Steam - all content is black

@TTimo Yes, it definitely already had the problem back then -- I didn't start steam or a few months (and before that, last time I tried, it all worked fine).

tpgxyz

comment created time in 2 days

pull request commentrust-lang/miri

add EbrCell to trophy case

@bors r+

RalfJung

comment created time in 2 days

PR opened rust-lang/miri

add EbrCell to trophy case

Thanks @Firstyear for letting me know about this :)

+1 -0

0 comment

1 changed file

pr created time in 2 days

create barnchRalfJung/miri

branch : trophy

created branch time in 2 days

pull request commentrust-lang/miri

add empty line before backtrace, to separate it from help text

@oli-obk any opinion on this?

RalfJung

comment created time in 2 days

push eventfreifunk-saar/tunneldigger

Ralf Jung

commit sha 6a96b53279b4b78df8e1587a71a71d2bd16c3140

better log messages for tunnel teardown

view details

Ralf Jung

commit sha c25f39154044e86adb19a3874bdfd20c9650ccf0

check for endpoint change on all messages, not just CREATE_TUNNEL

view details

Ralf Jung

commit sha 6179e1cd7e15bb7d8b845c9d83c1bece14497ada

remove broker_select_one; we can just use broker_select with length 1 also add some extra comments

view details

Ralf Jung

commit sha 766ec312b76e7d0beea1e9324bb4f3fd3fc554b9

show broker host+port in context-specific logs

view details

Ralf Jung

commit sha 42636519932cfdb03c304f7bbc648fb652ef1f32

broker: test for messages received on the wrong socket

view details

Ralf Jung

commit sha f4c9867c96c47fd1e158df4552550b1d279c4970

mention the new kernel requirements in the docs

view details

Ralf Jung

commit sha 4c8d6cf90f7b74b1856ba9700f22c9c54dbeb567

tweak and document default settings

view details

Ralf Jung

commit sha b85ef2ad3501e33bccd3930501b77e6c3ac3e1bb

Merge branch 'master' into server_pmtu

view details

push time in 2 days

pull request commentwlanslovenija/tunneldigger

without automatic PMTU, tell client about static PMTU

@kaechele what do you think about this? How do you handle MTUs in your network?

RalfJung

comment created time in 2 days

delete branch freifunk-saar/tunneldigger

delete branch : maxtun

delete time in 2 days

push eventwlanslovenija/tunneldigger

Ralf Jung

commit sha 4c8d6cf90f7b74b1856ba9700f22c9c54dbeb567

tweak and document default settings

view details

push time in 2 days

issue commentValveSoftware/steam-for-linux

Steam - all content is black

<deatils><summary>Ah, but I found cef_log.previous.txt.</summary>

$ cat ~/.steam/steam/logs/cef_log.previous.txt 
[1225/115038.075576:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/115039.076417:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/115040.078476:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/115041.079012:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/115042.081677:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/120145.387914:ERROR:nss_util.cc(84)] Failed to create /home/r/.pki/nssdb directory.
[1225/120147.389259:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/120148.391079:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/120149.391702:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/120150.393621:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/120151.397616:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/132454.258447:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1225/132455.285233:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/201924.274150:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/203150.609019:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/203151.610000:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/203152.611211:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/203153.612193:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/203154.613521:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0506/204041.757991:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:22
[0506/204300.662487:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:1
[0506/204421.812084:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:22
[0506/204423.932554:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/100853.397160:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/101149.037741:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111407.469091:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/111408.469691:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/111409.470293:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/111410.472389:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/111411.491853:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0508/111421.373357:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111442.290428:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111446.753945:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111446.908228:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111501.153867:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:58
[0508/111558.585767:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:108
[0508/111606.633329:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:0
[0508/111606.633508:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:252
[0508/111606.692342:WARNING:keyboard_code_conversion_x.cc(1363)] Unknown keycode:0
[0618/210736.689316:ERROR:nss_util.cc(84)] Failed to create /home/r/.pki/nssdb directory.
[0618/210812.749159:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0618/212359.411368:ERROR:gpu_process_transport_factory.cc(1029)] Lost UI shared context.
[0618/212359.502710:ERROR:nss_util.cc(83)] Failed to create /home/r/.pki/nssdb directory.
[0618/212404.379676:WARNING:crash_reporting.cc(254)] Failed to set crash key: UserID with value: 0
[0618/212404.379742:WARNING:crash_reporting.cc(254)] Failed to set crash key: BuildID with value: 1528497815
[0618/212404.379769:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[0618/212404.379793:WARNING:crash_reporting.cc(254)] Failed to set crash key: Version with value: 20180608195629
[0618/212404.379816:WARNING:crash_reporting.cc(254)] Failed to set crash key: ProductName with value: cefwebhelper
[0618/212404.379838:WARNING:crash_reporting.cc(254)] Failed to set crash key: Vendor with value: Valve
[0618/212404.963222:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[0618/212406.381520:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1110/111621.799603:ERROR:gpu_process_transport_factory.cc(1029)] Lost UI shared context.
[1110/111622.503023:WARNING:crash_reporting.cc(254)] Failed to set crash key: UserID with value: 0
[1110/111622.503062:WARNING:crash_reporting.cc(254)] Failed to set crash key: BuildID with value: 1528497815
[1110/111622.503070:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1110/111622.503077:WARNING:crash_reporting.cc(254)] Failed to set crash key: Version with value: 20180608195629
[1110/111622.503098:WARNING:crash_reporting.cc(254)] Failed to set crash key: ProductName with value: cefwebhelper
[1110/111622.503105:WARNING:crash_reporting.cc(254)] Failed to set crash key: Vendor with value: Valve
[1110/111624.033829:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1110/111624.506707:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1206/194758.642406:ERROR:gpu_process_transport_factory.cc(1029)] Lost UI shared context.
[1206/194759.358135:WARNING:crash_reporting.cc(254)] Failed to set crash key: UserID with value: 0
[1206/194759.358162:WARNING:crash_reporting.cc(254)] Failed to set crash key: BuildID with value: 1528497815
[1206/194759.358171:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1206/194759.358179:WARNING:crash_reporting.cc(254)] Failed to set crash key: Version with value: 20180608195629
[1206/194759.358186:WARNING:crash_reporting.cc(254)] Failed to set crash key: ProductName with value: cefwebhelper
[1206/194759.358193:WARNING:crash_reporting.cc(254)] Failed to set crash key: Vendor with value: Valve
[1206/194800.896317:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1206/194801.361044:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[1220/212728.652070:ERROR:gpu_process_transport_factory.cc(1029)] Lost UI shared context.
[1220/212729.448309:WARNING:crash_reporting.cc(254)] Failed to set crash key: UserID with value: 0
[1220/212729.448334:WARNING:crash_reporting.cc(254)] Failed to set crash key: BuildID with value: 1528497815
[1220/212729.448342:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1220/212729.448349:WARNING:crash_reporting.cc(254)] Failed to set crash key: Version with value: 20180608195629
[1220/212729.448357:WARNING:crash_reporting.cc(254)] Failed to set crash key: ProductName with value: cefwebhelper
[1220/212729.448364:WARNING:crash_reporting.cc(254)] Failed to set crash key: Vendor with value: Valve
[1220/212730.470163:WARNING:crash_reporting.cc(254)] Failed to set crash key: SteamUniverse with value: Public
[1220/212731.489838:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization
[0420/223339.317559:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: browser
[0420/223339.431789:ERROR:gpu_process_transport_factory.cc(1026)] Lost UI shared context.
[0420/223416.739844:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: browser
[0420/223416.757925:ERROR:gpu_process_transport_factory.cc(1026)] Lost UI shared context.
[0420/223445.968531:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223445.981282:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223445.999691:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: gpu-process
[0420/223446.455713:ERROR:nss_util.cc(83)] Failed to create /home/r/.pki/nssdb directory.
[0420/223457.696506:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223629.926146:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223743.751742:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: browser
[0420/223743.772776:ERROR:gpu_process_transport_factory.cc(1026)] Lost UI shared context.
[0420/223802.763310:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223802.795556:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: gpu-process
[0420/223804.393114:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0420/223804.894789:ERROR:nss_util.cc(83)] Failed to create /home/r/.pki/nssdb directory.
[0420/225414.334762:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer
[0421/000816.318376:INFO:crash_reporting.cc(239)] Crash reporting enabled for process: renderer

</details>

tpgxyz

comment created time in 2 days

issue commentValveSoftware/steam-for-linux

Steam - all content is black

@TTimo

See if steamwebhelper is running. ps aux --forest | grep webhelper

No, it is not:

$ ps aux --forest | grep webhelper
r         796138  0.0  0.0   6556   844 pts/3    S+   13:07   0:00  |       |   \_ grep --color=auto webhelper

Please provide ~/.steam/steam/logs/cef_log.txt

$ less ~/.steam/steam/logs/cef_log.txt
/home/r/.steam/steam/logs/cef_log.txt: No such file or directory
tpgxyz

comment created time in 2 days

issue closedwlanslovenija/tunneldigger

GSoC: Should tunneldigger participate

If you would like tthat tunneldigger participates with some ideas in GSoC this year, consider adding those ideas to this list of projects. You could list it under wlan slovenija network or some other one, whatever you prefer.

So main question is if there is anyone willing to mentor somebody else. And what are those ideas they could work on. Maybe better instrumentation, some better debugging/status printing, some things like that?

If you already know of anyone with student status who would be interested in contributing and getting payed for that a bit, they can also apply and this is valid as well.

closed time in 2 days

mitar

issue commentwlanslovenija/tunneldigger

GSoC: Should tunneldigger participate

This can probably be closed, the list of GSoC projects has long been finalized.

mitar

comment created time in 2 days

push eventfreifunk-saar/tunneldigger

Ralf Jung

commit sha 42636519932cfdb03c304f7bbc648fb652ef1f32

broker: test for messages received on the wrong socket

view details

Ralf Jung

commit sha f4c9867c96c47fd1e158df4552550b1d279c4970

mention the new kernel requirements in the docs

view details

Ralf Jung

commit sha e29e7b6ae17affbd05f9a47d1c8f12f21ecfe9f8

Merge branch 'master' into maxtun

view details

push time in 2 days

Pull request review commentwlanslovenija/tunneldigger

tweak and document default settings

 address=127.0.0.1 port=53,123,8942 ; Interface with that IP address interface=lo-; Maximum number of tunnels that will be allowed by the broker-max_tunnels=1024+; Maximum number of tunnels that will be allowed by the broker.+; On a cheap VPS, more than 256 tunnels usually do not make sense.+; Physical machines can take more.+max_tunnels=256 ; Tunnel id base tunnel_id_base=100 ; Reject connections if there are less than N seconds since the last connection. ; Can be less than a second (e.g., 0.1).-connection_rate_limit=10+connection_rate_limit=0.2

@mitar You mean something like https://github.com/wlanslovenija/tunneldigger/pull/138? :D

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Use explicit promotion for constants in repeat expressions

+// ignore-tidy-linelength+// ignore-compare-mode-nll+// compile-flags: -Z borrowck=migrate+// build-fail

Is there an issue tracking this?

oli-obk

comment created time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha b1009c4aa5356163d91ef9b30d987e1633d04add

more editing

view details

push time in 2 days

pull request commentrust-lang/miri

More explicit build instructions

So what about this?

We have a toolchain file that will automatically give them the correct nightly if they use rustup.

Not exactly (as we pin by commit, not by nightly), but we have rustup-toolchain to make that happen.

RalfJung

comment created time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha 0dd774569f7488f6e123166b5e79fe19e385712e

more editing

view details

push time in 2 days

pull request commentrust-lang/miri

More explicit build instructions

However, I am not sure if they really make sense in the "Building and testing Miri" section... they are conceptually more like setting up the build environment.

RalfJung

comment created time in 2 days

pull request commentrust-lang/miri

More explicit build instructions

@ssomers I did some more editing, please let me know what you think.

@oli-obk I'd also be interested in your feedback, I hope you are okay with these edits.

RalfJung

comment created time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha 925465ebab87af43a40a32083f9db2799364c001

more editing for CONTRIBUTING guide

view details

push time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha d0da2662883127827de16f8b1de9cef28241e210

more editing for CONTRIBUTING guide

view details

push time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha 8b0e376db862ad9f9a17bb2d78d88841c86c84c7

more editing for CONTRIBUTING guide

view details

push time in 2 days

push eventRalfJung/miri

Ralf Jung

commit sha e3b9e03fa4e73fc1638ada5cac66ed91b32c2c1b

more editing for CONTRIBUTING guide

view details

push time in 2 days

pull request commentrust-lang/miri

More explicit build instructions

I noticed myself it's not a good idea to ignore the rust-version file and "just compile with what I have"

Indeed, and somehow I hope to write the docs in a way to convey this most clearly. :)

RalfJung

comment created time in 2 days

pull request commentrust-lang/miri

More explicit build instructions

But then I don't understand why "Fixing Miri when rustc changes" comes so early, spoiling the fun before it begins.

I think I did that because I thought that might be a good on-ramping exercise for new contributors. But I do not think that any more, so I agree this should be rearranged.

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/miri

Check that shims are called with the correct number of arguments

 pub trait EvalContextExt<'mir, 'tcx: 'mir>: crate::MiriEvalContextExt<'mir, 'tcx                 this.write_null(dest)?;             }             "pthread_atfork" => {+                check_arg_count(args, 3)?;                 let _prepare = this.read_scalar(args[0])?.not_undef()?;                 let _parent = this.read_scalar(args[1])?.not_undef()?;-                let _child = this.read_scalar(args[1])?.not_undef()?;+                let _child = this.read_scalar(args[2])?.not_undef()?;

Yeah, const-generic is pretty ICE-prone... but if we restrict ourselves to the patterns libstd uses, it should not be too bad I hope. We could always fall back to a macro here.

However, please avoid this pattern:

        let mut scalars = [Scalar::<Tag>::from_u8(0); N];
        for (i, &arg) in args.iter().enumerate() {
            scalars[i] = this.read_scalar(arg)?.not_undef()?;
        }

I'd rather not risk accidentally returning the default value. This is exactly what we have TryFrom instances for.

toc-the-younger

comment created time in 2 days

Pull request review commentrust-lang/rust

Move `str` to libcore.

 impl<'rt, 'mir, 'tcx, M: Machine<'mir, 'tcx>> ValueVisitor<'mir, 'tcx, M>         fields: impl Iterator<Item = InterpResult<'tcx, Self::V>>,     ) -> InterpResult<'tcx> {         match op.layout.ty.kind {-            ty::Str => {+            // FIXME(eddyb) does this belong here?

Well you could remove that branch and then str would not be special any more in terms of validity. ;)

eddyb

comment created time in 2 days

PR opened matklad/once_cell

miri: enable leakcheck

https://github.com/rust-lang/miri/issues/940 is fixed, so we should be able to enable the leak checker now. :)

(However, we'll have to wait until https://github.com/rust-lang/rust/pull/70897 lands so that this is available via rustup.)

+1 -5

0 comment

2 changed files

pr created time in 2 days

create barnchRalfJung/once_cell

branch : miri

created branch time in 2 days

pull request commentrust-lang/rust

bump Miri

@bors retry (to get it in the queue again)

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

bump Miri

@bors retry

RalfJung

comment created time in 2 days

issue commentcrossbeam-rs/crossbeam

Memory leak from crossbeam_epoch::deferred::Deferred::new

Note that https://github.com/rust-lang/rust/pull/70897 has to land before the fix will be available via rustup.

jonhoo

comment created time in 2 days

Pull request review commentrust-lang/rfcs

RFC for unsafe blocks in unsafe fn

+- Feature Name: unsafe_block_in_unsafe_fn+- Start Date: 2018-11-04+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++No longer treat the body of an `unsafe fn` as being an `unsafe` block.  To avoid+a breaking change, this is a warning now and may become an error in a future+edition.++# Motivation+[motivation]: #motivation++Marking a function as `unsafe` is one of Rust's key protections against+undefined behavior: Even if the programmer does not read the documentation,+calling an `unsafe` function (or performing another unsafe operation) outside an+`unsafe` block will lead to a compile error, hopefully followed by reading the+documentation.++However, we currently entirely lose this protection when writing an `unsafe fn`:+If I, say, accidentally call `offset` instead of `wrapping_offset`, or if I+dereference a raw pointer thinking it is a reference, this happens without any+further notice when I am writing an `unsafe fn` because the body of an `unsafe+fn` is treated as an `unsafe` block.++For example, notice how+[this PR](https://github.com/rust-lang/rust/pull/55043/files) significantly+increased the amount of code in the thread spawning function that is considered+to be inside an `unsafe` block.++The original justification for this behavior (according to my understanding) was+that calling this function is anyway unsafe, so there is no harm done in+allowing *it* to perform unsafe operations.  And indeed the current situation+*does* provide the guarantee that a program without `unsafe` cannot be UB.+However, this neglects the other aspect of `unsafe` that I described above: To+make the programmer aware that they are treading dangerous ground even when they+may not realize they are doing so.++In fact, this double role of `unsafe` in `unsafe fn` (making it both unsafe to+call and enabling it to call other unsafe operations) conflates the two *dual*+roles that `unsafe` plays in Rust.  On the one hand, there are places that+*define* a proof obligation, these make things "unsafe to call/do" (e.g., the+language definition says that dereferencing a raw pointer requires it not to be+dangling).  On the other hand, there are places that *discharge* the proof+obligation, these are "unsafe blocks of code" (e.g., unsafe code that+dereferences a raw pointer has to locally argue why it cannot be dangling).++`unsafe {}` blocks are about *discharging* obligations, but `unsafe fn` are+about *defining* obligations.  The fact that the body of an `unsafe fn` is also+implicitly treated like a block has made it hard to realize this duality+[even for experienced Rust developers][unsafe-dual].  (Completing the picture,+`unsafe Trait` also defines an obligation, that is discharged by `unsafe impl`.+Curiously, `unsafe trait` does *not* implicitly make all bodies of default

So it would be unsound to make their default method definitions implicitly have unsafe bodies.

I think this depends on the particular definition of "unsound". unsafe is still required to cause any UB. And the boy of a fn inside an unsafe impl already does not to be manually reviewed to avoid UB elsewhere (in callers that rely on the unsafe part of the contract).

I agree with you for our conventional definition of "unsound", though.

RalfJung

comment created time in 2 days

issue commentrust-lang/miri

"cargo miri" has slightly different non-UTF-8 output than "cargo run"

I looks like cargo-miri is pretending to be rustc, so it is getting the lossy treatment.

Yeah, that is the only way we know to hook into cargo and run miri on the final crate with all the right flags.

Okay, so at least we know why this is happening. :D

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

bump Miri

Toolstate fix @bors r+ p=1

RalfJung

comment created time in 3 days

PR opened rust-lang/rust

bump Miri

r? @ghost Cc @rust-lang/miri

+1 -1

0 comment

1 changed file

pr created time in 3 days

create barnchRalfJung/rust

branch : miri

created branch time in 3 days

delete branch RalfJung/rust

delete branch : rustc-layout

delete time in 3 days

delete branch RalfJung/rust

delete branch : miri-leak-check

delete time in 3 days

delete branch RalfJung/rust

delete branch : ctfe-loop

delete time in 3 days

delete branch RalfJung/miri

delete branch : float-assoc

delete time in 3 days

issue commentrust-lang/rust

CTFE keeps values in padding, breaking structural equality of const generic args.

Not if you treat it as a constructor tree with integral leaves.

Hm... I suppose things are easier because we only have to compare values of equal types, so we don't actually need the full complexity of the "value domain".

But still, you keep talking about "trees" where if you turn the memory links into edges, you actually get a general graph. What notion would you use for graph equivalence? Two (&i32, &i32) where in one both have the same address but in the other we have two distinct shared references -- do you consider them equal?

And what about floating point leaves? NaNs are not usually equal to themselves even.

eddyb

comment created time in 3 days

delete branch RalfJung/miri

delete branch : global-leaks

delete time in 3 days

issue commentrust-lang/miri

"cargo miri" has slightly different non-UTF-8 output than "cargo run"

When I run the underlying miri driver directly, I get the expected output. So this definitely has something to do with the cargo wrapper.

@ehuss is it possible that cargo output forwarding modified the raw bytes of some non-UTF8-output of the underlying program?

RalfJung

comment created time in 3 days

issue openedrust-lang/miri

"cargo miri" has slightly different non-UTF-8 output than "cargo run"

Pointed out by @shepmaster in https://github.com/rust-lang/miri/issues/1309#issuecomment-610365682: when putting

fn main() {
    let s = unsafe { std::str::from_utf8_unchecked(&[139, 50]) };
    println!("{}", s);
}

into a cargo project and doing cargo run -q vs cargo miri run -q, the output in raw bytes differs:

$ xxd run
00000000: 8b32 0a                                  .2.
$ xxd miri
00000000: efbf bd32 0a

Looks like the "8b" turns into "ef bf bd".

created time in 3 days

issue closedrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

So it seems that somehow miri bypasses the the check for UTF8 validity when printing a str

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=393c2e1fe450d4a03e7a1d293d54d04e

It's a bit too late here for me to debug where it's happening in libstd right now.

closed time in 3 days

elichai

issue commentrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

Hm indeed, I can reproduce this even when using -q (to avoid having to remove any noise). Interesting.

I will open a new issue for that though, seems unrelated to the playground problem this here was originally about. Thanks for pointing this out! I suspect it is a cargo problem, but it is still good to know.

elichai

comment created time in 3 days

pull request commentrust-lang/miri

memory reachable through globals is not a leak

@bors r+

RalfJung

comment created time in 3 days

push eventRalfJung/miri

William Brown

commit sha 94d5eb02768fc5362bbfeff9739856aa130d7397

Update readme to make supported codo clearer

view details

JOE1994

commit sha 957ec2be10e628c0d31cfa4af7b7a26eccb89dfc

Add support for 'std::time::Instant' in Windows

view details

JOE1994

commit sha ff982b1821c6b4846c7a14053ba3a00a3f97f22b

fix incorrect error message in shim 'QueryPerformanceCounter'

view details

Youngsuk Kim

commit sha a494825d5aca389f5c6ff7407bd927a5faee35b8

Update comments in src/shims/time.rs Co-Authored-By: Ralf Jung <post@ralfj.de>

view details

Youngsuk Kim

commit sha 5157b8769f6f5196e73133a4cd3ec009823e71fd

Update comments in src/shims/time.rs Co-Authored-By: Ralf Jung <post@ralfj.de>

view details

Youngsuk Kim

commit sha f762c70b5185573112e4c897d23a29b0bf6636bd

Update comments in src/shims/time.rs Co-Authored-By: Ralf Jung <post@ralfj.de>

view details

JOE1994

commit sha d5de67a5a0719daffc9e5ed6d434c9feaf093fe7

change cfg gate to enable testing Instant subtraction in Windows

view details

William Brown

commit sha ef89525249614cd201aaa06d1652b693e9964c45

Apply feedback

view details

bors

commit sha 0e8a1a40f2c81c2318230c4d9c1947310578cbe0

Auto merge of #1294 - JOE1994:windows_instant, r=RalfJung Add support for 'std::time::Instant' in Windows Add support for creating `std::time::Instant` in Windows Includes shims for `QueryPerformanceCounter` & `QueryPerformanceFrequency` in Windows, which are both called in Windows when `std::time::Instant` is created. Windows docs page ["Acquiring high-resolution time stamps"](https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps) was helpful in learning how `QueryPerformanceCounter` & `QueryPerformanceFrequency` work. closes #1291

view details

Ralf Jung

commit sha bd9ec746a59eec97322eb7e7c24eb350ac94dba0

Rust bootstrap sysroot now has src in the same place as rust-src, so remove special hack

view details

bors

commit sha 26d7e9bd239af50baf708c2a7e38ec999de48e32

Auto merge of #1300 - RalfJung:rust-src, r=RalfJung Rust bootstrap sysroot now has src in the same place as rust-src So we can remove a special hack. I checked this locally to confirm it works. Cc https://github.com/rust-lang/rust/pull/70642 @eddyb

view details

bors

commit sha 5e7180bf469867375cfe6de957caa920f40ec488

Auto merge of #1293 - Firstyear:1289-miri-readme, r=RalfJung Update readme to make supported code clearer Fixes https://github.com/rust-lang/miri/issues/1289 This makes it clearer in the readme how miri will warn of supported or unsupported code in a program under test/run. Thanks!

view details

Ralf Jung

commit sha 73210be73baace3006e9a63b290e2356276a1173

tweak README

view details

bors

commit sha b1f053764f3bd200c4c723cfa396592b657b06c1

Auto merge of #1303 - RalfJung:readme, r=RalfJung tweak README Cc @Firstyear I realized the README has an example of unsupported code, so I changed the error to match that example.

view details

Stein Somers

commit sha e7fafa190478bfbf6dfe661d8d02dc126fd86840

Replace last_entry with last_key_value

view details

bors

commit sha ae2a811eee6b0bcf99cc1895fdc5983439d879b5

Auto merge of #1305 - ssomers:map_first_last_vs_miri, r=RalfJung Replace last_entry with last_key_value Wondering why `last_entry` was introduced (in #1156) while the alternative is shorter and seems clearer to me. Also, as the perpetrator of map_first_last, I now think that `first_entry`/`last_entry` are silly methods because they're supposed to be constant time (as opposed to `entry`), so there's no money to be made by doing multiple things with the entry.

view details

Ralf Jung

commit sha b8444deb64b1175152c98bd772a3fd445a77ac6e

test Vec::extend

view details

Ralf Jung

commit sha 9159b1eef891d35c5153b6e4027a1dd7d158e61b

test some more vec ptr invalidation

view details

Ralf Jung

commit sha ab32084ddbe1a28c3e58ab80acdb62bb520eaf6f

use mutable reference

view details

Ralf Jung

commit sha 41abcdb42262ec49495838eac38dbe2e9cd0a3ba

for consistency also rename floats.rs

view details

push time in 3 days

issue commentrust-lang/miri

miri test is painful to use with CARGO_TARGET_DIR set

@jonhoo thanks for bringing this up! I assume this would also solve the problem where I have to rm -rf target before doing cargo miri test in some other crate I am debugging. Unfortunately, I know nothing about "build profiles" and how they relate to the build cache and so on. Help would be welcome. :)

(For another target-dir issue that for some reason you do not run into, it seems, see https://github.com/japaric/xargo/issues/286.)

jonhoo

comment created time in 3 days

issue commentrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

@shepmaster I cannot reproduce this locally, both are the same here.

$ MIRI_SYSROOT=~/.cache/miri/HOST CARGO_EXTRA_FLAGS="-q" ./miri run utf8.rs 2> miri-output
$ xxd miri-output 
00000000: 5b75 7466 382e 7273 3a33 5d20 7320 3d20  [utf8.rs:3] s = 
00000010: 228b 3222 0a                             ".2".
$ rustc utf8.rs && ./utf8 2> rustc-output
$ xxd rustc-output 
00000000: 5b75 7466 382e 7273 3a33 5d20 7320 3d20  [utf8.rs:3] s = 
00000010: 228b 3222 0

What are the exact commands you used to create your two files?

elichai

comment created time in 3 days

issue commentrust-lang/rust

CTFE keeps values in padding, breaking structural equality of const generic args.

Instead, Phantom<PADDED> and Phantom<FILLED> are considered different types.

TBH, at least from a pure const-eval perspective, this seems fine to me. Actually formalizing Rust's "value domain" is a huge undertaking, and even then (ignoring const generics) I am not sure if we want to use that in const-eval.

So I think it would be acceptable if const generics used "identity of the underlying storage". But maybe I just want to avoid implementation complexity. :P

Though, on the other hand... does this mean that if we ever change the Miri engine to no longer preserve padding on copies, that would be a breaking change with const-generics? That seems quite problematic, then.

eddyb

comment created time in 3 days

pull request commentrust-lang/miri

prefer float assoc consts over std module

@bors r+

RalfJung

comment created time in 3 days

create barnchRalfJung/miri

branch : float-assoc

created branch time in 3 days

PR opened rust-lang/miri

prefer float assoc consts over std module
+35 -35

0 comment

1 changed file

pr created time in 3 days

IssuesEvent

issue commentrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

Hm, strange. The Miri code that does the printing is here:

https://github.com/rust-lang/miri/blob/master/src/shims/foreign_items/posix.rs#L68-L81

This should not do anything "weird" wrt. UTF-8. Looks like "8b" turned into "ef bf bd", whatever that means.

elichai

comment created time in 3 days

issue commentinteger32llc/rust-playground

Writing non-utf8 data to stdout suppresses compiler messages

Curiously, running the same example program in Miri does not suppress any output. Instead it prints the compiler warnings, and then the program output as

trentj

comment created time in 3 days

issue closedrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

So it seems that somehow miri bypasses the the check for UTF8 validity when printing a str

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=393c2e1fe450d4a03e7a1d293d54d04e

It's a bit too late here for me to debug where it's happening in libstd right now.

closed time in 3 days

elichai

issue commentrust-lang/miri

Running Miri on Playground does not error when printing non-UTF-8 output

Ah yes, looks like it's that (though curiously that bug seems to not affect Miri output).

Closing as duplicate of https://github.com/integer32llc/rust-playground/issues/386 then.

elichai

comment created time in 3 days

more