profile
viewpoint

lcnr/crow 109

A simple pixel perfect 2D rendering engine

lcnr/akari 39

A showcase game for the crow rendering engine

lcnr/-.- 7

I am using Rust

distransient/gmtk2019 5

"Only One"

lcnr/computer 4

A simple computer made from scratch

lcnr/binary 2

Efficient type based integers

lcnr/awesome-rust-mentors 1

A list of rust lang mentors tagged by topics of interest

lcnr/cobalt 1

a wip minimal proof assistant

lcnr/amethyst 0

Data-oriented and data-driven game engine written in Rust

push eventlcnr/tindex

lcnr

commit sha b7d4d0143452ada0046b04faa74b50f0b7c0cc8b

update version

view details

lcnr

commit sha be55a4ce9364978375e205b076cdfaf319ad8076

inline stuff

view details

push time in 11 minutes

pull request commentrust-lang/rust

Improve diagnostic for missing half of binary operator in `if` condition

lgtm :+1: thanks

@bors r+

FabianWolff

comment created time in 2 hours

push eventlcnr/tindex

lcnr

commit sha d6f15e0096b5dd8051d86c13697af682081f38d1

union vs intersection xx

view details

push time in 8 hours

push eventlcnr/tindex

lcnr

commit sha d1172d29ee504c3678fedadc77a0913f6b47d905

update to 0.4

view details

push time in a day

push eventlcnr/tindex

lcnr

commit sha e8ba1b7ed371cc544b57e994fbc5d547f9d23548

add `TBitSet::contains`

view details

lcnr

commit sha 6f89f4ca812b86479417d4373273a98a9ee569fd

update version

view details

push time in a day

issue openedrust-lang/rust

Poor diagnostic when using an if expression with missing half of binary operator

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

fn main() {
    let value = if true && {
        3
    } else { 4 };
}

The current output is:

error: missing condition for `if` expression
 --> src/main.rs:2:19
  |
2 |     let value = if true && {
  |                   ^ expected if condition here

error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
 --> src/main.rs:4:12
  |
4 |     } else { 4 };
  |            ^ expected one of `.`, `;`, `?`, `else`, or an operator

error: could not compile `wtf2` due to 2 previous errors

Ideally the output would refer to either the && or at least that there is an unexpected else or something :thinking:

created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/rust

Reduce boilerplate around infallible folders

 use std::ops::ControlFlow; /// /// To implement this conveniently, use the derive macro located in `rustc_macros`. pub trait TypeFoldable<'tcx>: fmt::Debug + Clone {-    fn super_fold_with<F: TypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error>;-    fn fold_with<F: TypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {-        self.super_fold_with(folder)+    /// Consumers may find this more convenient to use with infallible folders than+    /// [`try_super_fold_with`][`TypeFoldable::try_super_fold_with`], to which the+    /// provided default definition delegates.  Implementors **should not** override+    /// this provided default definition, to ensure that the two methods are coherent+    /// (provide a definition of `try_super_fold_with` instead).+    fn super_fold_with<F: TypeFolder<'tcx, Error = !>>(self, folder: &mut F) -> Self {+        self.try_super_fold_with(folder).into_ok()+    }+    /// Consumers may find this more convenient to use with infallible folders than+    /// [`try_fold_with`][`TypeFoldable::try_fold_with`], to which the provided+    /// default definition delegates.  Implementors **should not** override this+    /// provided default definition, to ensure that the two methods are coherent+    /// (provide a definition of `try_fold_with` instead).+    fn fold_with<F: TypeFolder<'tcx, Error = !>>(self, folder: &mut F) -> Self {+        self.try_fold_with(folder).into_ok()+    }+    fn try_super_fold_with<F: TypeFolderFallible<'tcx>>(+        self,+        folder: &mut F,+    ) -> Result<Self, F::Error>;+    fn try_fold_with<F: TypeFolderFallible<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {

    fn try_super_fold_with<F: TypeFolderFallible<'tcx>>(
        self,
        folder: &mut F,
    ) -> Result<Self, F::Error>;

    fn try_fold_with<F: TypeFolderFallible<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
eggyal

comment created time in a day

pull request commentrust-lang/rust

Reduce boilerplate around infallible folders

I quite like this change :+1: prefer the name FallibleTypeFolder over TypeFolderFallible though.

While I am not completely happy with the way this is implemented, I can't think of a better way with the way rusts default trait impls work. Might be interesting to think of ways to change Rust so that we're be able to represent this using only one trait, but that's not necessary for this PR. imo it's fine to merge this without an MCP

