profile
viewpoint

dtolnay/serde-yaml 273

Strongly typed YAML library for Rust

http-rs/async-h1 97

Asynchronous HTTP/1.1 in Rust

oli-obk/camera_capture 25

Crate for capturing images from a webcam

embed-rs/embedded-rs 15

Rust embed crate

christianpoveda/sire 8

A symbolic evaluator for MIR

mbr/mealy-rs 1

Worlds smallest crate.

oli-obk/bareboard 1

Ada source code and complete sample GNAT projects for selected bare-board platforms supported by GNAT.

Lireer/ricochet-robot-solver 0

Solver for ricochet robots written in rust

Manishearth/rfcs 0

RFCs for changes to Rust

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 351f81e6c8e28ac59083880b8c631910b03b7bb8

Deploy to GitHub pages [ci skip]

view details

push time in an hour

issue commentrust-lang/compiler-team

Make lang-items private

Jup, I'll gladly do any reviews on this

doctorn

comment created time in 9 hours

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

I adjusted the incremental test in my branch

RalfJung

comment created time in 14 hours

issue commentrust-lang/rust

[tracking issue] `union` field access inside `const fn`

If we use unconst as a keyword inside const fn, we must lint on unsafe, telling the user to use unconst. We can't ban unsafe as you can already call unsafe const fns on stable, you just can't do any unconst actions within unsafe blocks or unsafe const fns.

Some concerns that come to mind:

  • It feels a little odd to have unsafe const fn and unconst blocks. I definitely don't want unconst const fn.
  • Just slapping const on a function won't work anymore if it has unsafe blocks. This is a good thing as you stated, but it's also an oddness.
  • Users can already use the word unconst, so we'd need an edition just for that keyword. What do we do with the editions before that?
  • The gains are minimal for such a major change. Ppl will just learn to use unconst instead of unsafe without thinking more about it.

