profile
viewpoint
Eduard-Mihai Burtescu eddyb @LykenSol Bucharest, Romania Senior Compiler/PL Engineer

alexcrichton/rustc-demangle 92

Rust symbol demangling

eddyb/cprep 12

C/C++ preprocessor.

Centril/rfc-effects 8

Preparing an RFC on effect polymorphism in Rust with focus on 'const'

eddyb/aoc 2

Advent of Code solutions in Rust

eddyb/bootstrap 2

HTML, CSS, and JS toolkit from Twitter

eddyb/hematite 2

A simple Minecraft written in Rust with the Piston game engine

eddyb/1ml 0

1ML prototype interpreter

eddyb/cargo 0

The Rust package manager

eddyb/clap-rs 0

A full featured, fast Command Line Argument Parser for Rust

delete branch eddyb/rfcs

delete branch : mangling-underscore-escaping

delete time in 7 hours

push eventeddyb/rfcs

gnzlbg

commit sha ec42fd0b7fbc0448d1794bfecaa43621eab76814

RFC: mem::black_box and mem::clobber

view details

gnzlbg

commit sha 68b4dde8c709a07a8dcdbae9703e26ec6492b10c

black_box stores back to memory, not registers

view details

gnzlbg

commit sha 76c213bc535cbac30315a6a6aefaad1530216536

target_feature 1.1

view details

gnzlbg

commit sha 54083aa88085767ed0629bcab074eb21bb4c00d9

add perf implications

view details

gnzlbg

commit sha 2fec554e5fb428c86f5cac42f61c00bb232e9de7

fmt

view details

gnzlbg

commit sha f9d49051d184bf32a36e4efa6c60036756d79ab6

soundness

view details

gnzlbg

commit sha 39e03e3da8ca9c47cffed4803550823860685301

fmt

view details

gnzlbg

commit sha aa79d09670dda105e9775411caa31bc2d06b2be1

fix bug in reference; add unresolved question about disabling features

view details

gnzlbg

commit sha b73fc95e60d6635e012b1eaf52bdd544f1833596

effect system

view details

gnzlbg

commit sha 96c3abbf9021551f3cf4fe9a58bf2dfae64b2a78

update effects text

view details

gnzlbg

commit sha 48f4616c3d4d4ef7642468a10485a7d2fc9f1cb2

clarify hierarchies

view details

newpavlov

commit sha 800825ccd0f5db7f58a063395dfd02b5b228bb60

msrv

view details

newpavlov

commit sha 4ec9682a9f2c2697eedbdb06350fa5701fd0e862

drawbacks update

view details

Artyom Pavlov

commit sha f9057da774a1b5fe4dc33f7658fd89f6d024d083

reviews updates

view details

Artyom Pavlov

commit sha a43e9e13055f90b728cdccf46c78a463786806c2

kennytm's review updates

view details

Artyom Pavlov

commit sha 00a3022176ce22c4c51e75baefdab8756874fc17

fixes, option addition, wording improvements - fixed typo and RFC link - improved wording a bit - added `--check-msrv-toolchain` option ( @phaylon )

view details

varkor

commit sha b0bf8c5d5ba4310db3157dc13459ec1aa562476a

impl_trait_type_aliases

view details

varkor

commit sha 1082efdde798691903bd9fc849f6276ac59525a3

Correct some typos and make polymorphic type clearer

view details

varkor

commit sha d6db251443e0dd395d9b7ca8810c69dad99d7059

Mention `impl Trait` type aliases in associated types

view details

varkor

commit sha c62791c7a0b29d6e52977c9a6648b2b29303c302

Forbid compound `impl Trait` type aliases

view details

push time in 7 hours

pull request commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