eggyal

comment created time in a day

issue commentrust-lang/rust

rustdoc ICE when resolving traits

uh.. that seems weird

https://github.com/rust-lang/rust/blob/207c80f105282245d93024c95ac408c622f70114/compiler/rustc_trait_selection/src/traits/auto_trait.rs#L764-L774

cc @nikomatsakis @jackh726

so the obligation is Obligation(predicate=Binder(ProjectionPredicate(ProjectionTy { substs: [CC2], item_def_id: DefId(0:7 ~ dep[b688]::ChainComplex::Module) }, _), []), depth=2) with param env

ParamEnv {
   caller_bounds: [
      Binder(TraitPredicate(<CC2 as std::marker::Sized>, polarity:Positive), []),
      Binder(TraitPredicate(<CC2 as ChainComplex>, polarity:Positive), []),
      Binder(ProjectionPredicate(ProjectionTy { substs: [CC2], item_def_id: DefId(0:7 ~ dep[b688]::ChainComplex::Module) }, FreeModule<usize>), []),
      Binder(TraitPredicate(<CC2 as FreeChainComplex>, polarity:Positive), []),
      Binder(ProjectionPredicate(
         ProjectionTy { substs: [CC2], item_def_id: DefId(0:7 ~ dep[b688]::ChainComplex::Module) },
         FreeModule<<CC2 as ChainComplex>::Algebra>
      ), []),
      Binder(ProjectionPredicate(
         ProjectionTy { substs: [CC2], item_def_id: DefId(0:6 ~ dep[b688]::ChainComplex::Algebra) }, usize), [])
   ],
   reveal: UserFacing
}

This obligation should be easily provable, so I expect there to either be a bug something bigger going wrong :thinking: maybe a caching issue where rustdoc is using a SelectionContext the wrong way or something?

dalcde

comment created time in 2 days

pull request commentrust-lang/rust

Reuse refcounted allocs during folding

@bors try @rust-timer queue

eggyal

comment created time in 3 days

issue commentrust-lang/project-const-generics

Ghost types

Can you explain more?

if we typeck these as const parameters, they can never be used with runtime values, so there isn't really a need to codegen them at all, they could just be const fn's or even associated consts of a generic type.

There are already three style of api: panicking, fail with Option/Result, and unsafe. A forth style that takes proofs as input can be added?

we not just want things to take proofs as inputs, we also want to add proofs of postconditions as outputs, don't we? These three kinds of api only rarely exist for the same functionality, so I believe you underestimate the necessary amount of duplication. Esp. because the "proof" versions are pretty much a strict improvement over non proof methods, so having both seems suboptimal.

Dependent types (types that depends on value) are already here, but they are limited to compile-time constant, and it isn't because typeck (Correct me if I'm wrong)

To me, the core part of dependent typing is that values from a context can flow into types in that same context. Rusts implementation of const generics seperate computations used in types from the places where these types are used which makes it a lot easier to querify. Right now we can separately compute any const arguments during the typeck where these constants are used. Once these values are used in types which exist in the same context as they do themselves, the separation between const eval and typeck breaks down. We then have to partially evaluate a function while typechecking it which is far from trivial.

Finally, these statements seem contradictory

fn(MyStatement) -> ! guarantees that ¬MyStatement is partially correct, i.e. programs that use it to proof other properties will work as intended or won't terminate (successfully).

After type checking, we replace all ghost types with ()

if we replace all ghost types with () after typeck we have to catch all "false proofs" during compile time, for a function like fn proof_of_not_P(x: &str) -> fn(P<x>) -> ! this seems pretty much impossible to me.

This is at the edge of my knowledge, but more generally: for ghost types to be erasable before codegen you need proof irrelevance, i.e. the values of your proof objects must not flow into non proof objects. I am not sure how one would add proof irrelevance to rust.

HKalbasi

comment created time in 6 days

pull request commentrust-lang/rust

Only check for errors in predicate when skipping impl assembly

r? @lcnr @bors r+ rollup

Aaron1011

comment created time in 6 days

issue commentrust-lang/project-const-generics

Ghost types

How we type check such function calls? It will reuse const generic infrastructures. For example that function will become roughly equivalent to this for type checking propose:

fn do_smth<const x: usize, const y: usize>(x_le_y: Le<x, y>);

and

After type checking, we replace all ghost types with (), so that function will become:

fn do_smth(x: usize, y: usize, x_le_y: ());

seems to disagree with each other.