Possible alternatives:

  • unsafe<const> { foo } blocks. Though this is getting into effect territory I think?
  • Don't do unconst, just reuse unsafe. I realize ppl will still screw this up, but I don't know whetherunconstwill help there.unsafeis being overused, too. Not sure if the nudging you're suggesting will help beyond annoying ppl and making them replace allunsafeinsideconst fnwithunconst`. Some mitigation strategies that are not exclusive:
    • Obviously the rustonomicon needs a chapter
    • Once we add unsafe for const fns, keep :mega: -ing out notices via all channels for a few releases that there's a new chapter in the rustonomicon.
    • We can push the work to clippy (extend https://rust-lang.github.io/rust-clippy/master/index.html#missing_safety_doc to require a CONST-SAFETY annotation if unsafe is used within const fn
oli-obk

comment created time in 15 hours

pull request commentrust-lang/rust

Miri: avoid tracking current location three times

Fixed on my branch and ran all tests this time.

RalfJung

comment created time in 17 hours

push eventoli-obk/rust

Oliver Scherer

commit sha 44227f4123a2efb366e20b2e7ff6668ab0ad03d0

Adjust incremental test

view details

push time in 17 hours

pull request commentrust-lang/rust-clippy

Ignore const fn in `or_fun_call` lint

I don't think the constness of the function by itself will give us what we want. If the function is a const fn, but has arguments, these arguments may not be constants. An example:

const fn compute_nth_prime(n: usize) -> Option<usize> {
    // super heavy logic here
}
fn foo(n: usize) -> Option<usize> {
	// Whether the function above is `const fn` or not has no effect on the cost
    // of the work done in the `or`.
	None.or(compute_nth_prime(n))
}

Thus, we'll end up actually running the function at runtime, with all the runtime effort that comes with it. If you really want to do this, you'll need to analyze the entire expression and check if it is entirely const.

I don't know of a reliable way to do this except to do it on MIR, which would be a major undertaking.

lzutao

comment created time in 17 hours

Pull request review commentrust-lang/rust-clippy

Ignore const fn in `or_fun_call` lint

 pub fn is_ctor_or_promotable_const_function(cx: &LateContext<'_, '_>, expr: &Exp         if let ExprKind::Path(ref qp) = fun.kind {             let res = cx.tables.qpath_res(qp, fun.hir_id);             return match res {+                def::Res::Def(DefKind::Fn, def_id) => rustc_mir::const_eval::is_const_fn(cx.tcx, def_id),

No, this is definitely the right way. The constness field by itself is set, even if the function's constness is unstable.

lzutao

comment created time in 17 hours

pull request commentrust-lang/rust

Ensure stack when building MIR for matches

Looks good to me. Perf is also clean. The test is a bit annoyingly big, but I can't think of anything to change here. Generating it from a proc macro is overkill.

@bors r+

nagisa

comment created time in 17 hours

pull request commentrust-lang/rust

Stabilize `#![feature(const_if_match)]`

This is waiting for someone from @rust-lang/lang starting the FCP on https://github.com/rust-lang/rust/issues/52000 as we (wg-const-eval) would like to stabilize looping at the same time as branching so ppl don't have to resort to recursion.

ecstatic-morse

comment created time in 17 hours

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 7ac1f8dd627598aa05066f83131c7d5bc28332ff

Deploy to GitHub pages [ci skip]

view details

push time in a day

pull request commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

@rust-lang/lang This PR stabilizes transmute in const eval, but still keeps it forbidden inside const fn. We already do the same thing for union field accesses. Considering that users can already do everything transmute can do, but with more boilerplate and in a more error-prone way, it seems to wg-const-eval that we should just allow transmute wherever union field accesses are allowed.

I do not know of any concerns that would speak against doing this, except for impl complexity. This PR shows all the complexity needed and is fairly minimal imo. The additional code will go away once we decide to allow transmute and union field accesses in const fn.

oli-obk

comment created time in a day

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

I pushed a fix to my repo's branch

RalfJung

comment created time in a day

push eventoli-obk/rust

Oliver Scherer

commit sha a10ac7d083d07a71c15d3c786cf2bd569f415b78

Don't intern memory in const prop. This isn't sound without validation. We don't want to report errors in case of failure to intern and validate, we just don't want to const prop. Interning and const prop is not built for this, let's not do it until we have a clearer picture on aggregate propagation.

view details

Oliver Scherer

commit sha ef005bbc593cf8ae57f9fd35cc9b782bc6138b7c

Bump codegen test

view details

push time in a day

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

Heads up @rust-lang/wg-mir-opt I changed const-prop to stop interning constants, as it was trying to do so with partially initialized aggregates. The change is https://github.com/oli-obk/rust/commit/d18a704cc55686711d202e6508414cacf7c41cc8 . Doing so had no effect on our mir-opt test suite.

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

I have a fix, you'll need to pull it from my branch again

RalfJung

comment created time in 2 days

push eventoli-obk/rust

Josh Stone

commit sha b0fb57bd8d18946787a79d1244154f2512dcf15b

impl From<Cow> for boxed slices and strings These forward `Borrowed`/`Owned` values to existing `Box::from` impls. - `From<Cow<'_, [T]>> for Box<[T]>` - `From<Cow<'_, str>> for Box<str>` - `From<Cow<'_, CStr>> for Box<CStr>` - `From<Cow<'_, OsStr>> for Box<OsStr>` - `From<Cow<'_, Path>> for Box<Path>`

view details

Josh Stone

commit sha 6d40751b37ef453bee5d8a9c47b00ef205d61738

impl From<Cow> for Rc and Arc These forward `Borrowed`/`Owned` values to existing `From` impls. impl<'a, B> From<Cow<'a, B>> for Rc<B> where B: ToOwned + ?Sized, Rc<B>: From<&'a B> + From<B::Owned>, impl<'a, B> From<Cow<'a, B>> for Arc<B> where B: ToOwned + ?Sized, Arc<B>: From<&'a B> + From<B::Owned>,

view details

Josh Stone

commit sha 23f71fe5b518c6136990f79733155b4fa1314d2b

Add tests from Cow

view details

Josh Stone

commit sha 22efd959109b9a231edbc81a8bc818eaa5763e78

Bless From<Cow> UI changes

view details

Ralf Jung

commit sha 33541d5e55c3114e01e06b27715ae04372ce027f

clarify interaction of pin drop guarantee and panics

view details

Benoît du Garreau

commit sha ef485c6fa97a562b0bc559ffbe38fee9bf1f745b

Impl Error for Infallible

view details

Kevin Per

commit sha dfbc143e65dd4dc8499f7296ddc7889854a8cc7d

Adding if to prevent borrowing suggestion in structs #71136

view details

Kevin Per

commit sha bc29f1d062feeb68207c961d254652d6bff9fd9b

Adding new test #71136

view details

Kevin Per

commit sha d232be80f82b052fd023eb2f4904ccad0aa42d7a

Fix tidy checks

view details

flip1995

commit sha 17d877cce28b22b9b345ec7ef8b14859d8b165c4

Update contributing section about syncing Clippy

view details

Steven Fackler

commit sha 2ce3f85d46edbf5105f2e93d2cbe56ad777b41e6

Tweak and stabilize AtomicN::fetch_update

view details

Philipp Krones

commit sha c1698fedeb69109f9b1aebc0bfccd9bf3112ccad

Apply suggestions from code review Co-authored-by: Phil Hansch <dev@phansch.net>

view details

Eduardo Sánchez Muñoz

commit sha 68f89fcbf982d4b2a40d3175568bef194ee4f3b7

Make `std::char` functions and constants associated to `char`.

view details

Vadim Petrochenkov

commit sha 5c6f7b32aab683276d4feb1810244ccf72bda736

Stabilize fn-like proc macros in expression, pattern and statement positions

view details

Vadim Petrochenkov

commit sha 2d10babb71f6658c39279425ec5cda11a28d3af4

Stabilize fn-like proc macros in expression, pattern and statement positions

view details

Dylan MacKenzie

commit sha 41fe5c1ca73589fe9f63f2191fd0c869e5de34d0

Update clippy lint

view details

Eduardo Sánchez Muñoz

commit sha 0e12a9d9ac6f69ddd72f2c028f668c0b55ac2eda

Try to fix doc links in new `char` methods.

view details

Steven Fackler

commit sha 31c820552350e3f686a6f353982f0f31ecbaf4a7

Update src/libcore/sync/atomic.rs Co-authored-by: Ralf Jung <post@ralfj.de>

view details

csmoe

commit sha e07f63e79a618a0c5e53a71d053da0fa0dbc6970

add testcase for issue-70818

view details

Tobias Rapp

commit sha f99344ace44abc91f76df276625e048f1e8a9536

Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983

view details

push time in 2 days

issue commentrust-lang/rust

[tracking issue] `union` field access inside `const fn`

I came to this conclusion because while &x as *const i32 as usize is unconst, it's not unsafe, but transmute::<_, usize>(&x) is unsafe and unconst. I believe that almost all unsafe operations are also unconst, because you can always craft a situation that mirrors an unconst operation.

I understand that by itself &x as *const i32 as usize is not unconst, the fact that loads of uses of that usize are unconst is the problem. So this is also a static vs dynamic checks situation. We already have all the dynamic unconst checks we need, as an unconst op is just an operation that CTFE does not support.

Maybe it's enough to just explain CTFE errors because of unconst behaviour in detail? The only "problem" is really that users of an unconst fn get the error instead of the author of the function, or am I completely overlooking a class of unconst problems here?

oli-obk

comment created time in 2 days

issue commentrust-lang/rust

[tracking issue] `union` field access inside `const fn`

Yea, I just noticed we could go even more fine-grained:

#[unconst(raw_ptr_deref)].

But this made me realize that any unsafe operation can likely end up doing unconst things in some cases... so we're back to the root problem that we'd just end up marking everything, so there's no useful distinction between unconst and unsafe.

oli-obk

comment created time in 2 days

issue commentrust-lang/rust

[tracking issue] `union` field access inside `const fn`

Slightly stupid idea: lint about all unconst operations (with the lint specifically explaining each case individually) and require users to write #[allow(unconst_ops)] on functions or items performing such actions.

This may lead to ppl just adding #![allow(unconst_ops)] to the entire crate instead, which is uncool, and I don't think hijacking the lint system to make this one lint behave differently is a good idea.

It could also be an unconditional warning that can be silenced by using #[unconst] on such a function, const item, static item or expression.

oli-obk

comment created time in 2 days

Pull request review commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

 const TRANSMUTED_U32: u32 = unsafe { mem::transmute(Foo(3)) }; const fn transmute_fn() -> u32 { unsafe { mem::transmute(Foo(3)) } } //~^ ERROR can only call `transmute` from const items, not `const fn` +const fn transmute_fn_intrinsic() -> u32 { unsafe { std::intrinsics::transmute(Foo(3)) } }+//~^ ERROR can only call `transmute` from const items, not `const fn`

:shrug: I added some

oli-obk

comment created time in 2 days

push eventoli-obk/rust

Oliver Scherer

commit sha 361d34d0872cd4b000a2c32170f02296eb8e9724

Test transmute usage more exhaustively

view details

push time in 2 days

push eventoli-obk/rust

Oliver Scherer

commit sha 79cafa7c8c5c063b83330a0be2b8e04f0cc126f5

Update src/librustc_mir/transform/qualify_min_const_fn.rs Co-authored-by: Ralf Jung <post@ralfj.de>

view details

push time in 2 days

Pull request review commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

 const TRANSMUTED_U32: u32 = unsafe { mem::transmute(Foo(3)) }; const fn transmute_fn() -> u32 { unsafe { mem::transmute(Foo(3)) } } //~^ ERROR can only call `transmute` from const items, not `const fn` +const fn transmute_fn_intrinsic() -> u32 { unsafe { std::intrinsics::transmute(Foo(3)) } }+//~^ ERROR can only call `transmute` from const items, not `const fn`

that's unaffected by const fn. It's a completely different source path that checks for that, and it completely ignores the const modifier on functions.

oli-obk

comment created time in 2 days

Pull request review commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

 fn check_terminator(                         .into(),                     ));                 }++                // HACK: This is to "unstabilize" the stabilization of the `transmute` intrinsic

that's why it's in quotes. I was hoping the rest of the text would make it clear.

oli-obk

comment created time in 2 days

push eventoli-obk/rust

Oliver Scherer

commit sha 2566b1d35a119baf1a1bf6f293a50b61ce815325

Rename feature gate test to satisfy tidy

view details

push time in 2 days

push eventoli-obk/rust

Oliver Scherer

commit sha 6227b2e3c3f446bb5c5a5d1d216f00d870fb8703

Address review comments

view details

push time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 error[E0391]: cycle detected when const-evaluating `FOO`-  --> $DIR/recursive-zst-static.rs:10:18+  --> $DIR/recursive-zst-static.rs:10:1    | LL | static FOO: () = FOO;-   |                  ^^^+   | ^^^^^^^^^^^^^^^^^^^^^

I'm guessing these sites are actually from the const_eval_raw invocation from Memory

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 error[E0391]: cycle detected when const-evaluating `FOO`-  --> $DIR/recursive-zst-static.rs:10:18+  --> $DIR/recursive-zst-static.rs:10:1    | LL | static FOO: () = FOO;-   |                  ^^^+   | ^^^^^^^^^^^^^^^^^^^^^

uhmm... InterpCx::const_eval_raw is dead code except for try_eval_const_fn_call and some use in miri that could be replaced by using const_eval instead?

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

Miri: avoid tracking current location three times

I don't think I'll be able to push this through. I could try doing it for a few queries that Miri needs, though. And anyway I figure this requires MCP so I'd first have to read up on the bureaucracy involved in that.^^

Oh I wasn't suggesting you do this, or it being done fast. Don't worry about it. I just want a path forward to exist, and you gave me one.

RalfJung

comment created time in 2 days

issue commentrust-lang/rust

Add configurable, per-item instruction limit for CTFE

That avoids changes to this limit, and indeed any changes to what this function does, from "leaking" to the callers.

I considered that, but that would mean that library authors could set a low limit to the function, get it wrong, and then callers have no control over setting the limit higher.

ecstatic-morse

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 LL | pub static mut B: () = unsafe { A = 1; };    |                                 ^^^^^ modifying a static's initial value from another static's initializer  error[E0391]: cycle detected when const-evaluating `C`-  --> $DIR/write-to-static-mut-in-static.rs:5:34+  --> $DIR/write-to-static-mut-in-static.rs:5:1    | LL | pub static mut C: u32 = unsafe { C = 1; 0 };-   |                                  ^^^^^+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

what is that span?! From the start of pub to the end of unsafe?

anyway, this should only be pointing at the C in fact, not even the C = 1

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 // build-fail  pub const unsafe fn fake_type<T>() -> T {-    hint_unreachable()+    hint_unreachable() //~ ERROR evaluation of constant value failed

:shrug: this is fine

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 error[E0391]: cycle detected when const-evaluating `FOO`-  --> $DIR/recursive-zst-static.rs:10:18+  --> $DIR/recursive-zst-static.rs:10:1    | LL | static FOO: () = FOO;-   |                  ^^^+   | ^^^^^^^^^^^^^^^^^^^^^

This is due to the fact that you're using the root_span now. The invocation of the const_eval query should be using a more precise span

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 error: any use of this value will cause an error-  --> $DIR/const_eval_limit_reached.rs:8:11+  --> $DIR/const_eval_limit_reached.rs:8:5    |-LL | / const X: usize = {-LL | |     let mut x = 0;-LL | |     while x != 1000 {-   | |           ^^^^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)-LL | |-...  |-LL | |     x-LL | | };-   | |__-+LL |  / const X: usize = {+LL |  |     let mut x = 0;+LL |  |     while x != 1000 {

Although when looking at the multi-line variant, I guess we should figure out how to make things point at the while instead of the entire while expression

RalfJung

comment created time in 2 days

Pull request review commentrust-lang/rust

Miri: avoid tracking current location three times

 LL |             n = if n % 2 == 0 { n/2 } else { 3*n + 1 };    = help: add `#![feature(const_if_match)]` to the crate attributes to enable  error[E0080]: evaluation of constant value failed-  --> $DIR/infinite_loop.rs:8:20+  --> $DIR/infinite_loop.rs:8:17    | LL |             n = if n % 2 == 0 { n/2 } else { 3*n + 1 };-   |                    ^^^^^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)+   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)

This one's ok, the previous span didn't really give the user any additional info.

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

Miri: avoid tracking current location three times

I think a better solution is to not provide the query methods on TyCtxt, and instead make people write tcx.at_dummy().query() or so.

oh I like that.

I'm not really worried about perf, but could you look into the regressed spans?

RalfJung

comment created time in 2 days

issue commentrust-lang/compiler-team

Preserve `PlaceContext` through projections

@rustbot seconded

ecstatic-morse

comment created time in 2 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha eb0581e7f40c62d896e765a701dcf7530c120ca2

Deploy to GitHub pages [ci skip]

view details

push time in 2 days

Pull request review commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

 fn check_terminator(                         .into(),                     ));                 }+                if tcx.fn_sig(def_id).abi() == RustIntrinsic+                    && tcx.item_name(def_id) == sym::transmute+                    && !feature_allowed(tcx, def_id, sym::transmute_in_const_fn)+                {+                    return Err((+                        span,+                        "can only call `transmute` from const items, not `const fn`".into(),+                    ));+                }