r? @nagisa for LLVM (I wish we had GH teams specifically for review roles so I don't have to guess)

eddyb

comment created time in 8 hours

push eventeddyb/measureme

Michael Woerister

commit sha f96d3aa20c9bfecf314594771509ac13ff3be846

Fix typo in comment.

view details

Michael Woerister

commit sha e3a06d7af6248a690940b5c5c3726806309261e1

Update gitignore file.

view details

Michael Woerister

commit sha d31bbe260aa5bc2dc9da2aa2190ba93e5116baf1

Get rid rust-analyzer warning about shorthand struct initialization.

view details

Michael Woerister

commit sha 1c4fd85f3e2ea0dcca77ed9e106e46eb36929b2a

Add a CI check that all crates in the workspace have a consistent version.

view details

Michael Woerister

commit sha 86617c7dfc79d29731f9ee5844113a449fc8ba17

Make regex version_checker more robust.

view details

Wesley Wiser

commit sha 38e462d1d015d73dc8b08c325fb45bb6ca1f5125

Merge pull request #130 from michaelwoerister/better-version-checks Add a CI check that all crates in the workspace have a consistent version

view details

Michael Woerister

commit sha cd3e70fb8491bfbdc35520edc7319b1e6d9db610

Extend FileSerializationSink to support in-memory storage and use this instead of ByteVecSink.

view details

Michael Woerister

commit sha 77c6869fec65ae4cc083982c15da38712dfbc99f

Remove the MmapSerializationSink.

view details

Michael Woerister

commit sha 603f0c9db01e28733ebe941065f7669543d9eb26

Remove the generic SerializationSink parameter from Profiler.

view details

Michael Woerister

commit sha b4097fc1eaa57c7fe568cd0a4aea3b1f97a0bc31

Remove the generic SerializationSink parameter from StringTableBuilder.

view details

Michael Woerister

commit sha b74043c2b2394abc9dd3bdcf9e97f0fbaa27bb6d

Remove the SerializationSink trait.

view details

Michael Woerister

commit sha e5add84857479a472b82b3de36add29662a15eac

Rename FileSerializationSink to just SerializationSink, now that there is a single kind.

view details

Michael Woerister

commit sha 4303a6d52d247f015f37ea655775ef4b2c2ce759

Add clarifying comment to BackingStorage::drain_bytes().

view details

Wesley Wiser

commit sha 40a26b642a62dd06c935af36dab4a81098dfe88f

Merge pull request #131 from michaelwoerister/remove_serialization_sink_trait Remove the SerializationSink trait

view details

Michael Woerister

commit sha ce632523facabe74649f67bceb769876728e15aa

Turn serialization::BackingStorage into enum instead of a trait with two impls.

view details

Michael Woerister

commit sha 1825a06d998175d63139005b0f2b95268a1de9bc

Implement paged serialization approach. This allows to store all data in a single file instead of three separate ones.

view details

Tyler Mandry

commit sha 440331eed5adbef2529b6825ed1248646e041054

stack-collapse -> stack_collapse in README Fix naming

view details

Wesley Wiser

commit sha 662d00db8a19a25e2d805042e5371131e852c3f2

Merge pull request #133 from tmandry/patch-1 stack-collapse -> stack_collapse in README

view details

Michael Woerister

commit sha 410bcafbbc75336b3c4f3d7a4e03990cb1c51725

Update file header handling for paged data format.

view details

Florian Gilcher

commit sha 0d6725ed91e8c531645ea8fdbf5cf723bcef252d

Fix typo: profilng -> profiling

view details

push time in 21 hours

Pull request review commentrust-lang/rust

Suggest adding missing braces in `const` block pattern

 impl<'a> Parser<'a> {             })         } else if self.eat_keyword(kw::Unsafe) {             self.parse_block_expr(None, lo, BlockCheckMode::Unsafe(ast::UserProvided), attrs)-        } else if self.check_inline_const() {-            self.parse_const_expr(lo.to(self.token.span))+        } else if self.eat_keyword(kw::Const) {

The difference is that unsafe just modifies the block expression, whereas const needs to create the ExprKind::Const - but maybe it doesn't have to be too complicated shrug.

camelid

comment created time in a day

PullRequestReviewEvent

issue commentrust-lang/rust

ICE: const-generics-demangling.rs

Why is #[rustc_symbol_name] applied to an impl? impls don't have symbol names, the ICE is the same one for this:

#![feature(rustc_attrs)]

struct Foo;
#[rustc_symbol_name]
impl Foo {}
matthiaskrgr

comment created time in a day

pull request commentrust-lang/rust

fix def collector for impl trait

@bors r+

lcnr

comment created time in a day

create barncheddyb/measureme

branch : rdpmc

created branch time in 2 days

push eventeddyb/measureme

Eduard Burtescu

commit sha ef25949adf2717e1176745ec9afbf6fe4bba9bd1

summarize: add "aggregate" sub-command for analyzing sets of profiles.

view details

push time in 2 days

pull request commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

I saw eval_to_allocation_raw being slower for ctfe-stress-4.

Yeah, I was referring to everything other than ctfe-stress-4 (which, if it has MIR optimizations enabled, may necessarily get slowed down because MIR inlining is now more accurate).

eddyb

comment created time in 2 days

pull request commentrust-lang/rust

WIP: Compile rustc crates with the initial-exec TLS model

If we're going to go that far, I would rather just see this mechanism fixed to make the TLS model depend on the top-level artifact(s)

Oh yeah I forgot I wanted that too (should be possible, based on my experiments an rlib crate is undecided between static and dynamic TLS until it's linked into a bin crate, or a dylib crate, respectively) and went down the rabbit hole of thinking about tracking which crates define #[thread_local] statics.

joshtriplett

comment created time in 2 days

pull request commentrust-lang/rust

WIP: Compile rustc crates with the initial-exec TLS model

This may be silly, but, if we want to exactly track which crates are using TLS, so that we can list them out in the wrapper, we could:

  • have an allow-by-default lint against using #[thread_local] (including from thread_local!)
  • pass -Fthread-local from the bootstrap/bin/rustc.rs wrapper by default for all crates
    • specifically using "forbid" means #[allow(thread_local)] wouldn't work so it couldn't be accidentally used
  • for an explicit list of crates, we would omit -Fthread-local
    • the subset of that which ends up linked into librustc_driver-*.so, also get -Ztls-model=initial-exec

This could get confusing so we might want to make it an internal rustc::untracked_thread_local lint that has a custom message telling you to what list to add the crate etc.

joshtriplett

comment created time in 2 days

Pull request review commentrust-lang/rust

WIP: Compile rustc crates with the initial-exec TLS model

 fn main() {         {             cmd.arg("-C").arg("panic=abort");         }++        // Compile rustc crates with the more efficient initial-exec TLS model.+        // This doesn't work with `dlopen`, so we can't use it by default in+        // general, but we can use it for rustc's own internal libraries.+        if crate_name.map_or(false, |n| n.starts_with("rustc_") || n.starts_with("rustc-")) {+            cmd.arg("-Z").arg("tls-model=initial-exec");+        }

I wonder if we should also check that the path includes compiler/rustc_ because there's some stuff on crates.io that also starts with rustc_ or rustc- and it might not be strictly a rustc_driver dependency.

joshtriplett

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentalexcrichton/rustc-demangle

Elide the type when the const value is a placeholder `p`

 impl<'a, 'b, 's> Printer<'a, 'b, 's> {         }          let ty_tag = parse!(self, next);++        if ty_tag == b'p' {+            // We don't encode the type if the value is a placeholder.+            self.out.write_str("_")?;+            return Ok(());+        }+         if !supported_const_generic_type(ty_tag) {             invalid!(self);         } -        if self.eat(b'p') {-            self.out.write_str("_")?;-        } else {-            match ty_tag {-                // Unsigned integer types.-                b'h' | b't' | b'm' | b'y' | b'o' | b'j' => self.print_const_uint()?,-                // Signed integer types.-                b'a' | b's' | b'l' | b'x' | b'n' | b'i' => self.print_const_int()?,-                // Bool.-                b'b' => self.print_const_bool()?,-                // Char.-                b'c' => self.print_const_char()?,--                // This branch ought to be unreachable.-                _ => invalid!(self),-            };-        }+        match ty_tag {+            // Unsigned integer types.+            b'h' | b't' | b'm' | b'y' | b'o' | b'j' => self.print_const_uint()?,+            // Signed integer types.+            b'a' | b's' | b'l' | b'x' | b'n' | b'i' => self.print_const_int()?,+            // Bool.+            b'b' => self.print_const_bool()?,+            // Char.+            b'c' => self.print_const_char()?,++            // This branch ought to be unreachable.+            _ => invalid!(self),+        };

This can all be simplified by removing supported_const_generic_type.

I had some ideas for simplifying all of this code by removing the skip_ vs print_ split, given how much cleaner that made the C port, so I wouldn't worry about duplication.

varkor

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentalexcrichton/rustc-demangle

Add support for `min_const_generics` constants

 impl<'a, 'b, 's> Printer<'a, 'b, 's> {         }         v.fmt(self.out)     }++    fn print_const_int(&mut self) -> fmt::Result {+        if self.eat(b'n') {+            self.out.write_str("-")?;+        }++        self.print_const_uint()+    }++    fn print_const_bool(&mut self) -> fmt::Result {+        match parse!(self, hex_nibbles).as_bytes() {+            b"0" => self.out.write_str("false"),+            b"1" => self.out.write_str("true"),+            _ => invalid!(self),+        }+    }++    fn print_const_char(&mut self) -> fmt::Result {+        let hex = parse!(self, hex_nibbles);++        // Valid `char`s fit in `u32`.+        if hex.len() > 8 {+            invalid!(self);+        }++        let mut v = 0;+        for c in hex.chars() {+            v = (v << 4) | (c.to_digit(16).unwrap() as u32);+        }+        if let Some(c) = char::from_u32(v) {+            write!(self.out, "'{}'", c)

This should use "{:?}" so that you get e.g. '\n' instead of literally a newline in the output etc.

varkor

comment created time in 2 days

PullRequestReviewEvent

pull request commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

Does ctfe-stress-4 enable MIR inlining? Because in that case, that might make some sense.

The slight slowdowns don't reflect in the self-profile data, so I don't know where they're coming from.

But I think we can finally land this. cc @rust-lang/wg-mir-opt for a review of the MIR side and @nagisa for the LLVM parts.

eddyb

comment created time in 2 days

pull request commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

Given what I'm hearing about scopes in promoteds, this should be better now: @bors try @rust-timer queue

eddyb

comment created time in 3 days

push eventeddyb/rust

Eduard-Mihai Burtescu

commit sha 9b21c50335887fe9ecbd44d5a3efa105feae0a6d

rustc_mir: create the Integrator as soon as possible in MIR inlining.

view details

Eduard-Mihai Burtescu

commit sha aff4d3e659872ec1fbf469e91575a9a711ce4705

rustc_mir: run the MIR inlining Integrator on the whole callee body at once.

view details

push time in 3 days

push eventeddyb/rust

Jonas Schievink

commit sha 389f7cf7d6c333b490e208bcbda3406b9e0ef437

Rollup merge of #76745 - workingjubilee:move-wrapping-tests, r=matklad Move Wrapping<T> ui tests into library Part of #76268 r? @matklad

view details

Jonas Schievink

commit sha ccc020ab42b4209940b821ba4fd0e1240d3f7561

Rollup merge of #77182 - GuillaumeGomez:missing-examples-fd-traits, r=pickfire Add missing examples for Fd traits Not sure what happened here... This is a reopening of #77142 r? @Dylan-DPC

view details

Jonas Schievink

commit sha 65228686649c68f491d3b763e9dde52c23fea9d7

Rollup merge of #77251 - dtolnay:drop, r=Aaron1011 Bypass const_item_mutation if const's type has Drop impl Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation. ```rust struct Log { msg: &'static str } const LOG: Log = Log { msg: "" }; impl Drop for Log { fn drop(&mut self) { println!("{}", self.msg); } } LOG.msg = "wow"; // prints "wow" ``` r? @Aaron1011

view details

Jonas Schievink

commit sha 01ca8299d48df39a1567ec39f9768d8fcb69ce7f

Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio, r=dtolnay Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing. This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154, this should make output a little bit more efficient.

view details

Jonas Schievink

commit sha 23408de992598d89bf6ed697b4b86bbefc0f2df0

Rollup merge of #77421 - petrochenkov:globtravel, r=nagisa Revert "resolve: Avoid "self-confirming" import resolutions in one more case" And remove the assert that https://github.com/rust-lang/rust/pull/70236 tried to avoid instead. Closes https://github.com/rust-lang/rust/issues/74556.

view details

Jonas Schievink

commit sha eff63980142872227dcd66bf429f7337b1b68c31

Rollup merge of #77452 - Mark-Simulacrum:fix-symbol-v0, r=eddyb Permit ty::Bool in const generics for v0 mangling This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway). Fixes #76365 (well, it will, but seems fine to close as soon as we have support) r? @eddyb (for mangling) but I'm okay with some other reviewer too :)

view details

bors

commit sha 6ebad43c255e63ac0734646fe817de5780d76b45

Auto merge of #77470 - jonas-schievink:rollup-9a2hulp, r=jonas-schievink Rollup of 8 pull requests Successful merges: - #75377 (Fix Debug implementations of some of the HashMap and BTreeMap iterator types) - #76107 (Write manifest for MAJOR.MINOR channel to enable rustup convenience) - #76745 (Move Wrapping<T> ui tests into library) - #77182 (Add missing examples for Fd traits) - #77251 (Bypass const_item_mutation if const's type has Drop impl) - #77264 (Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. ) - #77421 (Revert "resolve: Avoid "self-confirming" import resolutions in one more case") - #77452 (Permit ty::Bool in const generics for v0 mangling) Failed merges: r? `@ghost`

view details

Stein Somers

commit sha d71d13e82d5a7cb3037a70d2ac18453db6dacca7

BTreeMap: refactoring around edges, missed spots

view details

Camelid

commit sha 21fb9dfa8d49d6aa3e74dfcc7032badcd6f51b91

Use old error when there's partial resolution The new error was confusing when there was partial resolution (something like `std::io::nonexistent`); the old one is better for those cases.

view details

Valerii Lashmanov

commit sha d1d2184db407dbdc0a0872c9efb4ff58457e1c9a

SsoHashSet/Map - genericiy over Q removed Due to performance regression, see SsoHashMap comment.

view details

bors

commit sha 8c54cf67c1bdae93ecef9791dc07c0982bb76041

Auto merge of #77451 - Mark-Simulacrum:bump-version, r=pietroalbini Bump version to 1.49.0 r? `@pietroalbini`

view details

Jubilee Young

commit sha c47caeaaa9011fa4dd56d7e7b0ef341a0419b378

Macro-expand test to cover all possible lanes

view details

Camelid

commit sha aa9b718cf0d4157a81c5dcc8d59f2c4ed96b801e

Improve error messages

view details

bors

commit sha 6f56fbdc1c58992a9db630f5cd2ba9882d32e84b

Auto merge of #77347 - jyn514:dox, r=Amanieu Remove --cfg dox from rustdoc.rs This was added in https://github.com/rust-lang/rust/pull/53076 because several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`). I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think this is now safe to remove. r? `@Mark-Simulacrum` cc `@QuietMisdreavus` :)

view details

Ralf Jung

commit sha e27ef130c1d1cc7d8c3779a4e66e413a7a943ad4

grammar nit

view details

Guillaume Gomez

commit sha e6027a42e109fef10f4fc27ebede50d1b3d203f0

Add `unclosed_html_tags` lint

view details

Guillaume Gomez

commit sha 5fcbf4668ecab0ff798ea076757e27760c90aff5

Add doc for invalid_html_tag lint

view details

Guillaume Gomez

commit sha bc6ec6fe36c5c902da900fea67cba30fad4b0b6b

Add test for unclosed_html_tag lint

view details

Guillaume Gomez

commit sha 6271a0a46dedd5eaf3eb26afb6ae536939496cd7

Improve invalid_html_tags lint span

view details

Guillaume Gomez

commit sha f9a65afb27e0093b56053f810952efcba3e718e5

Make invalid_html_tags lint only run on nightly and being allowed by default

view details

push time in 3 days

pull request commentrust-lang/rust

Separate unsized locals

r? @pnkfelix (as per #72029 and #74971)

spastorino

comment created time in 3 days

Pull request review commentrust-lang/rust

Separate unsized locals

 use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKi use rustc_middle::ty::Ty; use rustc_span::Span; use rustc_trait_selection::traits;+use std::mem;  pub(super) struct GatherLocalsVisitor<'a, 'tcx> {     fcx: &'a FnCtxt<'a, 'tcx>,     parent_id: hir::HirId,+    // params are special cases of pats, but we want to handle them as+    // *distinct* cases. so track when we are hitting a pat *within* an fn+    // param.

params -> parameters, pat -> pattern

spastorino

comment created time in 3 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Allow making `RUSTC_BOOTSTRAP` conditional on the crate name

@rfcbot reviewed

Doing it through the bot so I can say this: I disagree with doing anything here other than forcing distros' hand to adapt to something like https://github.com/rust-lang/compiler-team/issues/350#issuecomment-698372654 which would even allow them to compile some problematic (for now? hopefully there's a transition path...) packages with "unstable rustc for version 1.45" as opposed to "stable rustc 1.45 + RUSTC_BOOTSTRAP".

The important thing is that they would have control, and have to choose to exert it, over what gets to even use "unstable rustc", instead of being able to take any random stable rustc and make it unstable.

jyn514

comment created time in 3 days

Pull request review commentrust-lang/rust

Separate unsized fn params from unsized locals

 impl<'a, 'tcx> Visitor<'tcx> for GatherLocalsVisitor<'a, 'tcx> {         intravisit::walk_local(self, local);     } +    fn visit_param(&mut self, param: &'tcx hir::Param<'tcx>) {+        self.within_fn_param = true;+        intravisit::walk_param(self, param);+        self.within_fn_param = false;+    }+     // Add pattern bindings.     fn visit_pat(&mut self, p: &'tcx hir::Pat<'tcx>) {         if let PatKind::Binding(_, _, ident, _) = p.kind {             let var_ty = self.assign(p.span, p.hir_id, None); -            if !self.fcx.tcx.features().unsized_locals {-                self.fcx.require_type_is_sized(var_ty, p.span, traits::VariableType(p.hir_id));+            if self.within_fn_param {+                if !self.fcx.tcx.features().unsized_fn_params {+                    self.fcx.require_type_is_sized(var_ty, p.span, traits::SizedArgumentType(None));+                }+            } else {+                if !self.fcx.tcx.features().unsized_locals {+                    self.fcx.require_type_is_sized(var_ty, p.span, traits::VariableType(p.hir_id));+                }             }

(summarizing my discussion with @spastorino on Zulip) I think a bigger issue than special-casing the shape of the pattern, is that within_fn_param applies recursively to every nested pattern in a fn parameter, instead of to the parameter pattern itself.

So my suggestion is to replace it with a "shallow" version (bikeshed name: outermost_fn_param_pat) that visit_pat temporarily sets back to false around its walk_pat call, so that the #![feature(unsized_fn_params)] path is only taken for fn parameters themselves, not any other patterns nested in them.

JohnTitor

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/rust

Do not ICE with TraitPredicates containing [type error]

 impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> {                 &predicate.subst(tcx, substs),                 &mut obligations,             );-            obligations.push(Obligation {-                cause: cause.clone(),-                recursion_depth,-                param_env,-                predicate,-            });+            if predicate.references_error() {

Couldn't this check be done here: https://github.com/rust-lang/rust/blob/a85e94927622665a9e9022de0d33a890a2e32d43/compiler/rustc_trait_selection/src/traits/codegen/mod.rs#L123-L125

It's not obvious that there's any need to prevent errors from propagating in impl_or_trait_obligations, whereas turning an ICE into a delay_span_bug when .references_error(), in the snippet I linked, seems more natural.

But I don't care too strongly about this I don't think.

estebank

comment created time in 4 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Lift: take self by value

I have nothing against this change, FWIW.

lcnr

comment created time in 5 days

Pull request review commentrust-lang/rust

Lift: take self by value

 CloneTypeFoldableAndLiftImpls! { // FIXME(eddyb) replace all the uses of `Option::map` with `?`. impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>> Lift<'tcx> for (A, B) {     type Lifted = (A::Lifted, B::Lifted);-    fn lift_to_tcx(&self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {-        tcx.lift(&self.0).and_then(|a| tcx.lift(&self.1).map(|b| (a, b)))+    fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {+        let (a, b) = self;+        tcx.lift(a).and_then(|a| tcx.lift(b).map(|b| (a, b)))     } }  impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>, C: Lift<'tcx>> Lift<'tcx> for (A, B, C) {     type Lifted = (A::Lifted, B::Lifted, C::Lifted);-    fn lift_to_tcx(&self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {-        tcx.lift(&self.0)-            .and_then(|a| tcx.lift(&self.1).and_then(|b| tcx.lift(&self.2).map(|c| (a, b, c))))+    fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {+        let (a, b, c) = self;+        tcx.lift(a).and_then(|a| tcx.lift(b).and_then(|b| tcx.lift(c).map(|c| (a, b, c))))

If you're going to rewrite these, you can use ? nowadays. E.g. Some((tcx.lift(a)?, tcx.lift(b)?, tcx.lift(c)?))

lcnr

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Lift: take self by value

 impl<'cx, 'tcx> dataflow::ResultsVisitor<'cx, 'tcx> for MirBorrowckCtxt<'cx, 'tc                 // "Lift" into the tcx -- once regions are erased, this type should be in the                 // global arenas; this "lift" operation basically just asserts that is true, but                 // that is useful later.-                tcx.lift(&drop_place_ty).unwrap();+                tcx.lift(drop_place_ty).unwrap();

Yeah, I don't know what this did but it should be unnecessary. cc @nikomatsakis

lcnr

comment created time in 5 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Fix control flow check for breaking with diverging values

r? @nikomatsakis

varkor

comment created time in 5 days

pull request commentrust-lang/rust

normalize substs while inlining

@bors r+

lcnr

comment created time in 5 days

pull request commentrust-lang/rust

fix def collector for impl trait

@bors r+

lcnr

comment created time in 5 days

PullRequestReviewEvent

pull request commentrust-lang/rust

mangling: mangle impl params w/ v0 scheme

r=me though I'm not sure what's wrong with CI

davidtwco

comment created time in 9 days

PullRequestReviewEvent

issue commentjlgreathouse/AMD_IBS_Toolkit

Zen workaround missing for Zen 2 (which is also affected by SpecLockMap).

because IBS Op sampling only samples fully retired ops

Sadly it does seem to affect the "retired instructions" counter, so I guess it's not as "fully" retired as what IBS sees.

In any case, thanks for taking the time to respond! (I believe this might be the first time we heard back from anyone at AMD regarding the whole SpecLockMap saga, at all - then again, I don't think there was any attempt at grabbing anyone's attention, so no surprises there, heh)

And you can tell I'm also bad with notifications lately, didn't notice your reply until now.

eddyb

comment created time in 9 days

issue commentrust-lang/rust

Implementation detail exposed in short backtrace (RUST_BACKTRACE=1)

This would go away if lang_start would be generic over main's type as F: FnOnce() -> R instead of taking a fn pointer, right? If you use -Z symbol-mangling-version=v0, you can see that the "inlined sometimes" call_once is <fn() as core::ops::function::FnOnce<()>>::call_once, i.e. the shim for calling a fn pointer via FnOnce.

One nice thing would that is we could theoretically allow varying not just main's return type, but also argument counts/types (which frankly I don't know why it hasn't come up before?).

solson

comment created time in 15 days

issue commentrust-lang/rust

Add `-Zrandomize-layout` flag to better detect code that rely on unspecified behavior related to memory layout

@marmeladema It's pretty much all in rustc_middle::ty::layout. Wherever field offsets are computed (univariant_uninterned), you can, for example, add the final alignment to all of the field offsets - this will increase the size of the whole type but keep all fields correctly aligned (and it's slightly simpler than changing field order, which has to be done similarly to how we sort fields by alignment). You should be able to PM if you have more questions.

If you rely on the same flag to be passed across all the crates, or if you record what the choices were when a certain crate was contained (you could look at how -Z symbol-mangling-version is handled), you should be able to avoid problems with cross-crate consistency, which as per https://github.com/rust-lang/rust/issues/77316#issuecomment-701367977 was my main worry.

marmeladema

comment created time in 16 days

pull request commentrust-lang/rust

Don't run `resolve_vars_if_possible` in `normalize_erasing_regions`

I know what it's for (normalize may create inference variables), I'm just surprised it doesn't seem to be needed.

jyn514

comment created time in 17 days

pull request commentrust-lang/rust

Let backends access span information

@bors r+

khyperia

comment created time in 17 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Force posix-style quoting on lld, independent of host platform

@bors r+

Mark-Simulacrum

comment created time in 19 days

PullRequestReviewEvent

pull request commentrust-lang/rust

fix def collector for impl trait

@bors r+

lcnr

comment created time in 19 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Support signed integers and `char` in v0 mangling

 impl Printer<'tcx> for SymbolMangler<'tcx> {         }         let start = self.out.len(); -        match ct.ty.kind() {-            ty::Uint(_) => {}-            ty::Bool => {}+        let mut neg = false;+        let val = match ct.ty.kind() {+            ty::Uint(_) | ty::Bool | ty::Char => {+                ct.try_eval_bits(self.tcx, ty::ParamEnv::reveal_all(), ct.ty)+            }+            ty::Int(_) => {+                neg = true;+                ct.val

neg = true doesn't seem right when the value could be positive.

varkor

comment created time in 19 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/rust

fix def collector for impl trait

 impl<'a, 'hir> intravisit::Visitor<'hir> for HirIdValidator<'a, 'hir> {         // we are currently in. So for those it's correct that they have a         // different owner.     }++    fn visit_generic_param(&mut self, param: &'hir hir::GenericParam<'hir>) {+        if let hir::GenericParamKind::Type {+            synthetic: Some(hir::SyntheticTyParamKind::ImplTrait),+            ..+        } = param.kind+        {+            // Do nothing because bodging is fun.

This needs a comment like visit_impl_item_ref, explaining that synthetic generics from impl Trait are HIR ID owners.

lcnr

comment created time in 19 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

fix def collector for impl trait

 impl Generics<'hir> { #[derive(HashStable_Generic)] pub enum SyntheticTyParamKind {     ImplTrait,+    // Created by the `#[rustc_synthetic]` attribute.+    Rustc,

I'd call this RustcSyntheticAttr if you want to include Rustc in the name.

lcnr

comment created time in 19 days

PullRequestReviewEvent

pull request commentrust-lang/rust

fix def collector for impl trait

@bors rollup=never (this is turning into something that may have sharp edge cases)

lcnr

comment created time in 19 days

Pull request review commentrust-lang/rust

fix def collector for impl trait

+// run-pass+#![allow(unused_must_use)]+fn bug<T>() -> impl Iterator<Item = [(); { |x: u32| { x }; 4 }]> {

We're running into issues which suggest we also want examples where the impl Trait is in argument position. (As that lowers to a generic parameter, which currently isn't a HIR owner)

lcnr

comment created time in 19 days

PullRequestReviewEvent

pull request commentrust-lang/rust

fix def collector for impl trait

@bors r+ Thanks! (looks like this was an oversight)

lcnr

comment created time in 19 days

PullRequestReviewEvent

issue commentbevyengine/bevy

Create and use StableTypeId instead of TypeId

Could building the "host" as an example in the bevy repo and the "dynamic plugin" as a separate cargo project that references the bevy repo cause the inconsistencies I saw?

That could cause two incompatible builds of bevy, you should check target/{debug,release}/deps/libbevy-*.rlib in both cases - if they have different hashes in the filenames, you are already introducing UB (Rust doesn't guarantee the ABI is the same, though we sadly don't do as much as we could to make it break much earlier).

But even then, two recompiles of the plugin shouldn't result in different TypeIds of type defined in the plugin itself.

cart

comment created time in 19 days

issue commentgodot-rust/godot-rust

Change type_tag implementation to consider the possibility of a change in the layout of TypeId

Ah, I see, found it: https://github.com/godot-rust/godot-rust/blob/836fa993c875883702fbca4f3bc8347da4146bea/gdnative-core/src/nativescript/type_tag.rs#L73-L83

Yeah, you shouldn't rely on this. Consider amortizing the cost of using the boxed version instead (and, really, you can replace your Vec with an IndexSet<TypeId> and use even 32-bit integers, or smaller, instead of usize).

toasteater

comment created time in 19 days

issue commentgodot-rust/godot-rust

Change type_tag implementation to consider the possibility of a change in the layout of TypeId

It's not usize, though? It's currently u64, are you sure the code in question compiles on 32-bit targets? You can write [u8; size_of::<TypeId>()], but ideally you would rely on Eq and/or Hash.

toasteater

comment created time in 19 days

issue commentbevyengine/bevy

Create and use StableTypeId instead of TypeId

If you are rebuilding the same Cargo project to obtain a newer build of the plugin, and this is a feature meant primarily for development uses, please use TypeId. If it breaks, that's great, because it means you're doing something wrong all of a sudden.

It's a very weak litmus test for basic things like "did I upgrade my Rust version and forgot to recompile the host binary" (if you're not linking bevy as a dylib, you will get duplication of everything between the host and the plugin, so things will appear to work even when they shouldn't - and I guess even if you do have a common dylib it will also probably succeed dynamic loading even if it's an incompatible version).

At the very least, if you move to something like "language-agnostic ComponentId", consider checking, on plugin loading, that things like TypeId::of::<bevy::SomeType>() agree between the host and the plugin. If they don't, do not run the plugin. This is the least you can do to make sure you're not accidentally loading incompatible code.

cart

comment created time in 19 days

pull request commentrust-lang/rust

Widen TypeId from 64 bits to 128.

the fallback (hash comparison) will be known-length which will be faster than comparing strings.

But any fixed length of hash is a mere probabilistic improvement, but not a soundness fix.

The reason we were even talking about strings is because they can encode enough information to be sound.

eddyb

comment created time in 19 days

pull request commentrust-lang/rust

normalize substs while inlining

@bors r+ Thanks!

lcnr

comment created time in 19 days

pull request commentrust-lang/reference

Document expression order for tuple expressions.

Why document any one thing in particular? The order is universally "postorder" (on the AST), i.e. "more nested" expressions first (effectively mandated by "expressions depend on the result of their subexpressions"), and between siblings it's specifically left-to-right (outside of perhaps assignments' LHS? I forget how we resolved that one).

Can't we specify it in one place? Doing it on a case-by-case basis seems inefficient and would suggest the order isn't uniformly defined, whereas it is (otherwise e.g. the borrow-checker couldn't possibly work).

cc @rust-lang/lang

Havvy

comment created time in 20 days

pull request commentrust-lang/rust

updated p! macro to accept literals

@bors r+

jakevossen5

comment created time in 20 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Permit ty::Bool in const generics for v0 mangling

@bors r+ Btw do you have a matching rustc-demangle PR?

Mark-Simulacrum

comment created time in 21 days

PullRequestReviewEvent

issue commentoschwald/maxminddb-rust

Can't build with panic = "abort"

It shouldn't impact anyone, you should avoid specifying crate_type in general, looks like it was left over from pre-Rust-1.0 days.

We should've deprecated dylib a long time ago, and staticlib is only useful if you're building a standalone C library (with a C API, which you don't have, so it does nothing for you).

ye2020

comment created time in 21 days

issue commentrust-lang/cargo

indicate in cargo build whether incremental is in use

I've just spent my day telling different people about CARGO_INCREMENTAL=1 (and the .cargo/config.toml incremental = true, which is probably a better semi-permanent solution), and none of them were aware that release mode had it disabled.

So I think it would be useful to say incremental or non-incremental so that there's at least a hint.

nikomatsakis

comment created time in 21 days

Pull request review commentrust-lang/rust

Returns values up to 2*usize by value

 where                     _ => return,                 } -                let max_by_val_size =-                    if is_ret { call::max_ret_by_val(cx) } else { Pointer.size(cx) };+                // Return structures up to 2 pointers in size by value, matching `ScalarPair`. LLVM+                // will usually return these in 2 registers, which is more efficient than by-ref.+                let max_by_val_size = if is_ret { Pointer.size(cx) * 2 } else { Pointer.size(cx) };

I wonder if it makes sense to limit this to returns, but also whether 3 might work better than 2 as the multiplier. But I guess there's a risk it might get downgraded from registers... I really wish LLVM modeled ABIs more precisely so we can control that.

jonas-schievink

comment created time in 22 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Returns values up to 2*usize by value

 impl<'a, Ty> FnAbi<'a, Ty> {         Ok(())     } }--/// Returns the maximum size of return values to be passed by value in the Rust ABI.-///-/// Return values beyond this size will use an implicit out-pointer instead.-pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {-    match spec.target_spec().arch.as_str() {-        // System-V will pass return values up to 128 bits in RAX/RDX.-        "x86_64" => Size::from_bits(128),

I was hoping removing this string comparison would help perf but I guess not?

jonas-schievink

comment created time in 22 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/rust

Return values up to 128 bits in registers

 impl<'a, Ty> FnAbi<'a, Ty> {         Ok(())     } }++/// Returns the maximum size of return values to be passed by value in the Rust ABI.+///+/// Return values beyond this size will use an implicit out-pointer instead.+pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {+    match spec.target_spec().arch.as_str() {+        // System-V will pass return values up to 128 bits in RAX/RDX.+        "x86_64" => Size::from_bits(128),++        _ => spec.data_layout().pointer_size,+    }+}

That is, we already do 2 * pointer_size on all architectures, just not for arbitrary data, only pairs of scalars.

jonas-schievink

comment created time in 22 days

issue commentrust-lang/compiler-team

`ty.kind()` -> `ty.data()`

@rustbot second

nikomatsakis

comment created time in 22 days

Pull request review commentrust-lang/rust

Improve std::sys::windows::compat

 pub fn lookup(module: &str, symbol: &str) -> Option<usize> {     } } -pub fn store_func(ptr: &AtomicUsize, module: &str, symbol: &str, fallback: usize) -> usize {-    let value = lookup(module, symbol).unwrap_or(fallback);-    ptr.store(value, Ordering::SeqCst);-    value-}- macro_rules! compat_fn {-    ($module:ident: $(+    ($module:literal: $(         $(#[$meta:meta])*-        pub fn $symbol:ident($($argname:ident: $argtype:ty),*)-                                  -> $rettype:ty {-            $($body:expr);*-        }+        pub fn $symbol:ident($($argname:ident: $argtype:ty),*) -> $rettype:ty $body:block     )*) => ($(-        #[allow(unused_variables)]         $(#[$meta])*-        pub unsafe fn $symbol($($argname: $argtype),*) -> $rettype {+        pub mod $symbol {+            use super::*;             use crate::sync::atomic::{AtomicUsize, Ordering};             use crate::mem;-            type F = unsafe extern "system" fn($($argtype),*) -> $rettype;              static PTR: AtomicUsize = AtomicUsize::new(0); +            #[allow(unused_variables)]+            unsafe extern "system" fn fallback($($argname: $argtype),*) -> $rettype $body++            #[cold]             fn load() -> usize {-                crate::sys::compat::store_func(&PTR,-                                          stringify!($module),-                                          stringify!($symbol),-                                          fallback as usize)+                // There is no locking here. It's okay if this is executed by multiple threads in+                // parallel. `lookup` will result in the same value, and it's okay if they overwrite+                // eachothers result as long as they do so atomically. We don't need any guarantees+                // about memory ordering, as this involves just a single atomic variable which is+                // not used to protect or order anything else.+                let addr = crate::sys::compat::lookup($module, stringify!($symbol))+                    .unwrap_or(fallback as usize);+                PTR.store(addr, Ordering::Relaxed);+                addr             }-            unsafe extern "system" fn fallback($($argname: $argtype),*)-                                               -> $rettype {-                $($body);*++            fn addr() -> usize {+                match PTR.load(Ordering::Relaxed) {+                    0 => load(),+                    addr => addr,+                }             } -            let addr = match PTR.load(Ordering::SeqCst) {-                0 => load(),-                n => n,-            };-            mem::transmute::<usize, F>(addr)($($argname),*)+            #[allow(dead_code)]+            pub fn is_available() -> bool {+                addr() != fallback as usize

FWIW this looks fine to me now.

m-ou-se

comment created time in 22 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Return values up to 128 bits in registers

 impl<'a, Ty> FnAbi<'a, Ty> {         Ok(())     } }++/// Returns the maximum size of return values to be passed by value in the Rust ABI.+///+/// Return values beyond this size will use an implicit out-pointer instead.+pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {+    match spec.target_spec().arch.as_str() {+        // System-V will pass return values up to 128 bits in RAX/RDX.+        "x86_64" => Size::from_bits(128),++        _ => spec.data_layout().pointer_size,+    }+}

Is there anything wrong with 2 * pointer_size? IIRC we already return pairs in two registers.

jonas-schievink

comment created time in 22 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used.

You could use a thread-local Cell<bool>, that won't register a destructor, at least on cfg(target_thread_local) platforms.

m-ou-se

comment created time in 22 days

issue commentmicrosoft/vscode

Task terminal truncates long/quick output.

IIUC, #38137 was fixed in version 1.49 but I can still reproduce my testcase above with:

Version: 1.49.1
Commit: 58bb7b2331731bf72587010e943852e13e6fd3cf
Date: 2020-09-16T23:23:33.049Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 5.4.59

So I'm pretty sure this is a different bug than #38137.

eddyb

comment created time in 23 days

issue commentrust-lang/rfcs

Impl Copy for Range

Because Copy is a marker trait (no associated items), and its absence doesn't confer any additional powers (in general we try to avoid negative reasoning, I think - also see the previous comment where I show coherence is already future-proofed), I believe we can implement Copy on Range and feature-gate it.

While we still can't feature-gate individual impls without running into the complexity of all possible trait system interactions (and how it may behave across crates), we could "just" pretend Copy impls aren't there for types marked with #[must_clone], unless the feature-gate, e.g. #![feature(must_clone_copy_impls)] (bikeshed-ready name) is enabled.

There's one issue I see with this: if a dependency uses #![feature(must_clone_copy_impls)], definitions from it may result in ICEs when used/codegen'd in a downstream crate without the feature-gate. And I can think of two mitigations:

  1. avoid the feature in the standard library - this should avoid any cross-crate interactions for users which don't touch the feature-gate (or are on beta/stable), though it would limit dogfooding
  2. only hide the #[must_clone] + Copy impls in Reveal::UserFacing mode (i.e. type-checking, borrow-checking, lints), not Reveal::All mode (everything else, including MIR optimizations, miri, codegen, etc.) - that way, MIR from dependencies should continue to codegen correctly, even in downstream crates without the feature-gate
    • this should make mitigation 1. irrelevant but we might still want to be careful about it

cc @nikomatsakis @matthewjasper Do you have any opinions on this strategy? I think if we can feature-gate Range<_>: Copy, we can land it much sooner, and go through the normal stabilization process.

jyn514

comment created time in 23 days

PR closed rust-lang/rust

[experiment] Add MustClone and impl Copy+MustClone on Range{,From,Inclusive}. S-waiting-on-author

Background: (second half of) https://github.com/rust-lang/rfcs/issues/2848#issuecomment-697257283.

I'm opening this for two reasons:

  • demonstrating the (relatively simple) implementation (though it could use specialized diagnostics)
  • doing a crater run just in case simply having Range<_>: Copy breaks something through e.g. inference
+118 -54

20 comments

21 changed files

eddyb

pr closed time in 23 days

pull request commentrust-lang/rust

[experiment] Add MustClone and impl Copy+MustClone on Range{,From,Inclusive}.

I'm closing this experiment PR, please continue discussion over at https://github.com/rust-lang/rfcs/issues/2848#issuecomment-701951599, to avoid fragmentation.

eddyb

comment created time in 23 days

issue commentrust-lang/rfcs

Impl Copy for Range

If anyone is wondering, part of the reason adding Copy impls is backwards-compatible is, well, we future-proofed for it:

trait Trait {}
impl<T: Copy> Trait for T {}
impl Trait for std::ops::Range<usize> {}

That snippet produces (on playground) an error with this note:

upstream crates may add a new impl of trait std::marker::Copy for type std::ops::Range<usize> in future versions

jyn514

comment created time in 23 days

issue commentrust-lang/rfcs

Impl Copy for Range

Update on the experiment I was doing in https://github.com/rust-lang/rust/pull/77180: Range<_>: Copy appears to be backwards-compatible, like I was hoping it would be (see https://github.com/rust-lang/rust/pull/77180#issuecomment-701487663).

Quoting myself from that PR:

So we should be able to proceed here with an RFC or similar - though at the moment I don't have the bandwidth for anything like that, but if someone is interested in writing a #[must_clone] / trait MustClone RFC, feel free to show me drafts etc.

Importantly, I don't have a strong opinion on "attribute vs trait", and both implementation strategies should work (the attribute might be slightly easier even). I'd suggest looking for previous discussions of #[must_use] deficiencies (sadly I only have a vague memory of there being some discussion), or starting a t-lang thread on Zulip to discuss attribute vs trait.

jyn514

comment created time in 23 days

pull request commentrust-lang/rust

[experiment] Add MustClone and impl Copy+MustClone on Range{,From,Inclusive}.

Thanks! At least it being a lint means it shouldn't impact any crates that depend on conrod_core / kiss3d_conrod. And having that lint trip is a nice way to confirm that something is different.

So we should be able to proceed here with an RFC or similar - though at the moment I don't have the bandwidth for anything like that, but if someone is interested in writing a #[must_clone] / trait MustClone RFC, feel free to show me drafts etc.

eddyb

comment created time in 23 days

issue commentrust-lang/rust

Add `-Zrandomize-layout` flag to better detect code that rely on unspecified behavior related to memory layout

On Zulip @RalfJung pointed out that I didn't explain why you would want to make this deterministic (or why that's the main difficulty), so here's 3 reasons why this has to be deterministic:

  • unsizing coercions mean that generic types need to have the same field order across instantiations, when the field types match (ignoring the field that would be unsized) - so we can reorder based on alignment, but not randomize differently each time
  • layouts have to be the same for the same type across sibling crates (which do not know about eachother)
  • introducing non-determinism into the query system is unsound at least for incremental recompilation (where you will get miscompiles, i.e. potentially UB in safe code, if you have things like order-dependency or outright RNG)

There's two ways to get deterministic per-type-definition "seeds":

  • generate a random number when compiling the definition (and use that one value for shuffling the layout of every instance in any crate) - this is still troublesome with incremental, you would have to add it explicitly as an incremental input, in order to be sound, and it will cause a lot of invalidation
  • use the def_path_hash (which I mentioned in the previous comment), which is effectively the TypeId hash corresponding to a DefId, and rely on its hash properties be pseudo-random (it should change with compiler releases and crate versions specified in the Cargo.toml, so at least we should get some variety - though maybe not as much on nightly sadly)

You might probably also want a CLI flag to e.g. XOR in a fixed seed as well, even with the latter method, but it would have to be embedded in the type definition (so that it's correct cross-crate without requiring the same flag to passed in order to avoid miscompilation), so it's as much effort as both.

marmeladema

comment created time in 23 days

Pull request review commentrust-lang/rust

Fix control flow check for breaking with diverging values

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 assert!(expr_opt.is_none() || self.tcx.sess.has_errors());             } -            ctxt.may_break = true;+            // If we encountered a `break`, then (no surprise) it may be possible to break from the+            // loop... unless the value being returned from the loop diverges itself, e.g.+            // `break return 5` or `break loop {}`.+            ctxt.may_break |= !e_ty.is_never();

Like self.diverges (was looking for it).

varkor

comment created time in 24 days

more