More generally, while I would love a language like Rust with dependent types, I do not believe that we should add them to Rust itself.

There are three reasons for this:

  • adding it to Rust without any breaking changes will leave us with large parts of std/the ecosystem at large not supporting it, which makes using it a lot more cumbersome than needed
  • dependent types really do not mesh well with our current query system and would need fairly large changes to how typeck and const evaluation works. Even feature(generic_const_exprs) feels like its pretty much at the edge of what we can support.
  • const fns are not guaranteed to evaluate successfully, so you can't use fn(MyStatement) -> ! as a proof of ¬MyStatement and I don't believe that adding something like ghost fn or pure fn for this is worth it. To my knowledge this is an important part of any useful proof assistant.

Other members of the language or compiler team might be a bit more open to something like your proposal, but even then, I do not assume this to be something we're going to tackle any time soon.

An imo far more promising approach would be unique lifetimes outside of closures. While using them will be more complex than actual dependent types, these lifetimes can already be used to assert things about the runtime behavior of your programs, e.g. https://twitter.com/lcnr7/status/1390653250383355904

HKalbasi

comment created time in 6 days

pull request commentrust-lang/rust

Stabilise `feature(const_generics_defaults)`

Is there a separate gate for this? Or a test that it's not inadvertently stabilized?

the gate for this is generic_const_exprs and we do have a test for this:

https://github.com/rust-lang/rust/blob/a7836bf885e70aaf1a2e0d4669406b183a79acaa/src/test/ui/const-generics/defaults/complex-generic-default-expr.rs#L1-L13

the inference rules for this match the ones for types

yes, whether const parameter defaults are used is decided in the same way as for type parameters. Added a sentence to the report itself for this.

BoxyUwU

comment created time in 6 days

pull request commentrust-lang/rust

Visit `param_env` field in Obligation's `TypeFoldable` impl

the output probably changed cause the param_env of the obligation also contained an erroneous anon const which we previously did not compute for whatever reason :shrug:

slightly prefer to keep the old formatting here, apart from that r=me

r? @lcnr

Aaron1011

comment created time in 7 days

pull request commentrust-lang/rust

Warn when `#[test]` is present multiple times.

we currently allow the following without any warnings as well

#[inline]
#[inline]
fn foo() {}

I think that ideally we should hard error for duplicate builtin attributes though starting with a future incompat lint is probably the right choice :thinking: imo we should start a crater run for this, you would have to first convert the warning to an error in that case.

Ethiraric

comment created time in 8 days

issue commentrust-lang/rust

Tracking issue for allowing overlapping implementations for marker trait

it allows overlapping impls in the same crate, allowing it across crates is unsound without restricting the way marker traits can be used.

consider a crate like this:

#![feature(marker_trait_attr)]
#[marker]
pub trait Marker {}

pub struct B;

trait NotMarker {
    type Assoc;
}

impl NotMarker for B {
    type Assoc = usize;
}

impl<T: Marker> NotMarker for T {
    type Assoc = Box<String>;
}

if a different crate were to add an impl leading to B: Marker, we have an ambiguous associated type

nikomatsakis

comment created time in 9 days

issue commentrust-lang/rust

Tracking issue for allowing overlapping implementations for marker trait

cc @rust-lang/wg-traits -- I seem to recall some concerns about the implementation potentially being unsound? Does anyone remember what I'm talking about?

I think the issue was #88139. The implementation now results in weird ambiguities, but at least it isn't unsound anymore afaik

For Unpin we have a concrete example where making it #[marker] would introduce soundness issues in a crate (#29864 (comment), taiki-e/pin-project#18).

Afaict the issue here is about impls for marker traits violating the orphan rules, which is generally unsound to my knowledge and not permitted by the current implementation. It might actually be possible to change all auto traits to marker traits again, only requiring opt-in for non-auto traits, as for those, adding an item to the trait definition would otherwise be a breaking change.

nikomatsakis

comment created time in 9 days

push eventlcnr/rust

lcnr

commit sha 549f2fc0ea058ee2a50ead600b716abfae4630e9

that's a win

view details

lcnr

commit sha 70ff31e9e8089222f77ea9838e817e64364e5835

do not eagerly polymorphize vtables causes query cycles when building core

view details

lcnr

commit sha cde9e9870e30f536ec8065d62c6b1a7b8406ce4e

fixup source

view details

lcnr

commit sha 2bb93168adec0ccfac39e51612180c00d2f438e4

polymorphize: deal with upvars

view details

lcnr