I noticed that, but I don't know what our const_fn feature gate story is anymore. iirc it's "the const_fn feature will go away when we merge min_const_fn into the regular const checks"?

oli-obk

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

Idk who needs to sign off on this stabilization. Technically T-libs? Hypothetically just wg-const-eval? I mean this is just removing boilerplate for users for a feature already existing via unions.

oli-obk

comment created time in 2 days

Pull request review commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

 fn check_terminator(                         .into(),                     ));                 }+                if tcx.fn_sig(def_id).abi() == RustIntrinsic+                    && tcx.item_name(def_id) == sym::transmute+                    && !feature_allowed(tcx, def_id, sym::transmute_in_const_fn)

This is the fun part. It works, but it's absolutely not scalable to more functions or intrinsics.

oli-obk

comment created time in 2 days

PR opened rust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

cc #53605 (leaving issue open so we can add transmute to const fn later)

r? @RalfJung

cc @rust-lang/wg-const-eval

+91 -82

0 comment

34 changed files

pr created time in 2 days

push eventoli-obk/rust

Tomasz Miąsko

commit sha bbb63d4554b03feee481bc799a04f183abaff1d4

Consistently use LLVM lifetime markers during codegen Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together, lifetime markers from one function might invalidate load & stores performed by the other one.

view details

ThibsG

commit sha 945c9447093a2ca944e70bae125f2af69f8eac16

Merge `block_in_if_condition_expr` and `block_in_if_condition_stmt` lints into `block_in_if_condition` lint

view details

ThibsG