commit sha 528a781f9b784faf08b65fed08d67720eac4b4a7

extract polymorphization option check

view details

push time in 12 days

push eventlcnr/rust

push time in 12 days

push eventlcnr/rust

lcnr

commit sha 72902e2ab2a380eb63f20b1045af40718a8dcb30

enable polymorphization

view details

push time in 12 days

push eventlcnr/rust

Dharma Saputra Wijaya

commit sha a5a3e6192dc0c4a5b7b83ff19f074df3cf526338

Fix typo on utils/lib

view details

bors

commit sha 91b931926fd49fc97d1e39f2b8206abf1d77ce7d

Auto merge of #90203 - matthiaskrgr:rollup-v215wew, r=matthiaskrgr Rollup of 5 pull requests Successful merges: - #85833 (Scrape code examples from examples/ directory for Rustdoc) - #88041 (Make all proc-macro back-compat lints deny-by-default) - #89829 (Consider types appearing in const expressions to be invariant) - #90168 (Reset qualifs when a storage of a local ends) - #90198 (Add caveat about changing parallelism and function call overhead) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

view details

Martinez

commit sha 599b2fd9c47f913c6c3540b4805528d8bacd3d7e

Add One option to group_imports (#4966) * Add Together option to group_imports * Rename option to One * Rename files from Together to One

view details

bors

commit sha ba0cfc7debaaa68dbd26c9aab101a496afe3db49

Auto merge of #7867 - dswij:utils-typo, r=llogiq Fix typo on utils/lib Found some typo when looking through `clippy_utils/src/lib.rs` :slightly_smiling_face: changelog: none

view details

Mark Rousskov

commit sha 3cd5c95ab0618924d790fcd19f31883e020cc90f

Specialize HashStable for [u8] slices Particularly for ctfe-stress-4, the hashing of byte slices as part of the MIR Allocation is quite hot. Previously, we were falling back on byte-by-byte copying of the slice into the SipHash buffer (64 bytes long) before hashing a 64 byte chunk, and then doing that again and again. This should hopefully be an improvement for that code.

view details

Camille GILLOT

commit sha 138e96b71926a9cb8b70b33d40ab803ab2985d94

Do not require QueryCtxt for cache_on_disk.

view details

Josh Stone

commit sha 8b1504cfb73894040f8096623e6f9d4559c9eb7f

bless the line changes in ui/asm/aarch64/srcloc.rs

view details

Maybe Waffle

commit sha 27d69611347142cc5f103df0923b46d670e75739

Fill tracking issue for `const_slice_from_ref` and `const_array_from_ref`

view details

Chris Denton

commit sha f1efc7efb2bc39021eb93228b1e25c384767b38d

Make sure `CreateDirectoryW` works for path lengths > 247

view details

Jacob Hoffman-Andrews

commit sha 542ab2daa6eb4b05a01403114783aa323315b416

Outdent method headings so they stand out The makes the heading / documentation distinction clearer.

view details

Chris Denton

commit sha 37e4c84b239c58196c888eabf5550f398ea0b7a2

Fix typo Co-authored-by: Ruslan Sayfutdinov <ruslan@sayfutdinov.com>

view details

Maybe Waffle

commit sha 5f390cfb722cf95b0df81f9563bf97b1663cff9e

Add tests for `const_slice_from_ref` and `const_array_from_ref`

view details

bors

commit sha 45591408b18e7f93fcf8c09210c9a5a102d84b37

Auto merge of #90175 - cuviper:min-llvm-12, r=nagisa Update the minimum external LLVM to 12 With this change, we'll have stable support for LLVM 12 and 13. For reference, the previous increase to LLVM 10 was #83387, and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`

view details

bors

commit sha a99c9d6518690023914abdbaad572634f857c4c2

Auto merge of #89776 - rusticstuff:ci-overflow-checks, r=Mark-Simulacrum CI: Enable overflow checks for test (non-dist) builds They stay disabled for Apple builds though, which take the most time already due to running on slow hw.

view details

Pietro Albini

commit sha 5d088abfb3dfd45f2d021fd2eef7a0f8ba1a204a

bump boostrap compiler

view details

Pietro Albini

commit sha b63ab8005a76844a0330d45bf48b6d71e9422de3

update cfg(bootstrap)

view details

Pietro Albini

commit sha aca8bcb48feca8c87b9af4e440835992d3f6d470

remove "field is never read" warning

view details

Dylan MacKenzie

commit sha abd3fe347b41328b556c333330bbc815b5ec99e5

Ignore errors re: unreachable blocks in dataflow cursor unit tests

view details

Jakob Degen

commit sha eae42fd9d0d6e568282a4c782405058b64f1ef0b

Add regresstion test for #90024. Uses 2 MCVEs from the issue tracker that test opposite sides of the problem.

view details

Jakob Degen

commit sha 4b970231fd1254580fbddabab74a125404fea0de

Fix ICE when forgetting to `Box` a parameter to a `Self::func` call

view details

push time in 12 days

push eventlcnr/rust

Waffle Lapkin

commit sha 7a477869b72e2e053182d677b3b8f785796ee95d

Makes docs for references a little less confusing - Make clear that the `Pointer` trait is related to formatting - Make clear that `&T` (shared reference) implements `Send` (if `T: Send + Sync`)

view details

Waffle Lapkin

commit sha 9a4530bdd00f5df42e750e2596fb2cc992fa3627

Update library/std/src/primitive_docs.rs Co-authored-by: fmease <liehr.exchange@gmx.net>

view details

Maybe Waffle

commit sha 26aec6c9363345d14ca38d7630dc9478239fbd77

Update core primitives_docs.rs up to date with std

view details

Jacob Hoffman-Andrews

commit sha 69df43b041f76251391f11264c1ff763ca2a64a0

Improve display of enum variants Use h3 and h4 for the variant name and the "Fields" subheading. Remove the "of T" part of the "Fields" subheading. Remove border-bottom from "Fields" subheading. Move docblock below "Fields" listing.

view details

Tomasz Miąsko

commit sha 73f5b6581891e24b9b5bd45e58fbec78582549a2

Implement `clone_from` for `State` Data flow engine uses `clone_from` for domain values. Providing an implementation of `clone_from` will avoid some intermediate memory allocations.

view details

Nilstrieb

commit sha d64aea65ad3b994ed0e1503f836d82a9896ab468

Fix `non-constant value` ICE (#90878) This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const. I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong. Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.

view details

Yuki Okushi

commit sha 8f6fa4f548a57d11b93e8c9a1f20628783d6e4d7

Add a regression test for #87573

view details

Mara Bos

commit sha 483cff7ed3a3121e6644bbcb9011a762cf871d97

Add SourceMap::indentation_before.

view details

Mara Bos

commit sha 453e2423e6238283acae39007741e0b122fdb191

Improve suggestion for unit Option/Result at the end of a block.

view details

Mara Bos

commit sha b331b6608265f98eea8c3fa85dd67d3156c88ead

Improve compatible enum variant suggestions.

view details

Mara Bos

commit sha 48777561ca67abcd259c870f8da28d0062ce6857

Update tests.

view details

Mara Bos

commit sha 5a25751c1e5328930743bef8c1f688ed7c69938b

Add new tests for compatible variant diagnostics.

view details

Mara Bos

commit sha 09e4a75f294a9b058bd908c98df38dd41e68f6ff

Use span_suggestions instead of multipart_suggestions.

view details

Mara Bos

commit sha b66fb641da92ea4c9d1c5b0d52ea273cbc21f76e

Update test output.

view details

Nilstrieb

commit sha 7c7f58d5b7b5b453fde743bb058aa5770a37e57f

Fix case where ICE #90878 was still triggered by a leading newline I cannot provide a test for that thanks to tidy.

view details

Guillaume Gomez

commit sha bf10c88fbd15c6ca1254a0100ec76d464f665f86

Make scrollbar in the sidebar always visible for visual consistency

view details

Nilstrieb

commit sha 495d8ed246ec659127ee646b55e0ea7874ecb82f

tidy-ignore-leading-newlines

view details

Nilstrieb

commit sha 96c37c8a6a4bbfe34a81754e174bfc2e41d194f6

Add a test with a leading newline for ICE #90878

view details

Ralf Jung

commit sha 2f1a1f530b253b98e41a138b159c19481eb42269

fix CTFE/Miri simd_insert/extract on array-style repr(simd) types

view details

Ralf Jung

commit sha 0304e16f3b357c3df48b25277127c658b5169fd4

CTFE SIMD: also test 1-element array

view details

push time in 12 days

push eventlcnr/rust

Will Crichton

commit sha fd5d614b7708c2bbd0a7c796af3c3b63f31a19ac

Move def_id logic into render_call_locations

view details

Santiago Pastorino

commit sha 953418685769424388fb9ea1f4b2beaceedb6857

Hide negative coherence checks under negative_impls feature flag

view details

bors

commit sha 514b3877956dc594823106b66c164f8cdbc8b3da

Auto merge of #90007 - xfix:inline-cstr-from-str, r=kennytm Inline CStr::from_ptr Inlining this function is valuable, as it allows LLVM to apply `strlen`-specific optimizations without having to enable LTO. For instance, the following function: ```rust pub fn f(p: *const c_char) -> Option<u8> { unsafe { CStr::from_ptr(p) }.to_bytes().get(0).copied() } ``` Looks like this if `CStr::from_ptr` is allowed to be inlined. ```asm before: push rax call qword ptr [rip + std::ffi::c_str::CStr::from_ptr@GOTPCREL] mov rcx, rax cmp rdx, 1 sete dl test rax, rax sete al or al, dl jne .LBB1_2 mov dl, byte ptr [rcx] .LBB1_2: xor al, 1 pop rcx ret after: mov dl, byte ptr [rdi] test dl, dl setne al ret ``` Note that optimization turned this from O(N) to O(1) in terms of performance, as LLVM knows that it doesn't really need to call `strlen` to determine whether a string is empty or not.

view details

Noah Lev

commit sha 865d99f82be5718abce2c75a9ed87b1ed028910e

docs: Escape brackets to satisfy the linkchecker My change to use `Type::def_id()` (formerly `Type::def_id_full()`) in more places caused some docs to show up that used to be missed by rustdoc. Those docs contained unescaped square brackets, which triggered linkcheck errors. This commit escapes the square brackets and adds this particular instance to the linkcheck exception list.

view details

Michael Howell

commit sha 98ed5548d7e604470ab9a97ffed4d9c12e424d83

nice_region_error: Include lifetime placeholders in error output As you can see in src/test/ui/traits/self-without-lifetime-constraint.stderr you can get very confusing type names if you don't have this. Fixes #87763

view details

Noah Lev

commit sha 3ad0834700ec3db9952a7b69daf805c04a98d8e0

Fix another place that used `def_id_no_primitives()`

view details

bors

commit sha a3f7c4db0373aa077f86cdd1bf11122845d3b65a

Auto merge of #90054 - michaelwoerister:v0-mangling-in-compiler, r=Mark-Simulacrum Make new symbol mangling scheme default for compiler itself. As suggest in https://github.com/rust-lang/rust/pull/89917#issuecomment-945888574, this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet). r? `@Mark-Simulacrum`

view details

Matthias Krüger

commit sha 5ea02745637be7c4c0c8ba46407bbfca3b66edcc

Rollup merge of #83233 - jethrogb:split_array, r=yaahc Implement split_array and split_array_mut This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to #74373, #75026, etc. Fixes #74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.

view details

Matthias Krüger

commit sha df430624b6274f06800f7323a2702b661cee0a84

Rollup merge of #88300 - ijackson:exitstatusext-methods, r=yaahc Stabilise unix_process_wait_more, extra ExitStatusExt methods This stabilises the feature `unix_process_wait_more`. Tracking issue #80695, FCP needed. This was implemented in #79982 and merged in January.

view details

Matthias Krüger

commit sha d64b3a703d8e3b76a4bcb75cef94e52eb32bf55c

Rollup merge of #89416 - notriddle:notriddle/do-not-elide-lifetimes-in-region-errors, r=jackh726 nice_region_error: Include lifetime placeholders in error output As you can see in src/test/ui/traits/self-without-lifetime-constraint.stderr you can get very confusing type names if you don't have this. Fixes #87763

view details

Matthias Krüger

commit sha 0f81c7faf5f657704b2e29154af3c09aca7afd67

Rollup merge of #89468 - FabianWolff:issue-89358, r=jackh726 Report fatal lexer errors in `--cfg` command line arguments Fixes #89358. The erroneous behavior was apparently introduced by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/commit/a678e3191197f145451c97c6cc884e15cae38186; the idea is to silence individual parser errors and instead emit one catch-all error message after parsing. However, for the example in #89358, a fatal lexer error is created here: https://github.com/rust-lang/rust/blob/edebf77e0090195bf80c0d8cda821e1bf9d03053/compiler/rustc_parse/src/lexer/mod.rs#L340-L349 This fatal error aborts the compilation, and so the call to `new_parser_from_source_str()` never returns and the catch-all error message is never emitted. I have therefore changed the `SilentEmitter` to silence only non-fatal errors; with my changes, for the rustc invocation described in #89358: ```sh rustc --cfg "abc\"" ``` I get the following output: ``` error[E0765]: unterminated double quote string | = note: this error occurred on the command line: `--cfg=abc"` ```

view details

Matthias Krüger

commit sha 736e8ebd1ca703c7de40806a727559bef836d3f7

Rollup merge of #89730 - crlf0710:type_changing_feature, r=jackh726 add feature flag for `type_changing_struct_update` This implements the PR0 part of the mentoring notes within #86618. overrides the previous inactive #86646 pr. r? ```@nikomatsakis```

view details

Matthias Krüger

commit sha 8fb194c86f100a443b6e637f0ff8e4c0148a4f05

Rollup merge of #89920 - hudson-ayers:location-detail-control, r=davidtwco Implement -Z location-detail flag This PR implements the `-Z location-detail` flag as described in https://github.com/rust-lang/rfcs/pull/2091 . `-Z location-detail=val` controls what location details are tracked when using `caller_location`. This allows users to control what location details are printed as part of panic messages, by allowing them to exclude any combination of filenames, line numbers, and column numbers. This option is intended to provide users with a way to mitigate the size impact of `#[track_caller]`. Some measurements of the savings of this approach on an embedded binary can be found here: https://github.com/rust-lang/rust/issues/70579#issuecomment-942556822 . Closes #70580 (unless people want to leave that open as a place for discussion of further improvements). This is my first real PR to rust, so any help correcting mistakes / understanding side effects / improving my tests is appreciated :) I have one question: RFC 2091 specified this as a debugging option (I think that is what -Z implies?). Does that mean this can never be stabilized without a separate MCP? If so, do I need to submit an MCP now, or is the initial RFC specifying this option sufficient for this to be merged as is, and then an MCP would be needed for eventual stabilization?

view details

Matthias Krüger

commit sha 1782d1333cbe35aba7b4326534e8263041b7dac1

Rollup merge of #90070 - llogiq:compiletest-config-edition, r=Mark-Simulacrum Add edition configuration to compiletest This allows the compiletest configuration to set a default edition that can still be overridden with header annotations. Doing this will make it far easier for clippy to get our tests to the newest edition. r? ```@Manishearth```

view details

Matthias Krüger

commit sha c400feeb84f6164edd2d78607218ac8a58754cc3

Rollup merge of #90087 - calebcartwright:rustfmt-subtree, r=calebcartwright Sync rustfmt subtree There's a large number of small fixes and new features, but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20

view details

Matthias Krüger

commit sha 270c800d358ee47f3aee6fe1e2ec4dc92616d55f

Rollup merge of #90117 - calebsander:fix/rsplit-clone, r=yaahc Make RSplit<T, P>: Clone not require T: Clone This addresses a TODO comment. The behavior of `#[derive(Clone)]` *does* result in a `T: Clone` requirement. Playground example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a8b1a9581ff8893baf401d624a53d35b Add a manual `Clone` implementation, mirroring `Split` and `SplitInclusive`. `(R)?SplitN(Mut)?` don't have any `Clone` implementations, but I'll leave that for its own pull request.

view details

Matthias Krüger

commit sha 1ea34fb463b4472d674576b1d310cd44ce40760b

Rollup merge of #90122 - rusticstuff:ci_curl_max_time, r=Mark-Simulacrum CI: make docker cache download and `docker load` time out after 10 minutes Might help to prevent timeouts we have been seeing: * https://github.com/rust-lang-ci/rust/runs/3946294286?check_suite_focus=true#step:25:23 * https://github.com/rust-lang-ci/rust/runs/3956799200?check_suite_focus=true#step:25:22 * https://github.com/rust-lang-ci/rust/runs/3962928502?check_suite_focus=true#step:25:23 * https://github.com/rust-lang-ci/rust/runs/3967892291?check_suite_focus=true * https://github.com/rust-lang-ci/rust/runs/3971202204?check_suite_focus=true If the download or loading the images into docker times out the CI will still continue and rebuild the docker image from scratch.

view details

Matthias Krüger

commit sha a05a1294d08e285f7039293298d9170fb3117013

Rollup merge of #90166 - smmalis37:patch-1, r=joshtriplett Add comment documenting why we can't use a simpler solution See #90144 for context. r? ```@joshtriplett```

view details

bors

commit sha cf708558b758f4473c4f35986d9492ace7bf906d

Auto merge of #90188 - matthiaskrgr:rollup-74cwv5c, r=matthiaskrgr Rollup of 11 pull requests Successful merges: - #83233 (Implement split_array and split_array_mut) - #88300 (Stabilise unix_process_wait_more, extra ExitStatusExt methods) - #89416 (nice_region_error: Include lifetime placeholders in error output) - #89468 (Report fatal lexer errors in `--cfg` command line arguments) - #89730 (add feature flag for `type_changing_struct_update`) - #89920 (Implement -Z location-detail flag) - #90070 (Add edition configuration to compiletest) - #90087 (Sync rustfmt subtree) - #90117 (Make RSplit<T, P>: Clone not require T: Clone) - #90122 (CI: make docker cache download and `docker load` time out after 10 minutes) - #90166 (Add comment documenting why we can't use a simpler solution) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

view details

Tomasz Miąsko

commit sha e4aeeca667b6ce0446703f22f95552a64954df0d

Reset qualifs when a storage of a local ends to ensure that the local qualifs are affected by the state from previous loop iterations only if the local is kept alive. The change should be forward compatible with a stricter handling of indirect assignments, since storage dead invalidates all existing pointers to the local.

view details

push time in 12 days

PR opened rust-lang/rust

return the correct type for closures in `type_of`

A bit unhappy about the way typeck::check_crate works rn. Would have preferred to not change CollectItemTypesVisitor in this way.

r? @nikomatsakis

+9 -13

0 comment

3 changed files

pr created time in 13 days

push eventlcnr/rust

lcnr

commit sha 6bd534dbdb48f14a761356e22573904e5d419706

return the correct type for closures in `type_of`

view details

push time in 13 days

create barnchlcnr/rust

branch : type_of-closures

created branch time in 13 days

Pull request review commentrust-lang/rust

extend `simplify_type`

 where     OpaqueSimplifiedType(D),     FunctionSimplifiedType(usize),     ParameterSimplifiedType,-    ForeignSimplifiedType(DefId), } -/// Tries to simplify a type by dropping type parameters, deref'ing away any reference types, etc.-/// The idea is to get something simple that we can use to quickly decide if two types could unify-/// during method lookup.+#[derive(PartialEq, Eq, Debug, Clone, Copy)]+pub enum SimplifyParams {+    Yes,+    No,+}++#[derive(PartialEq, Eq, Debug, Clone, Copy)]+pub enum StripReferences {+    Yes,+    No,+}++/// Tries to simplify a type by only returning the outermost injective¹ layer, if one exists.+///+/// The idea is to get something simple that we can use to quickly decide if two types could unify,+/// for example during method lookup. ///-/// If `can_simplify_params` is false, then we will fail to simplify type parameters entirely. This-/// is useful when those type parameters would be instantiated with fresh type variables, since-/// then we can't say much about whether two types would unify. Put another way,-/// `can_simplify_params` should be true if type parameters appear free in `ty` and `false` if they-/// are to be considered bound.+/// A special case here are parameters and projections. Projections can be normalized to+/// a different type, meaning that `<T as Trait>::Assoc` and `u8` can be unified, even though+/// their outermost layer is different while parameters like `T` of impls are later replaced+/// with an inference variable, which then also allows unification with other types.+///+/// When using `SimplifyParams::Yes`, we still return a simplified type for params and projections²,+/// the reasoning for this can be seen at the places doing this.+///+/// For diagnostics we strip references with `StripReferences::Yes`. This is currently the best+/// way to skip some unhelpful suggestions.+///+/// ¹ meaning that if two outermost layers are different, then the whole types are also different.+/// ² FIXME(@lcnr): this seems like it can actually end up being unsound with the way it's used during+///   candidate selection. We do not consider non blanket impls for `<_ as Trait>::Assoc` even+///   though `_` can be inferred to a concrete type later at which point a concrete impl+///   could actually apply. After experimenting for about an hour I wasn't able to cause any issues+///   this way so I am not going to change this until we actually find an issue as I am really+///   interesting in getting an actual test for this.

@nikomatsakis does this comment make sense to you? I hoped to trigger it by using something like the following, but wasn't able to make much progress. We either normalize the projection because it is already concrete enough or fail for some different reason. Not sure if this is actually exploitable if it even is an issue.

trait Id {
    type Assoc;
}

impl<T> Id for T {
    type Assoc = Self;
}

trait Bar<T> {
    type Assoc;
    fn bar(self) -> Self::Assoc; 
}

impl Bar<u32> for i32 {
    type Assoc = i32;
    fn bar(self) -> Self::Assoc {
        1
    }
}

fn main() {
    let mut x = <<_ as Id>::Assoc>::default();
    x = <_ as Bar<u32>>::bar(x);
}
lcnr

comment created time in 13 days

more