commit sha 6cbdd1e49dbb2355ac1036946a5a635e22023c6f

Merge `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` lints into `map_unwrap` lint

view details

ThibsG

commit sha bcf61666bd903c0d13c081cf222b423e45cd854e

Merge `option_unwrap_used` and `result_unwrap_used` lints into `unwrap_used` lint

view details

ThibsG

commit sha 0e8be599cd04a8566224c63eeb07f5fa04605702

Merge `option_expect_used` and `result_expect_used` lints into `expect_used` lint

view details

ThibsG

commit sha adbdf7549c6b24c37629eabdc4be0346e0c8fd56

Merge `for_loop_over_option` and `for_loop_over_result` lints into `for_loop_over_fallible` lint

view details

Nathan Corbyn

commit sha f6aa161936887bf4a0aaebbd5cfc743132a1ab0b

Don't ICE on missing `Unsize` impl

view details

Dylan DPC

commit sha b20b200d2edc22a97d8bf6a1621f37eacd9bc008

Rollup merge of #71910 - mibac138:necessary-paren, r=cuviper Fix unused_parens false positive when using binary operations Fixes #71290 r? @cuviper who provided instructions

view details

Dylan DPC

commit sha 2e65f7bc1f9e0cfab801672874655224ead8deed

Rollup merge of #72087 - matthewjasper:regionck-hang, r=nikomatsakis Fix hang in lexical_region_resolve Regionck was stuck in a loop where a region value was changing between two equal regions. Closes #72051

view details

Dylan DPC

commit sha 96caa257c3c1cd597280b1c205ccca977268c5be

Rollup merge of #72126 - nnethercote:change-WorkProduct-saved_files, r=alexcrichton Change `WorkProduct::saved_files` to an `Option`. Because there is at most one file. r? @bjorn3

view details

Dylan DPC

commit sha 746b8ca083395fbad72d2eb110157ae316e0d480

Rollup merge of #72127 - jademcgough:long-error-explanation-E0228, r=petrochenkov add long error explanation for E0228 Add long explanation for the E0228 error code Part of #61137 Let me know if this is wrong at all (or can be written more clearly), I'm still learning Rust.

view details

Dylan DPC

commit sha d732aeff914b9c3bf53ba1857ead33745c00c88a

Rollup merge of #72141 - kornelski:dontsleep, r=joshtriplett Warn against thread::sleep in async fn I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](https://github.com/rust-lang/rust-clippy/issues/4377), but the std docs could warn against it too.

view details

Dylan DPC

commit sha 62f184030ab9da2c3acd95d3f7f94c4bc1820b07

Rollup merge of #72170 - lcnr:lang_item, r=oli-obk use `require_lang_item` over `unwrap`. Does not yet replace all uses of `lang_items\(\)\.*\.unwrap\(\)`, as there are more than I expected :sweat_smile: Fixes #72099 r? @RalfJung *edit: The goal of this this PR is to change ICE from missing lang items to a fatal error.*

view details

Dylan DPC

commit sha d7f5e56498bffa50813fbdd34623501c8f5b0a5c

Rollup merge of #72191 - GuillaumeGomez:cleanup-e0589, r=Dylan-DPC Clean up E0589 explanation r? @Dylan-DPC

view details

Dylan DPC

commit sha 7b5bc61e99ea77ff87233295fc3e789e43dd66f0

Rollup merge of #72194 - doctorn:dispatch-from-dyn-ice, r=estebank Don't ICE on missing `Unsize` impl Previously code of the form ```rust #![feature(unsize, dispatch_from_dyn)] use std::marker::Unsize; use std::ops::DispatchFromDyn; pub struct Foo<'a, T: ?Sized> { _inner: &'a &'a T, } impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} ``` would generate an ICE due to the missing `Unsize` impl being run through the `suggest_change_mut` suggestion. This PR adds an early exit and a pointer to the appropriate docs regarding `Unsize` instead: ``` error[E0277]: the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied --> src/test/ui/issues/issue-71036.rs:11:1 | 11 | impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T` | = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information = note: required because of the requirements on the impl of `std::ops::DispatchFromDyn<&'a &'a U>` for `&'a &'a T` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. ``` r? @estebank Resolves #71036

view details

David Tolnay

commit sha 95399f8f941b89785c6e9d94e0bc32ff5d43ba06

Downgrade useless_let_if_seq to nursery

view details

sergey-melnychuk

commit sha 0dc74dc0c6beb0bf2fd4fcc32cf3461a07f44521

cleanup stale FIXME(#64197)

view details

Tyler Mandry

commit sha 15c22922989774cb2102fc5c52f078f0f899cc62

Don't pass --dynamic-linker for Fuchsia dylibs This was causing a PT_INTERP header in Fuchsia dylibs (implying that they're executable when they're not).

view details

bors

commit sha a74d1862d4d87a56244958416fd05976c58ca1a8

Auto merge of #72202 - Dylan-DPC:rollup-6lbxh1s, r=Dylan-DPC Rollup of 8 pull requests Successful merges: - #71910 (Fix unused_parens false positive when using binary operations) - #72087 (Fix hang in lexical_region_resolve) - #72126 (Change `WorkProduct::saved_files` to an `Option`.) - #72127 (add long error explanation for E0228) - #72141 (Warn against thread::sleep in async fn) - #72170 (use `require_lang_item` over `unwrap`.) - #72191 (Clean up E0589 explanation) - #72194 (Don't ICE on missing `Unsize` impl) Failed merges: r? @ghost

view details

Vardan Margaryan

commit sha 94e4b5ec316993200d75276b4e7c16a059bf3a57

Add the redundant_wildcard_enum_match lint

view details

push time in 2 days

issue commentrust-lang/rust

Tracking Issue For Using std::mem::transmute() In Constants

I'm creating a new stabilization PR to show the workarounds needed to allow such a split. We can then decide whether we'll take on that technical debt.

TheDarkula

comment created time in 2 days

issue commentrust-lang/const-eval

Heap allocations in constants

yes. I am working on https://github.com/rust-lang/const-eval/pull/43 that helps us organize which features depend on which other features. Once we have that we can discuss the roadmap for const features and when everyone is on the same page, start working on RFCing these features.

oli-obk

comment created time in 2 days

issue commentrust-lang/rust

Add configurable, per-item instruction limit for CTFE

It should be easy to make this work on const fn, as we can just fetch the attribute at push_stack_frame time and add it to the current limit. If the value is chosen too big, this will just blow up the limit though. Also it would make shrinking the value a breaking change.

Maybe what would make more sense is to add it to the current limit and revert to the previous step value after executing a function that has a limit override. This way both the function can enable itself to be easier to execute, and the user can bump the value futher in case the function screwed up the limit.

ecstatic-morse

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

let's continue any further discussion in #53605

oli-obk

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

Ah, trying that I now remember what the problem is:

we declare intrinsics to be stable by adding the rustc_const_stable attribute to them... There's no concept for undoing that just for const fn. I can add a specific check just for const fn, but if we plan on doing more of these, we'll need a new attribute.

oli-obk

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize `transmute` in constants and statics but not const fn

Before we do that we should probably get rid of the extra min_const_fn logic, and instead integrating its checks into the new const checking infrastructure.

Oh well, we could just do it in min_const_fn :/ yea no need to block it. I'll rebase this and fix it up

oli-obk

comment created time in 2 days

pull request commentrust-lang/rust

Miri: avoid tracking current location three times

I did this for a few reasons:

  1. No accidental forgetting to use TyCtxtAt for queries, giving us better query cycle errors. This is not tested on CI, so you won't see if we regressed that
  2. Kinda hoping for more usage of TyCtxtAt in other APIs, improving query cycle errors further
  3. More precise errors (you regressed a bunch of errors to much more general spans).
  4. ecx.tcx is used a lot, I wanted using it to be as cheap as possible.

I'd prefer working on 2. than doing this PR

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

InstCombine: Don't optimize `&mut *x` into `x`

@bors r+

jonas-schievink

comment created time in 2 days

pull request commentrust-lang/rust

InstCombine: Don't optimize `&mut *x` into `x`

Yes it is cgu partitioning: https://perf.rust-lang.org/detailed-query.html?commit=ee7813f5ca0f5a520184f18081c777da904cd1d5&base_commit=4b1f86adbe41e8dd4864ca2315f43953dd503bb5&benchmark=script-servo-opt&run_name=incr-patched:%20println

jonas-schievink

comment created time in 2 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 42445e1883e314bf6ff25c8ec6d7b820427289cc

Deploy to GitHub pages [ci skip]

view details

push time in 3 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 7a672119ce5f16f07cc98671e3c5c501c7c0f942

Deploy to GitHub pages [ci skip]

view details

push time in 4 days

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

still can't push. I now pushed my commit to https://github.com/oli-obk/rust/tree/deaggregate-is-cleanup

RalfJung

comment created time in 4 days

delete branch rust-lang/rust

delete branch : jonas-schievink-patch-1

delete time in 4 days

delete branch rust-lang/rust

delete branch : jonas-schievink-patch-2

delete time in 4 days

create barncholi-obk/rust

branch : deaggregate-is-cleanup

created branch time in 4 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

           StorageLive(_1);                 // scope 0 at $DIR/aggregate.rs:5:9: 5:10           StorageLive(_2);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24           StorageLive(_3);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:22-          _3 = (const 0i32, const 1i32, const 2i32); // scope 0 at $DIR/aggregate.rs:5:13: 5:22+          (_3.0: i32) = const 0i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000000))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:14: 5:15                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000000)) }+          (_3.1: i32) = const 1i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000001))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:17: 5:18                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000001)) }+          (_3.2: i32) = const 2i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000002))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:20: 5:21                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000002)) }--         _2 = (_3.1: i32);                // scope 0 at $DIR/aggregate.rs:5:13: 5:24--         _1 = Add(move _2, const 0i32);   // scope 0 at $DIR/aggregate.rs:5:13: 5:28-+         _2 = const 1i32;                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24

you need to check the box on the right allowing edits or give me access to your repo in order for me to push

RalfJung

comment created time in 4 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

           StorageLive(_1);                 // scope 0 at $DIR/aggregate.rs:5:9: 5:10           StorageLive(_2);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24           StorageLive(_3);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:22-          _3 = (const 0i32, const 1i32, const 2i32); // scope 0 at $DIR/aggregate.rs:5:13: 5:22+          (_3.0: i32) = const 0i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000000))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:14: 5:15                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000000)) }+          (_3.1: i32) = const 1i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000001))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:17: 5:18                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000001)) }+          (_3.2: i32) = const 2i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000002))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:20: 5:21                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000002)) }--         _2 = (_3.1: i32);                // scope 0 at $DIR/aggregate.rs:5:13: 5:24--         _1 = Add(move _2, const 0i32);   // scope 0 at $DIR/aggregate.rs:5:13: 5:28-+         _2 = const 1i32;                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24

I can't do this locally without your PR. There's no way to produce the relevant MIR without your PR :(

I believe it should get fixed by changing https://github.com/rust-lang/rust/blob/4b1f86adbe41e8dd4864ca2315f43953dd503bb5/src/librustc_mir/transform/const_prop.rs#L790-L803 to change ConstPropMode to OnlyInsideOwnBlock if it currently is FullConstProp.

RalfJung

comment created time in 4 days

issue openedrust-lang/rust

ICE on unmonomorphized const generics in const eval: eval_const_to_op: Unexpected ConstKind

Amusingly the following ICEs while https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=67ee1b8218865042e272d1c2c1aa22fe has a compiler error that hints at the const generic actually getting resolved.

#![feature(const_generics)]
#![allow(incomplete_features)]
struct Arr<const N: usize>
where Assert::<{N < usize::max_value() / 2}>: IsTrue,
{
}

enum Assert<const CHECK: bool> {}

trait IsTrue {}

impl IsTrue for Assert<true> {}

fn main() {
    let x: Arr<{usize::max_value()}> = Arr {};
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error: internal compiler error: src/librustc_mir/interpret/operand.rs:548: eval_const_to_op: Unexpected ConstKind Const { ty: usize, val: Bound(DebruijnIndex(0), 0) }

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:907:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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

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

note: rustc 1.45.0-nightly (74e804683 2020-05-30) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 --crate-type bin

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

error: aborting due to previous error

error: could not compile `playground`.

To learn more, run the command again with --verbose.

created time in 4 days

issue commentrust-lang/rust

There's currently no way to specify bounds requiring constants in types to be well-formed

@Evrey what you're asking for is already possible:

struct Arr<T, const N: usize>
where T: Sized,
      Assert::<{N <= (usize::max_value() / std::mem::size_of::<T>())}>: IsTrue,
{
    data: [T; N],
}

enum Assert<const COND: bool> {}

trait IsTrue {}

impl IsTrue for Assert<true> {}

The problem lies elsewhere. It's that failure to evaluate the constant expression won't be linked to the fact that the user messed up the generic parameters:

#![feature(const_generics)]
#![allow(incomplete_features)]
struct Arr<const N: usize>
where Assert::<{N + N}>: IsValid,
{
}

enum Assert<const CHECK: usize> {}

trait IsValid {}

impl<const CHECK: usize> IsValid for Assert<CHECK> {}

fn main() {
    let x: Arr<{usize::max_value()}> = Arr {};
}

What we want to be able to avoid is having to work around this by writing

#![feature(const_generics)]
#![allow(incomplete_features)]
struct Arr<const N: usize>
where Assert::<{N < usize::max_value() / 2}>: IsTrue,
{
}

enum Assert<const CHECK: bool> {}

trait IsTrue {}

impl IsTrue for Assert<true> {}

fn main() {
    let x: Arr<{usize::max_value()}> = Arr {};
}

(which ICEs the compiler right now, I'm opening an issue for that)

varkor

comment created time in 4 days

delete branch oli-obk/rust

delete branch : mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein

delete time in 5 days

delete branch oli-obk/rust

delete branch : min_const_fn

delete time in 5 days

delete branch oli-obk/rfcs

delete branch : const_looping

delete time in 5 days

delete branch oli-obk/rfcs

delete branch : big_bold_letters

delete time in 5 days

delete branch oli-obk/rfcs

delete branch : const_locals

delete time in 5 days

push eventrust-lang/const-eval

Ralf Jung

commit sha cab4825596c25373a6c663bc2b895c8de98a29a1

promotion tweaks

view details

Oliver Scherer

commit sha 887386504ef65ac9affcf663d48ff58524be19a7

Merge pull request #41 from RalfJung/promotion promotion tweaks

view details

push time in 5 days

PR merged rust-lang/const-eval

promotion tweaks

I felt like the concerns here could be made slightly more explicit.

+11 -7

1 comment

1 changed file

RalfJung

pr closed time in 5 days

Pull request review commentrust-lang/const-eval

describe static vs dynamic const checks

+# Static and dynamic checks++This repository describes a set of rules that various forms of compile-time evaluated code needs to satisfy.+The compiler contains two kinds of checks that guard against violations of these rules: static checks and dynamic checks.++## Dynamic checks++Dynamic checks are conceptually very simple: when evaluating the compile-time code, we look at what it does, and if what it does violates the rules, we halt evaluation.+Thus, a dynamic check generally makes it very clear what is being protected against.++The main disadvantage of dynamic checks is that they can only run when the compile-time code is being evaluated, which is after monomorphization.+We generally try to avoid post-monomorphization errors as they make for a bad user experience.
We generally try to avoid post-monomorphization errors as they inherently make for a bad user experience.
While there are technical aspects that could be improved here, the main problem is that the site where the error is reported is disconnected from the site where the root cause is.
Such problems can be observed when creating an associated constant that uses associated constants from generic parameters.
These generic parameters are unknown, so the usage of these associated constants may cause errors depending on the *value* of the generic parameter's associated constants.
RalfJung

comment created time in 5 days

pull request commentrust-lang/rust

Return early to avoid ICE

@bors r=estebank

We actually have to fix clippy in tree nowadays as CI is blocked on it. src/tools/clippy is synchronized with the clippy repo independently of anything happening here

JohnTitor

comment created time in 5 days

Pull request review commentrust-lang/rust

Return early to avoid ICE

 pub fn implements_trait<'a, 'tcx>(     trait_id: DefId,     ty_params: &[GenericArg<'tcx>], ) -> bool {+    // Do not check on infer_types to avoid panic in evaluate_obligation.+    if ty.has_infer_types() {+        return false;+    }+    let ty = cx.tcx.erase_regions(&ty);

correct

JohnTitor

comment created time in 5 days

issue commentrust-lang/rust

`InstCombine` can incorrectly deinitialize locals that are later used

Maybe we should stop making instcombine convert &*some_mut_ref to some_mut_ref? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use Copy or Move on such values in general.

Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.

jonas-schievink

comment created time in 5 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 81f80d54052636ce8ed5e3f3135d0a7626006fb0

Deploy to GitHub pages [ci skip]

view details

push time in 5 days

Pull request review commentrust-lang/rust

Constify most non-trait `Duration` methods as described in #72440

+// run-pass++#![feature(const_panic)]+#![feature(const_if_match)]+#![feature(duration_consts_2)]+#![feature(div_duration)]++use std::time::Duration;++fn duration() {+    const ZERO : Duration = Duration::new(0, 0);+    assert_eq!(ZERO, Duration::from_secs(0));++    const ONE : Duration = Duration::new(0, 1);+    assert_eq!(ONE, Duration::from_nanos(1));++    const MAX : Duration = Duration::new(u64::MAX, 1_000_000_000 - 1);++    const MAX_ADD_ZERO : Option<Duration> = MAX.checked_add(ZERO);+    assert_eq!(MAX_ADD_ZERO, Some(MAX));++    const MAX_ADD_ONE : Option<Duration> = MAX.checked_add(ONE);+    assert_eq!(MAX_ADD_ONE, None);++    const ONE_SUB_ONE : Option<Duration> = ONE.checked_sub(ONE);+    assert_eq!(ONE_SUB_ONE, Some(ZERO));++    const ZERO_SUB_ONE : Option<Duration> = ZERO.checked_sub(ONE);+    assert_eq!(ZERO_SUB_ONE, None);++    const ONE_MUL_ONE : Option<Duration> = ONE.checked_mul(1);+    assert_eq!(ONE_MUL_ONE, Some(ONE));++    const MAX_MUL_TWO : Option<Duration> = MAX.checked_mul(2);+    assert_eq!(MAX_MUL_TWO, None);++    const ONE_DIV_ONE : Option<Duration> = ONE.checked_div(1);+    assert_eq!(ONE_DIV_ONE, Some(ONE));++    const ONE_DIV_ZERO : Option<Duration> = ONE.checked_div(0);+    assert_eq!(ONE_DIV_ZERO, None);++    const MAX_AS_F32 : f32 = MAX.as_secs_f32();+    assert_eq!(MAX_AS_F32, u64::MAX as f32 + 0.000_000_000_1);

oh darn. I didn't notice that typo at all

marmeladema

comment created time in 5 days

Pull request review commentrust-lang/rust

Constify most non-trait `Duration` methods as described in #72440

+// run-pass++#![feature(const_panic)]+#![feature(const_if_match)]+#![feature(duration_consts_2)]+#![feature(div_duration)]++use std::time::Duration;++fn duration() {+    const ZERO : Duration = Duration::new(0, 0);+    assert_eq!(ZERO, Duration::from_secs(0));++    const ONE : Duration = Duration::new(0, 1);+    assert_eq!(ONE, Duration::from_nanos(1));++    const MAX : Duration = Duration::new(u64::MAX, 1_000_000_000 - 1);++    const MAX_ADD_ZERO : Option<Duration> = MAX.checked_add(ZERO);+    assert_eq!(MAX_ADD_ZERO, Some(MAX));++    const MAX_ADD_ONE : Option<Duration> = MAX.checked_add(ONE);+    assert_eq!(MAX_ADD_ONE, None);++    const ONE_SUB_ONE : Option<Duration> = ONE.checked_sub(ONE);+    assert_eq!(ONE_SUB_ONE, Some(ZERO));++    const ZERO_SUB_ONE : Option<Duration> = ZERO.checked_sub(ONE);+    assert_eq!(ZERO_SUB_ONE, None);++    const ONE_MUL_ONE : Option<Duration> = ONE.checked_mul(1);+    assert_eq!(ONE_MUL_ONE, Some(ONE));++    const MAX_MUL_TWO : Option<Duration> = MAX.checked_mul(2);+    assert_eq!(MAX_MUL_TWO, None);++    const ONE_DIV_ONE : Option<Duration> = ONE.checked_div(1);+    assert_eq!(ONE_DIV_ONE, Some(ONE));++    const ONE_DIV_ZERO : Option<Duration> = ONE.checked_div(0);+    assert_eq!(ONE_DIV_ZERO, None);++    const MAX_AS_F32 : f32 = MAX.as_secs_f32();+    assert_eq!(MAX_AS_F32, u64::MAX as f32 + 0.000_000_000_1);

f64::EPSILON is the smallest value you can add to 1.0 that will change the float.

I'm assuming that the 0.000_000_000_1 here is supposed to attempt the same: add a very small value to the result of this conversion and check whether that addition changes anything.

marmeladema

comment created time in 5 days

Pull request review commentrust-lang/rust

Constify most non-trait `Duration` methods as described in #72440

+// run-pass++#![feature(const_panic)]+#![feature(const_if_match)]+#![feature(duration_consts_2)]+#![feature(div_duration)]++use std::time::Duration;++fn duration() {+    const ZERO : Duration = Duration::new(0, 0);+    assert_eq!(ZERO, Duration::from_secs(0));++    const ONE : Duration = Duration::new(0, 1);+    assert_eq!(ONE, Duration::from_nanos(1));++    const MAX : Duration = Duration::new(u64::MAX, 1_000_000_000 - 1);++    const MAX_ADD_ZERO : Option<Duration> = MAX.checked_add(ZERO);+    assert_eq!(MAX_ADD_ZERO, Some(MAX));++    const MAX_ADD_ONE : Option<Duration> = MAX.checked_add(ONE);+    assert_eq!(MAX_ADD_ONE, None);++    const ONE_SUB_ONE : Option<Duration> = ONE.checked_sub(ONE);+    assert_eq!(ONE_SUB_ONE, Some(ZERO));++    const ZERO_SUB_ONE : Option<Duration> = ZERO.checked_sub(ONE);+    assert_eq!(ZERO_SUB_ONE, None);++    const ONE_MUL_ONE : Option<Duration> = ONE.checked_mul(1);+    assert_eq!(ONE_MUL_ONE, Some(ONE));++    const MAX_MUL_TWO : Option<Duration> = MAX.checked_mul(2);+    assert_eq!(MAX_MUL_TWO, None);++    const ONE_DIV_ONE : Option<Duration> = ONE.checked_div(1);+    assert_eq!(ONE_DIV_ONE, Some(ONE));++    const ONE_DIV_ZERO : Option<Duration> = ONE.checked_div(0);+    assert_eq!(ONE_DIV_ZERO, None);++    const MAX_AS_F32 : f32 = MAX.as_secs_f32();+    assert_eq!(MAX_AS_F32, u64::MAX as f32 + 0.000_000_000_1);

or are you asking why not u64::EPSILON?

marmeladema

comment created time in 5 days

Pull request review commentrust-lang/rust

Constify most non-trait `Duration` methods as described in #72440

+// run-pass++#![feature(const_panic)]+#![feature(const_if_match)]+#![feature(duration_consts_2)]+#![feature(div_duration)]++use std::time::Duration;++fn duration() {+    const ZERO : Duration = Duration::new(0, 0);+    assert_eq!(ZERO, Duration::from_secs(0));++    const ONE : Duration = Duration::new(0, 1);+    assert_eq!(ONE, Duration::from_nanos(1));++    const MAX : Duration = Duration::new(u64::MAX, 1_000_000_000 - 1);++    const MAX_ADD_ZERO : Option<Duration> = MAX.checked_add(ZERO);+    assert_eq!(MAX_ADD_ZERO, Some(MAX));++    const MAX_ADD_ONE : Option<Duration> = MAX.checked_add(ONE);+    assert_eq!(MAX_ADD_ONE, None);++    const ONE_SUB_ONE : Option<Duration> = ONE.checked_sub(ONE);+    assert_eq!(ONE_SUB_ONE, Some(ZERO));++    const ZERO_SUB_ONE : Option<Duration> = ZERO.checked_sub(ONE);+    assert_eq!(ZERO_SUB_ONE, None);++    const ONE_MUL_ONE : Option<Duration> = ONE.checked_mul(1);+    assert_eq!(ONE_MUL_ONE, Some(ONE));++    const MAX_MUL_TWO : Option<Duration> = MAX.checked_mul(2);+    assert_eq!(MAX_MUL_TWO, None);++    const ONE_DIV_ONE : Option<Duration> = ONE.checked_div(1);+    assert_eq!(ONE_DIV_ONE, Some(ONE));++    const ONE_DIV_ZERO : Option<Duration> = ONE.checked_div(0);+    assert_eq!(ONE_DIV_ZERO, None);++    const MAX_AS_F32 : f32 = MAX.as_secs_f32();+    assert_eq!(MAX_AS_F32, u64::MAX as f32 + 0.000_000_000_1);

that's what clippy suggests as the format for float literals

marmeladema

comment created time in 5 days

pull request commentrust-lang/rust

bump Miri, update for cargo-miri being a separate project

@bors p=1

RalfJung

comment created time in 5 days

pull request commentrust-lang/rust

bump Miri, update for cargo-miri being a separate project

@bors r+

RalfJung

comment created time in 5 days

push eventoli-obk/rust

Oliver Scherer

commit sha 0aa7f4d2f2ff55b8cfe5de5e4e7665a8fdeaf050

Make TLS accesses explicit in MIR

view details

push time in 6 days

push eventoli-obk/rust

Glenn Hope

commit sha 152cdcb45be7a8f0f24dbcd4177e0858d94516b6

Remove unnecessary field, check for Mod/Fn ItemKind

view details

Glenn Hope

commit sha 4db6abcd50eb07a7fa8349a059f80792b7b19a2e

Remove check for Fn, reflect this in test cases, make test cases more robust/explicit

view details

Glenn Hope

commit sha a339766136a183327faaf13b987be30b2940872e

Fix test from auto-formatter fix

view details

Glenn Hope

commit sha 0ba61c612ee873314d252ca1f747c14a2f0161ba

Check is_macro inside check_exceptions, update references to fix test

view details

Glenn Hope

commit sha b69200b8468434bc3f5b9ef8468733e5d40f4e01

Move is_test_module check to top of function

view details

bors

commit sha 43a1777b89cf6791f9e20878b4e5e3ae907867a5

Auto merge of #5564 - MrAwesome:master, r=flip1995 Allow `use super::*;` glob imports changelog: Allow super::* glob imports fixes #5554 fixes #5569 A first pass at #5554 - this allows all `use super::*` to pass, which may or may not be desirable. The original issue was around allowing test modules to import their entire parent modules - I'm happy to modify this to do that instead, may just need some guidance on how to implement that (I played around a bit with #[cfg(test)] but from what I can gather, clippy itself isn't in test mode when running, even if the code in question is being checked for the test target).

view details

Bastian Kauschke

commit sha bb6a6e08325a38f735b4806f5146e0d6a3fa687f

move `ty::List` into a new submodule

view details

Marko Mijalkovic

commit sha b6e4581937dff28f4534e393907124182fb791d0

Add mipsel-sony-psp target

view details

Bastian Kauschke

commit sha a8c152dfc921e8ec2c00f65e7c731197e522a96d

add regression tests + improve method name

view details

Marko Mijalkovic

commit sha 20a66913233589208934d155491c75157947e03e

Update stdarch

view details

Marko Mijalkovic

commit sha 8961b083762d3660ca21110836b547e8b3f19022

Formatting

view details

bors

commit sha 0a3619c9e51a16d08cfd9a825cb89c6a49f80ffc

Auto merge of #69530 - Aaron1011:perf/skip-coerce-var, r=nikomatsakis [perf] Skip attempting to run coerce_unsized on an inference variable See the included comment for a detailed explanation of why this is sound.

view details

bors

commit sha 6f5c7827b71d1e1e4831fa7522e49acaf2a9e44e

Auto merge of #71557 - matthewjasper:mir-asymmetric-or-pattern, r=oli-obk Fix ICE for broken or-pattern in async fn closes #71297

view details

Alex Crichton

commit sha c7bd5a635ebef6520a2d7373973726b034345026

Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006

view details

bors

commit sha b3269536d0a883caa0904cf6589aa1310ff70b5e

Auto merge of #72020 - alexcrichton:fix-incremental-linker-plugin-lto, r=oli-obk Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006

view details

bors

commit sha 8d16eeb8c9a8d6d85130b15ec9bd26df55773b12

Auto merge of #71775 - petrochenkov:crtcfg, r=matthewjasper Enable `cfg` predicate for `target_feature = "crt-static"` only if the target supports it That's what all other `target_feature`s do.

view details

YI

commit sha a6c2f73b6e0d24af5396355886b26bb23885c37e

add linking option strip move strip option to "Z" add more strip options, remove strip-debuginfo-if-disabled merge strip and debuginfo

view details

Trevor Spiteri

commit sha 0ceacd022c326dadfc65e5cffcde28449c3d735a

doc: minus (U+2212) instead of dash (U+002D) for negative infinity

view details

Ralf Jung

commit sha c82103cb21942b171c2fe135d0a32be620113e47

use min_specialization for some rustc crates where it requires no changes

view details

Ralf Jung

commit sha 62353071af2dd3a731892a951352acb26809eacf

Rollup merge of #71840 - matthewjasper:drop-trees, r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed, the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme, because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.

view details

push time in 6 days

pull request commentrust-lang/rust

Make TLS accesses explicit in MIR

I rebased the PR

oli-obk

comment created time in 6 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha ea9eba23e52d5855b26522d90052326008b1ca72

Deploy to GitHub pages [ci skip]

view details

push time in 6 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

           StorageLive(_1);                 // scope 0 at $DIR/aggregate.rs:5:9: 5:10           StorageLive(_2);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24           StorageLive(_3);                 // scope 0 at $DIR/aggregate.rs:5:13: 5:22-          _3 = (const 0i32, const 1i32, const 2i32); // scope 0 at $DIR/aggregate.rs:5:13: 5:22+          (_3.0: i32) = const 0i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000000))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:14: 5:15                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000000)) }+          (_3.1: i32) = const 1i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000001))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:17: 5:18                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000001)) }+          (_3.2: i32) = const 2i32;        // scope 0 at $DIR/aggregate.rs:5:13: 5:22                                            // ty::Const                                            // + ty: i32                                            // + val: Value(Scalar(0x00000002))                                            // mir::Constant                                            // + span: $DIR/aggregate.rs:5:20: 5:21                                            // + literal: Const { ty: i32, val: Value(Scalar(0x00000002)) }--         _2 = (_3.1: i32);                // scope 0 at $DIR/aggregate.rs:5:13: 5:24--         _1 = Add(move _2, const 0i32);   // scope 0 at $DIR/aggregate.rs:5:13: 5:28-+         _2 = const 1i32;                 // scope 0 at $DIR/aggregate.rs:5:13: 5:24

ok thanks, this makes it clear what the problem is, I'll look into what the solution is.

RalfJung

comment created time in 7 days

push eventoli-obk/cargo_metadata

Matthias Krüger

commit sha 419a9b15ac57497107fd98129a1547ebd7790965

deps: bump semver from 0.9 to 0.10

view details

Oliver Scherer

commit sha f9d8073c90e2a9254af290313d9118bbeb5fc179

Merge pull request #115 from matthiaskrgr/semver_up deps: bump semver from 0.9 to 0.10

view details

push time in 7 days

PR merged oli-obk/cargo_metadata

deps: bump semver from 0.9 to 0.10

This will allow us to bump semver in clippy, it currently conflicts because cargo-metadata still requires 0.9 instead of 0.10.

+2 -2

0 comment

2 changed files

matthiaskrgr

pr closed time in 7 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha 5bac24d7f85af7bb089d5ae925f2812bb555ed7e

Deploy to GitHub pages [ci skip]

view details

push time in 7 days

pull request commentrust-lang/miri

Move cargo-miri into separate package

@bors r+

RalfJung

comment created time in 8 days

pull request commentrust-lang/rust

Clippy should always build

@bors r+

Mark-Simulacrum

comment created time in 8 days

Pull request review commentrust-lang/miri

Move cargo-miri into separate package

 [package]-authors = ["Scott Olson <scott@solson.me>"]-description = "An experimental interpreter for Rust MIR."+authors = ["Miri Team"]

nope

RalfJung

comment created time in 8 days

push eventoli-obk/fixmeh

Oliver Scherer

commit sha f250af72678e611c71cd4dbe30749341d09d668a

Deploy to GitHub pages [ci skip]

view details

push time in 8 days

PR closed rust-lang/rust

Add a feature gate for allowing integers as the address of references in constants S-waiting-on-author

implementation for #63197

cc @rust-lang/wg-const-eval

+75 -10

10 comments

7 changed files

oli-obk

pr closed time in 8 days

pull request commentrust-lang/rust

Add a feature gate for allowing integers as the address of references in constants

Closing after https://github.com/rust-lang/rust/issues/63197#issuecomment-634538553 has convinced me that this is the wrong thing to do and we should instead suggest raw pointers once raw borrows are stable and thus a viable alternative.

oli-obk

comment created time in 8 days

issue commentrust-lang/rust

Miri interning: what to do with dangling pointers?

We can just keep failing early and wait until someone has an actual use case

RalfJung

comment created time in 9 days

issue commentrust-lang/rust

Const validation rejects references that might be dangling (but could actually be valid at run-time)

If there are no dereferences of a reference anywhere in the code, is the compiler still permitted to insert a read?

axos88

comment created time in 9 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

Ok, so from my perspective, we should totally merge this. I don't think we need to explain in the docs why looking at the bits of a TypeId is a bad idea. If we did that, we'd have to explain it for all other types, too.

KodrAus

comment created time in 9 days

pull request commentrust-lang/rust

WF-check all ty::Const's, not just array lengths.

@bors try @rust-timer queue

lcnr

comment created time in 9 days

pull request commentrust-lang/rust

Added a codegen test for a recent optimization for overflow-checks=on

@bors r+ rollup

alex

comment created time in 9 days

more