profile
viewpoint
Mazdak Farrokhzad Centril Sweden http://centril.me Compiler engineer and Rust Language and Release team member.

AltSysrq/proptest 536

Hypothesis-like property testing for Rust

Centril/dbg 5

Implementation of https://github.com/rust-lang/rfcs/pull/2173 in stable rust

Centril/firefox-line 4

Rewrite of Mozilla Labs Prospector Oneliner 2 with Addons SDK

Centril/aTetria 2

Initial push of Framework + Model + input processors.

Centril/android-numberpicker 1

A backport of the Android 4.2 NumberPicker

Centril/bin-util 1

small utility scripts, mostly git related.

Centril/consensusbot 1

Next gen rfcbot

Centril/firefox-movable-titlebar 1

Movable Titlebar Buttons allows you to move the titlebar buttons on Windows 10.

Centril/android-project-template 0

template project for android.

pull request commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

I dropped the last formatting commit and ran:

rustc +gamma-stage1 src/test/ui/editions/edition-keywords-2015-2018-expansion.rs --extern edition_kw_macro_2018=./build/x86_64-unknown-linux-gnu/test/ui/editions/edition-keywords-2015-2018-expansion/auxiliary/libedition_kw_macro_2018.so

which produced:

error: expected identifier, found keyword `async`
 --> src/test/ui/editions/edition-keywords-2015-2018-expansion.rs:8:5
  |
8 |     produces_async! {} //~ ERROR expected identifier, found keyword
  |     ^^^^^^^^^^^^^^^^^^ expected identifier, found keyword
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can escape reserved keywords to use them as identifiers
  |
7 | r#async
  |

error: aborting due to previous error

and then I reran with -Z macro-backtrace added and it produced:

error: expected identifier, found keyword `async`
 --> /home/centril/programming/rust/rust-gamma/src/test/ui/editions/auxiliary/edition-kw-macro-2018.rs:7:19
  |
6 | / macro_rules! produces_async {
7 | |     () => (pub fn async() {})
  | |                   ^^^^^ expected identifier, found keyword
8 | | }
  | |_- in this expansion of `produces_async!`
  | 
 ::: src/test/ui/editions/edition-keywords-2015-2018-expansion.rs:8:5
  |
8 |       produces_async! {} //~ ERROR expected identifier, found keyword
  |       ------------------ in this macro invocation
  |
help: you can escape reserved keywords to use them as identifiers
  |
7 |     () => (pub fn r#async() {})
  |                   ^^^^^^^

error: aborting due to previous error
Centril

comment created time in 3 hours

Pull request review commentrust-lang/rust

Stabilize const for integer {to,from}_{be,le,ne}_bytes methods

 assert_eq!( ); ```"),             #[stable(feature = "int_to_from_bytes", since = "1.32.0")]-            #[rustc_const_unstable(feature = "const_int_conversion", issue = "53718")]+            #[rustc_const_stable(feature = "const_int_conversion", since = "1.43.0")]+            #[allow_internal_unstable(const_transmute)]             #[inline]             pub const fn to_ne_bytes(self) -> [u8; mem::size_of::<Self>()] {                 // SAFETY: integers are plain old datatypes so we can always transmute them to

I would use the union based implementation as done in the aforementioned PR instead of the transmute based one with the macro, as that seems more hacky.

tspiteri

comment created time in 4 hours

Pull request review commentrust-lang/rust

Stabilize const for integer {to,from}_{be,le,ne}_bytes methods

 assert_eq!( ); ```"),             #[stable(feature = "int_to_from_bytes", since = "1.32.0")]-            #[rustc_const_unstable(feature = "const_int_conversion", issue = "53718")]+            #[rustc_const_stable(feature = "const_int_conversion", since = "1.43.0")]+            #[allow_internal_unstable(const_transmute)]             #[inline]             pub const fn to_ne_bytes(self) -> [u8; mem::size_of::<Self>()] {                 // SAFETY: integers are plain old datatypes so we can always transmute them to

Please add a const-safety argument as in https://github.com/rust-lang/rust/pull/63770/files#diff-1decd9f63c23ff5e439882aa3624d87aR66 in the places the transmute is used. (Applies generally when const fn and unsafe is being combined. const fns have additional safety requirements beyond what fns must adhere to, in particular as laid out in https://www.ralfj.de/blog/2018/07/19/const.html (see "CTFE correctness", which is the property which must be preserved).) In this case the safety argument should be simple.

tspiteri

comment created time in 4 hours

pull request commentrust-lang/rust

Stabilize const for integer {to,from}_{be,le,ne}_bytes methods

I would agree with @nikomatsakis's perspective here, and also note that where exposed intrinsics are being const-stabilized, then the language team should be included in the FCP as well, as is the case with intrinsics in general, because well, they are intrinsic to the language... ;)

I think notifying wg-const-eval is the right balance here, and if there is a problem then we can escalate to the language team, but usually it will be smooth sailing.

I do find @ecstatic-morse's philosophy and guidelines compelling, although I would note that the language team did go beyond what those guidelines would permit in https://github.com/rust-lang/rust/pull/63770#issuecomment-524104831 by allowing e.g., "foo".len() in a const context. In that case, it could be justified by "at some point we will allow this through stable-only code, but we are not going to right now due to lack of teaching material". Though in such a case, the reviewing process wrt. risks needs to be more robust.

tspiteri

comment created time in 4 hours

Pull request review commentrust-lang/rust-forge

Stabilizing const functions

 Features can be stabilized in a PR that replaces `#[unstable]` attributes with `  You can find the right version to use in the `#[stable]` attribute by checking the [Forge]. +### When a `const` function is being stabilized

Also btw, there's some notes here: https://github.com/rust-lang/rustc-guide/blob/master/src/stability.md#allow_internal_unstable

KodrAus

comment created time in 4 hours

Pull request review commentrust-lang/rust-forge

Stabilizing const functions

 Features can be stabilized in a PR that replaces `#[unstable]` attributes with `  You can find the right version to use in the `#[stable]` attribute by checking the [Forge]. +### When a `const` function is being stabilized++Const functions can be stabilized in a PR that replaces `#[rustc_const_unstable]` attributes with `#[rustc_const_stable]` ones. The [Constant Evaluation WG] should be pinged for input on whether or not the `const`-ness is something we want to commit to. This is particularly important when the function internally depends on other unstable `const` functions through `#[allow_internal_unstable]` attributes.

It's important that where unsafe and const is involved, e.g., for operations which are "unconst", that the const safety argument for the usage also be documented. That is, a const fn has additional determinism (e.g. run-time/compile-time results must correspond and the function's output only depends on its inputs...) restrictions that must be preserved, and those should be argued when unsafe is used.

KodrAus

comment created time in 4 hours

Pull request review commentrust-lang/rust-forge

Stabilizing const functions

 Features can be stabilized in a PR that replaces `#[unstable]` attributes with `  You can find the right version to use in the `#[stable]` attribute by checking the [Forge]. +### When a `const` function is being stabilized

If it is an intrinsic being exposed that is const-stabilized then the language team should also be pinged.

KodrAus

comment created time in 4 hours

pull request commentrust-lang/rust

Implement RFC 2532 – Associated Type Defaults

I'm so excited to finally see this land! Thanks so much @jonas-schievink for your hard work and thanks @nikomatsakis for diligently assembling all those test cases.

jonas-schievink

comment created time in 6 hours

issue commentrust-lang/rust

False warning: "unused logical operation that must be used"

For the record, I disagree that this is bad style, or it's at least debatable. It seems like it's taking advantage of the sugar that && brings over if, and Rust being a sideeffectful language, this should be expected.

As for whether this should be linted against or not, it seems to me it should not, but cc @rust-lang/lang if there are objections.

spacekookie

comment created time in 6 hours

issue closedrust-lang/rust

`Mut` in a pattern matched against a reference changes the binding's type

<!-- 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. -->

I tried this code:

let (a, mut b) = &(1, 2);
b = *a;

With nightly rustc, this code compiles. The hover information of VSCode shows that a is a &i32, while b is an i32.

I expected both a and b to be &i32.

closed time in 6 hours

arucil

issue commentrust-lang/rust

`Mut` in a pattern matched against a reference changes the binding's type

This is expected behavior.

What happens is pattern type checking is given the expected type &(i32, i32) and a tuple pattern at the root. A tuple pattern uses the "peeling" adjustment mode, resulting in removing & (as many as possible, in this case a single) from the expected type and then making the binding mode to pass down into the recursive steps by-ref. However, default binding modes only affect unannotated bindings, whereas annotated bindings (ref | ref mut | mut) get the binding mode from the annotation. Since the annotation is mut, the binding mode becomes by-value and thus the expected type passed down is used.

arucil

comment created time in 6 hours

delete branch Centril/parze

delete branch : patch-1

delete time in 13 hours

pull request commentrust-lang/rust

Move some `build-pass` tests to `check-pass`

cc @rust-lang/wg-const-eval since there are a lot of const related tests here

LeSeulArtichaut

comment created time in 14 hours

pull request commentrust-lang/rust

Minor refactoring of statement parsing

@bors r=estebank

Centril

comment created time in a day

push eventCentril/rust

Mazdak Farrokhzad

commit sha 7876711b9be1673631c4aaea63c289a984afbb0b

parse: address nitpick

view details

push time in a day

PR opened rust-lang/rust

typeck: use `Pattern` obligation cause more for better diagnostics F-or_patterns

r? @estebank

+284 -102

0 comment

28 changed files

pr created time in a day

create barnchCentril/rust

branch : typeck-pat

created branch time in a day

Pull request review commentrust-lang/rust

When encountering an Item in a pat context, point at the item def

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {         }          // Type-check the path.-        let pat_ty = self.instantiate_value_path(segments, opt_ty, res, pat.span, pat.hir_id).0;-        self.demand_suptype(pat.span, expected, pat_ty);+        let (pat_ty, pat_res) =+            self.instantiate_value_path(segments, opt_ty, res, pat.span, pat.hir_id);++        self.demand_suptype_diag(pat.span, expected, pat_ty).map(|e| {+            self.emit_bad_pat_path(e, pat.span, res, pat_res, qpath, segments, parent_pat)+        });         pat_ty     } +    fn emit_bad_pat_path(+        &self,+        mut e: DiagnosticBuilder<'_>,+        pat_span: Span,+        res: Res,+        pat_res: Res,+        qpath: &hir::QPath<'_>,+        segments: &'b [hir::PathSegment<'b>],+        parent_pat: Option<&Pat<'_>>,+    ) {+        let path = hir::print::to_string(self.tcx.hir(), |s| s.print_qpath(qpath, false));

btw, looking at this some more, could we get a snippet span instead of using HIR pretty? I would like to remove the HIR pretty printer soon-ish.

estebank

comment created time in a day

push eventCentril/rust

Dylan MacKenzie

commit sha f6d4720f26c92e9905c98b4ee2db832927e30a8a

Make `u8::is_ascii` a stable `const fn` `char::is_ascii` is already a stable `const fn`, so there is no reason for `u8::is_ascii` to be unstable.

view details

Dylan MacKenzie

commit sha bf732a11ecc319e0c0a840196bde1b5daccbdc85

Test `u8::is_ascii` alongside `char::is_ascii`

view details

Pyry Kontio

commit sha 86bf96291d8222dbec9e07461404ecb189be0a98

Implement split_inclusive for slice and str, an splitting iterator that includes the matched part in the iterated substrings as a terminator.

view details

Pyry Kontio

commit sha 5c9dc57cb587761561e85574c821a6f9c0c7cc67

Don't return empty slice on last iteration with matched terminator. Test reverse iteration.

view details

Vadim Petrochenkov

commit sha bcd7e2b38b3eb26004bf94a63814341329233491

rustc_lint: Move `unused_doc_comments` from pre-expansion to early lints

view details

Vadim Petrochenkov

commit sha 1bd6b98220a7d161288f04a03111ca77b0a4845d

Emit some additional `unused_doc_comments` lints outside of the main pass

view details

Camille GILLOT

commit sha 6e15faf68a2b1af57d6c94392329d148882d1650

Querify object_safety_violations.

view details

Camille GILLOT

commit sha 310f4707e59f696814e0e800be0b5ec6e81353d5

Make is_object_safe a method.

view details

Jonas Schievink

commit sha f77d1076ab63dc68c1bce2b8cc08e05b0ea885b0

Match MIR statements exhaustively

view details

Jonas Schievink

commit sha 3723fc1e45381ed8957b60967c8f7af5ab93e796

Use match ergonomics to simplify match

view details

Jonas Schievink

commit sha d4c6dfe6d6028dacc0dc59f509a823aad2d2cdf6

Handle resume args in `RequiresStorage` analysis

view details

Jonas Schievink

commit sha 71c4f76153590fc1744c7f73b94d2d39ae2e2f23

Reorder yield visitation order to match call

view details

Jonas Schievink

commit sha 689615724535d00c093c6c5dff0accaf6e38d9bc

Remap the resume place if necessary

view details

Jonas Schievink

commit sha 66b1ae40606ae0c07645ebc8f97e537d8d30ef73

Add more comments to `SuspensionPoint`

view details

Jonas Schievink

commit sha fc2702c96c0db560f55683e4cd33075c054ed062

Add regression test

view details

Nicholas Nethercote

commit sha 100ff5a25666a1903113ecff0dc63ad84e5bdff7

Revert `u8to64_le` changes from #68914. `SipHasher128`'s `u8to64_le` function was simplified in #68914. Unfortunately, the new version is slower, because it introduces `memcpy` calls with non-statically-known lengths. This commit reverts the change, and adds an explanatory comment (which is also added to `libcore/hash/sip.rs`). This barely affects `SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it does result in `SipHasher128` once again being consistent with `libcore/hash/sip.rs`.

view details

Dylan MacKenzie

commit sha 16790ae1f98692af59c37f6dd5db535fb3c5fe81

Revert "Rollup merge of #69280 - ecstatic-morse:promote-shuffle-no-special-case, r=petrochenkov" This reverts commit 61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c, reversing changes made to c6ad1e2c2a0c7e48537617d36085f866fa6a65a3.

view details

Mark Rousskov

commit sha e7ee42baeb54f6484fa76a88e03b3168ff3147ce

Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.

view details

Wesley Wiser

commit sha ec980a21b06de1988afff7275bd8d4d44f73722c

Add test for #69312 This bug was fixed by #67501. Closes #69312

view details

Ralf Jung

commit sha 821c4408f9752b17c40b9cb879fc5f430136ecd8

bump Miri

view details

push time in a day

Pull request review commentrust-lang/rust

[WIP] Cleanup `rmeta::MacroDef`

  #[macro_export] macro_rules! produces_async {-    () => (pub fn async() {})+    () => {+        pub fn async() {}+    };

So I tried:


        let rmeta::MacroDef { body, legacy } = data.get_macro(id.index, sess);
        let span = data.get_span(id.index, sess);

        let macro_full_name = data.def_path(id.index).to_string_friendly(|_| data.root.name);
        let source_name = FileName::Custom(macro_full_name);
        let source_content = rustc_ast_pretty::pprust::tts_to_string(body.clone());
        let source_file = sess.parse_sess.source_map().new_source_file(source_name, source_content);
        let span = span.with_lo(source_file.start_pos).with_hi(source_file.end_pos);

to see if the primary change was the cause, but it didn't result in reverting this case, so I'm thinking that's not the cause.

So at this point I don't really have a clue what could have caused this diff.

Centril

comment created time in a day

pull request commentrust-lang/rust

Rollup of 6 pull requests

@bors treeclosed-

Dylan-DPC

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         Ok(Mod { inner: inner_lo.to(hi), items, inline: true })     } +    fn parse_item_in_mod(+        &mut self,+        term: &TokenKind,+        stuck: &mut bool,+    ) -> PResult<'a, Option<Option<P<ast::Item>>>> {+        match self.parse_item()? {+            // We just made progress and we might have statements following this item.+            i @ Some(_) => {+                *stuck = false;+                Ok(Some(i))+            }+            // No progress and the previous attempt at statements failed, so terminate the loop.+            None if *stuck => Ok(None),+            None => Ok(self.recover_stmts_as_item(term, stuck)?.then_some(None)),+        }+    }++    /// Parse a contiguous list of statements until we reach the terminating token or EOF.+    /// When any statements were parsed, perform recovery and suggest wrapping the statements+    /// inside a function. If `stuck` becomes `true`, then this method should not be called+    /// unless we have advanced the cursor.+    fn recover_stmts_as_item(&mut self, term: &TokenKind, stuck: &mut bool) -> PResult<'a, bool> {+        let lo = self.token.span;+        let mut stmts = vec![];+        while ![term, &token::Eof].contains(&&self.token.kind) {+            let old_expected = std::mem::take(&mut self.expected_tokens);+            let snapshot = self.clone();+            let stmt = self.parse_full_stmt(true);+            self.expected_tokens = old_expected; // Restore expected tokens to before recovery.+            match stmt {+                Ok(None) => break,+                Ok(Some(stmt)) => stmts.push(stmt),+                Err(mut err) => {+                    // We couldn't parse as a statement. Rewind to the last one we could for.+                    // Also notify the caller that we made no progress, meaning that the method+                    // should not be called again to avoid non-termination.+                    err.cancel();+                    *self = snapshot;+                    *stuck = true;+                    break;+                }+            }+        }++        let recovered = !stmts.is_empty();+        if recovered {+            // We parsed some statements and have recovered, so let's emit an error.+            self.error_stmts_as_item_suggest_fn(lo, stmts);+        }+        Ok(recovered)+    }++    fn error_stmts_as_item_suggest_fn(&self, lo: Span, stmts: Vec<ast::Stmt>) {+        use syntax::ast::*;++        let span = lo.to(self.prev_span);+        let spans: MultiSpan = match &*stmts {+            [] | [_] => span.into(),+            [x, .., y] => vec![x.span, y.span].into(),

Switching to just span in all cases then. :)

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         Ok(Mod { inner: inner_lo.to(hi), items, inline: true })     } +    fn parse_item_in_mod(+        &mut self,+        term: &TokenKind,+        stuck: &mut bool,+    ) -> PResult<'a, Option<Option<P<ast::Item>>>> {+        match self.parse_item()? {+            // We just made progress and we might have statements following this item.+            i @ Some(_) => {+                *stuck = false;+                Ok(Some(i))+            }+            // No progress and the previous attempt at statements failed, so terminate the loop.+            None if *stuck => Ok(None),+            None => Ok(self.recover_stmts_as_item(term, stuck)?.then_some(None)),+        }+    }++    /// Parse a contiguous list of statements until we reach the terminating token or EOF.+    /// When any statements were parsed, perform recovery and suggest wrapping the statements+    /// inside a function. If `stuck` becomes `true`, then this method should not be called+    /// unless we have advanced the cursor.+    fn recover_stmts_as_item(&mut self, term: &TokenKind, stuck: &mut bool) -> PResult<'a, bool> {+        let lo = self.token.span;+        let mut stmts = vec![];+        while ![term, &token::Eof].contains(&&self.token.kind) {+            let old_expected = std::mem::take(&mut self.expected_tokens);+            let snapshot = self.clone();+            let stmt = self.parse_full_stmt(true);+            self.expected_tokens = old_expected; // Restore expected tokens to before recovery.+            match stmt {+                Ok(None) => break,+                Ok(Some(stmt)) => stmts.push(stmt),+                Err(mut err) => {+                    // We couldn't parse as a statement. Rewind to the last one we could for.+                    // Also notify the caller that we made no progress, meaning that the method+                    // should not be called again to avoid non-termination.+                    err.cancel();+                    *self = snapshot;+                    *stuck = true;+                    break;+                }+            }+        }++        let recovered = !stmts.is_empty();+        if recovered {+            // We parsed some statements and have recovered, so let's emit an error.+            self.error_stmts_as_item_suggest_fn(lo, stmts);+        }+        Ok(recovered)+    }++    fn error_stmts_as_item_suggest_fn(&self, lo: Span, stmts: Vec<ast::Stmt>) {+        use syntax::ast::*;++        let span = lo.to(self.prev_span);+        let spans: MultiSpan = match &*stmts {+            [] | [_] => span.into(),+            [x, .., y] => vec![x.span, y.span].into(),

Why do we want .until(...) though? That would leave out e.g. the end of the last statement? I would expect x.to(y) as the alternative, but that's equivalent to span.

Centril

comment created time in a day

pull request commentrust-lang/rust

Cherry-pick the LLVM fix for #69225

I have not tried to reapply #67174 yet -- cc @kraai @shahn

I would suggest attempting to reapply it only on master.

cuviper

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 LL | pub(crate) () fn foo() {}    |    = help: you likely meant to define an item, e.g., `pub(crate) fn foo() {}` -error: expected item, found `(`+error: statements cannot reside in modules   --> $DIR/pub-restricted-error-fn.rs:1:12    | LL | pub(crate) () fn foo() {}-   |            ^ expected item+   |            ^^

I read your comment again; it makes more sense now since you're talking only about the suggestion -- I think we could use the same flag and pass it in to avoid everything except for the primary message, and instead do "remove the statements".

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 LL | pub(crate) () fn foo() {}    |    = help: you likely meant to define an item, e.g., `pub(crate) fn foo() {}` -error: expected item, found `(`+error: statements cannot reside in modules   --> $DIR/pub-restricted-error-fn.rs:1:12    | LL | pub(crate) () fn foo() {}-   |            ^ expected item+   |            ^^

But is this a common case? And if it is, does the first error not suggest what the problem is and how to fix it? And is it not better to recover than to fatally error? Otherwise we could have some flag when calling parse_item_common_ which signifies that we've parsed at least the visibility / defaultness, if you would prefer the error as-is, though that is adding code complexity, so consider whether this is common enough to be worth it.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {      /// Parses associated items.     fn parse_assoc_item(&mut self, req_name: ReqName) -> PResult<'a, Option<Option<P<AssocItem>>>> {-        Ok(self.parse_item_(req_name)?.map(|Item { attrs, id, span, vis, ident, kind, tokens }| {+        let item = self.parse_item_(req_name)?;+        Ok(item.map(|Item { attrs, id, span, vis, ident, kind, tokens }| {

Isn't that handled in parse_item_list? Not sure what the relation to this PR is though.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

-error: expected item, found `;`+error: statements cannot reside in modules   --> $DIR/issue-49040.rs:1:28    | LL | #![allow(unused_variables)];-   |                            ^ help: remove this semicolon+   |                            ^+   |+   = note: the program entry point starts in `fn main() { ... }`, defined in `main.rs`+   = note: for more on functions and how to structure your program, see https://doc.rust-lang.org/book/ch03-03-how-functions-work.html+help: consider moving the statements into a function+   |+LL | #![allow(unused_variables)]fn my_function() { }+   |                            ^^^^^^^^^^^^^^^^^^^^

Would suggest https://github.com/rust-lang/rust/pull/69445#discussion_r383591643 to fix it.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         Ok(Mod { inner: inner_lo.to(hi), items, inline: true })     } +    fn parse_item_in_mod(+        &mut self,+        term: &TokenKind,+        stuck: &mut bool,+    ) -> PResult<'a, Option<Option<P<ast::Item>>>> {+        match self.parse_item()? {+            // We just made progress and we might have statements following this item.+            i @ Some(_) => {+                *stuck = false;+                Ok(Some(i))+            }+            // No progress and the previous attempt at statements failed, so terminate the loop.+            None if *stuck => Ok(None),+            None => Ok(self.recover_stmts_as_item(term, stuck)?.then_some(None)),+        }+    }++    /// Parse a contiguous list of statements until we reach the terminating token or EOF.+    /// When any statements were parsed, perform recovery and suggest wrapping the statements+    /// inside a function. If `stuck` becomes `true`, then this method should not be called+    /// unless we have advanced the cursor.+    fn recover_stmts_as_item(&mut self, term: &TokenKind, stuck: &mut bool) -> PResult<'a, bool> {+        let lo = self.token.span;+        let mut stmts = vec![];+        while ![term, &token::Eof].contains(&&self.token.kind) {+            let old_expected = std::mem::take(&mut self.expected_tokens);+            let snapshot = self.clone();+            let stmt = self.parse_full_stmt(true);+            self.expected_tokens = old_expected; // Restore expected tokens to before recovery.+            match stmt {+                Ok(None) => break,+                Ok(Some(stmt)) => stmts.push(stmt),+                Err(mut err) => {+                    // We couldn't parse as a statement. Rewind to the last one we could for.+                    // Also notify the caller that we made no progress, meaning that the method+                    // should not be called again to avoid non-termination.+                    err.cancel();+                    *self = snapshot;+                    *stuck = true;+                    break;+                }+            }+        }++        let recovered = !stmts.is_empty();+        if recovered {+            // We parsed some statements and have recovered, so let's emit an error.+            self.error_stmts_as_item_suggest_fn(lo, stmts);+        }+        Ok(recovered)+    }++    fn error_stmts_as_item_suggest_fn(&self, lo: Span, stmts: Vec<ast::Stmt>) {+        use syntax::ast::*;++        let span = lo.to(self.prev_span);+        let spans: MultiSpan = match &*stmts {+            [] | [_] => span.into(),+            [x, .., y] => vec![x.span, y.span].into(),

Not sure what you mean; in the first arm the span spans as long as [first.span] would and in the case of [] it's unreachable (but I didn't unreachable!() because it's more code).

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         Ok(Mod { inner: inner_lo.to(hi), items, inline: true })     } +    fn parse_item_in_mod(+        &mut self,+        term: &TokenKind,+        stuck: &mut bool,+    ) -> PResult<'a, Option<Option<P<ast::Item>>>> {+        match self.parse_item()? {+            // We just made progress and we might have statements following this item.+            i @ Some(_) => {+                *stuck = false;+                Ok(Some(i))+            }+            // No progress and the previous attempt at statements failed, so terminate the loop.+            None if *stuck => Ok(None),+            None => Ok(self.recover_stmts_as_item(term, stuck)?.then_some(None)),+        }+    }++    /// Parse a contiguous list of statements until we reach the terminating token or EOF.+    /// When any statements were parsed, perform recovery and suggest wrapping the statements+    /// inside a function. If `stuck` becomes `true`, then this method should not be called+    /// unless we have advanced the cursor.+    fn recover_stmts_as_item(&mut self, term: &TokenKind, stuck: &mut bool) -> PResult<'a, bool> {+        let lo = self.token.span;+        let mut stmts = vec![];+        while ![term, &token::Eof].contains(&&self.token.kind) {+            let old_expected = std::mem::take(&mut self.expected_tokens);+            let snapshot = self.clone();+            let stmt = self.parse_full_stmt(true);+            self.expected_tokens = old_expected; // Restore expected tokens to before recovery.+            match stmt {+                Ok(None) => break,+                Ok(Some(stmt)) => stmts.push(stmt),+                Err(mut err) => {+                    // We couldn't parse as a statement. Rewind to the last one we could for.+                    // Also notify the caller that we made no progress, meaning that the method+                    // should not be called again to avoid non-termination.+                    err.cancel();+                    *self = snapshot;+                    *stuck = true;+                    break;+                }+            }+        }++        let recovered = !stmts.is_empty();+        if recovered {+            // We parsed some statements and have recovered, so let's emit an error.+            self.error_stmts_as_item_suggest_fn(lo, stmts);+        }+        Ok(recovered)+    }++    fn error_stmts_as_item_suggest_fn(&self, lo: Span, stmts: Vec<ast::Stmt>) {+        use syntax::ast::*;++        let span = lo.to(self.prev_span);+        let spans: MultiSpan = match &*stmts {+            [] | [_] => span.into(),+            [x, .., y] => vec![x.span, y.span].into(),+        };++        // Perform coarse grained inference about returns.+        // We use this to tell whether `main` is an acceptable name+        // and if `-> _` or `-> Result<_, _>` should be used instead of defaulting to unit.+        #[derive(Default)]+        struct RetInfer(bool, bool, bool);+        let RetInfer(has_ret_unit, has_ret_expr, has_try_expr) = {+            impl Visitor<'_> for RetInfer {+                fn visit_expr_post(&mut self, expr: &Expr) {+                    match expr.kind {+                        ExprKind::Ret(None) => self.0 = true,    // `return`+                        ExprKind::Ret(Some(_)) => self.1 = true, // `return $expr`+                        ExprKind::Try(_) => self.2 = true,       // `expr?`+                        _ => {}+                    }+                }+            }+            let mut visitor = RetInfer::default();+            for stmt in &stmts {+                visitor.visit_stmt(stmt);+            }+            if let StmtKind::Expr(_) = &stmts.last().unwrap().kind {+                visitor.1 = true; // The tail expression.

My thinking is that worst case you get -> _ and you write that, and the compiler tells you to write -> () cause it's inferring the return type.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         } else if vis.node.is_pub() && self.isnt_macro_invocation() {             self.recover_missing_kw_before_item()?;             return Ok(None);-        } else if macros_allowed && self.token.is_path_start() {+        } else if let Some(kind) = if macros_allowed && self.token.is_path_start() {+            self.parse_item_macro(vis, mod_stmt)?+        } else {+            None+        } {             // MACRO INVOCATION ITEM-            (Ident::invalid(), ItemKind::Mac(self.parse_item_macro(vis)?))+            (Ident::invalid(), ItemKind::Mac(kind))         } else {

I would have preferred to write this with let-chains but they ain't implemented yet sadly.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {         } else if vis.node.is_pub() && self.isnt_macro_invocation() {             self.recover_missing_kw_before_item()?;             return Ok(None);-        } else if macros_allowed && self.token.is_path_start() {+        } else if let Some(kind) = if macros_allowed && self.token.is_path_start() {+            self.parse_item_macro(vis, mod_stmt)?+        } else {+            None+        } {             // MACRO INVOCATION ITEM-            (Ident::invalid(), ItemKind::Mac(self.parse_item_macro(vis)?))+            (Ident::invalid(), ItemKind::Mac(kind))         } else {

@estebank we could do something like:

        } else if self.maybe_consume_incorrect_semicolon(&[]) {
            let lo = self.token.span;
            self.parse_item_kind(attrs, macros_allowed, lo, vis, def, req_name, mod_stmt)?
        } else {
Centril

comment created time in a day

push eventCentril/rust

Mazdak Farrokhzad

commit sha 1eb0844f5d4321a7769238af740e6d93d3e966e4

parse: move condition into guard

view details

push time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {     }      /// Parses an item macro, e.g., `item!();`.-    fn parse_item_macro(&mut self, vis: &Visibility) -> PResult<'a, Mac> {-        let path = self.parse_path(PathStyle::Mod)?; // `foo::bar`-        self.expect(&token::Not)?; // `!`+    fn parse_item_macro(&mut self, vis: &Visibility, mod_stmt: bool) -> PResult<'a, Option<Mac>> {+        let parse_prefix = |p: &mut Self| -> PResult<'a, ast::Path> {+            let path = p.parse_path(PathStyle::Mod)?; // `foo::bar`+            p.expect(&token::Not)?; // `!`+            Ok(path)+        };+        let path = if mod_stmt {+            // We're in statement-as-module-item recovery mode.+            // To avoid "stealing" syntax from e.g. `x.f()` as a module-level statement,+            // we backtrack if we failed to parse `$path!`; after we have, we commit firmly.+            // This is only done when `mod_stmt` holds to avoid backtracking inside functions.+            let snapshot = self.clone();+            match parse_prefix(self) {+                Ok(path) => path,+                Err(mut err) => {+                    // Assert that this is only for diagnostics!+                    // This is a safeguard against breaking LL(k) accidentally in the spec,+                    // assuming no one has gated the syntax with something like `#[cfg(FALSE)]`.+                    err.delay_as_bug();+                    *self = snapshot;+                    return Ok(None);

An alternative to this might be bounded look-ahead for some fixed k, but that is ostensibly less good for diagnostics and trickier to encode correctly. Path parsing is also rarely long and $path! is a fairly unique sequence of tokens.

Centril

comment created time in a day

PR opened rust-lang/rust

Minor refactoring of statement parsing

Extracted out of https://github.com/rust-lang/rust/pull/69445.

r? @estebank

+58 -64

0 comment

1 changed file

pr created time in a day

create barnchCentril/rust

branch : minor-stmt-refactor

created branch time in a day

pull request commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

@bors try @rust-timer queue

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

+error: statements cannot reside in modules+  --> $DIR/main.rs:5:1+   |+LL | let x = 0;+   | ^^^^^^^^^^+...+LL | Ok(42u16)+   | ^^^^^^^^^+   |+   = note: the program entry point starts in `fn main() { ... }`, defined in `main.rs`+   = note: for more on functions and how to structure your program, see https://doc.rust-lang.org/book/ch03-03-how-functions-work.html+help: consider moving the statements into a function+   |+LL | fn my_function() -> Result<_, _> {+LL |     let x = 0;+LL |     x;+LL |     x;+LL |     x;+LL |     x;+ ...++error: statements cannot reside in modules+  --> $DIR/main.rs:17:1+   |+LL | if true {}+   | ^^^^^^^^^^+   |+   = note: the program entry point starts in `fn main() { ... }`, defined in `main.rs`+   = note: for more on functions and how to structure your program, see https://doc.rust-lang.org/book/ch03-03-how-functions-work.html+help: consider moving the statements into a function+   |+LL | fn my_function() -> _ { if true { } }+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^++error: statements cannot reside in modules+  --> $DIR/main.rs:21:1+   |+LL | x.y();+   | ^^^^^^+LL | let x = 0;+LL | x;+   | ^^+   |+   = note: the program entry point starts in `fn main() { ... }`, defined in `main.rs`+   = note: for more on functions and how to structure your program, see https://doc.rust-lang.org/book/ch03-03-how-functions-work.html+help: consider moving the statements into a function+   |+LL | fn my_function() { x.y(); let x = 0; x; }

Not sure why this is saying my_function as opposed to main.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

 impl<'a> Parser<'a> {     }      /// Parses an item macro, e.g., `item!();`.-    fn parse_item_macro(&mut self, vis: &Visibility) -> PResult<'a, Mac> {-        let path = self.parse_path(PathStyle::Mod)?; // `foo::bar`-        self.expect(&token::Not)?; // `!`+    fn parse_item_macro(&mut self, vis: &Visibility, mod_stmt: bool) -> PResult<'a, Option<Mac>> {+        let parse_prefix = |p: &mut Self| -> PResult<'a, ast::Path> {+            let path = p.parse_path(PathStyle::Mod)?; // `foo::bar`+            p.expect(&token::Not)?; // `!`+            Ok(path)+        };+        let path = if mod_stmt {+            // We're in statement-as-module-item recovery mode.+            // To avoid "stealing" syntax from e.g. `x.f()` as a module-level statement,+            // we backtrack if we failed to parse `$path!`; after we have, we commit firmly.+            // This is only done when `mod_stmt` holds to avoid backtracking inside functions.+            let snapshot = self.clone();+            match parse_prefix(self) {+                Ok(path) => path,+                Err(mut err) => {+                    // Assert that this is only for diagnostics!+                    // This is a safeguard against breaking LL(k) accidentally in the spec,+                    // assuming no one has gated the syntax with something like `#[cfg(FALSE)]`.+                    err.delay_as_bug();+                    *self = snapshot;+                    return Ok(None);

This use of backtracking bears some discussion. It only happens outside of function bodies to avoid regressing perf or accepting more syntax. In the case of module level, if we hit EOF we will not even attempt parsing an item so it shouldn't have a perf implication that way?

Centril

comment created time in a day

PR opened rust-lang/rust

EXPERIMENT: Recover on stmts/exprs at module level, suggesting to wrap in function

TODO: write description

r? @petrochenkov @estebank

+596 -203

0 comment

28 changed files

pr created time in a day

push eventCentril/rust

Mazdak Farrokhzad

commit sha 37e08fdd3dfc0f4ff84ac6a00b22d5685b409a38

wip

view details

Mazdak Farrokhzad

commit sha 0748f6042acc1c0320017f2ae30d10e9f11f4054

parse: backtrack to avoid stealing e.g. `x.f()` at mod level.

view details

push time in a day

pull request commentrust-lang/rust

Implement RFC 2532 – Associated Type Defaults

I believe that part is not included per PR OP:

This is a partial implementation that is still missing the changes to object types, since I ran into some trouble while implementing that. [...]

jonas-schievink

comment created time in a day

pull request commentrust-lang/rust

[stable] Cherry-pick LLVM fix for 1.41.1

@bors treeclosed=100

pietroalbini

comment created time in a day

pull request commentrust-lang/rust

Rollup of 6 pull requests

@bors retry yielding to stable PR

Dylan-DPC

comment created time in a day

push eventCentril/rust

Ralf Jung

commit sha 821c4408f9752b17c40b9cb879fc5f430136ecd8

bump Miri

view details

Ralf Jung

commit sha 1a0e2001bca6cbb3fc8496b83d5f847e11f459e6

fix miri and bootstrap interaction

view details

ridiculousfish

commit sha 9e41c4b682f625ae7860255c2d17790f5d9f324a

Relax str::get_unchecked precondition to permit empty slicing Prior to this commit, `str` documented that `get_unchecked` had the precondition that "`begin` must come before `end`". This would appear to prohibit empty slices (i.e. begin == end). In practice, get_unchecked is called often with empty slices. Let's relax the precondition so as to allow them.

view details

Daniel Henry-Mantilla

commit sha 2cf339aeda77f29a8ad609f88b67591e0a668b89

Fix doc example for `MaybeUninit::get_mut()` Suggested by @ametisf in https://github.com/rust-lang/rust/pull/65948#issuecomment-589988183 Co-Authored-By: Frantisek Fladung <fladufra@fel.cvut.cz>

view details

Guillaume Gomez

commit sha 78e4bd1c758b59593c02e2785e8024dbec6069f4

Clean up E0367 explanation

view details

Michael Morehouse

commit sha c103a16f3a0c56351270eca9624acc27e2804bce

Update links Formatting fixes Now that I can actually run `python x.py test src/tools/tidy` locally ... my god it takes a long time to compile when you're on a cellular connection. Removing unnecessary whitespaces Updates src/test/ui/json-short.stderr golden test file Fixes test failure by updating the golden file for changes in src/librustc_error_codes/error_codes/E0601.md Update src/librustc_error_codes/error_codes/E0080.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0080.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0080.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0154.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0154.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0661.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0662.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0663.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0664.md Co-Authored-By: varkor <github@varkor.com> Update src/test/ui/json-short.stderr Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0260.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0154.md Co-Authored-By: varkor <github@varkor.com> Update src/librustc_error_codes/error_codes/E0260.md Co-Authored-By: varkor <github@varkor.com> Apply suggestions from code review Co-Authored-By: varkor <github@varkor.com> Fixing 1 character over 80 cascade

view details

Jakub Kądziołka

commit sha b3e0d272af149c4126f90a0262d796d7401ba7a1

docs: Stdin::read_line: mention the appending

view details

Mazdak Farrokhzad

commit sha fa2a792491ed28530146ee55a46128c05a8026ad

add `Span` to `ast::Defaultness::Default`.

view details

Mazdak Farrokhzad

commit sha d41fc138bf57db0d5491d0886a676c3ade4b746f

`parse_defaultness`: avoid hardcoded list of keywords.

view details

Mazdak Farrokhzad

commit sha 7017058e6b289ea6253e62b9ffdae5dea036855f

ast: add `Defaultness` to `Item`, making `AssocItem` an alias.

view details

Mazdak Farrokhzad

commit sha 9ed4c0998381901ac68c19c30c375f5760016759

parse: extract `error_on_unmatched_vis`.

view details

Mazdak Farrokhzad

commit sha a920a056035d3aa8f5e90ff174764a886366d379

parse: recover `default` on free items.

view details

Mazdak Farrokhzad

commit sha a63f35daeefc4ae89ba5b6bd0323d97bb0d050e6

parse: use `parse_item_common` in `parse_foreign_item`.

view details

Mazdak Farrokhzad

commit sha a05c83b2ebc4e85e32f723e708a40dbd3f165cd0

parse: use `parse_item_common` in `parse_assoc_item_`.

view details

Mazdak Farrokhzad

commit sha a3b08294141bb209f9cd6a0d0b9bf56890edc742

parse: move token hack into `parse_item_common`.

view details

Mazdak Farrokhzad

commit sha abc46a579b336f7ac686b8f24c0ff31be8726038

parse: harden `default` test.

view details

Mazdak Farrokhzad

commit sha d446c73e6ab94fe37f7d7b8f2abf633ed6344c8a

parser: refactor away at_end

view details

Mazdak Farrokhzad

commit sha ab84914fe47aa2da615c9e759e686d1a45f8aae3

parser: tweak unmatched wording

view details

Mazdak Farrokhzad

commit sha b01c1e2092b0d3c4e86aedf1e0875898fbde21e3

parser: tweak item kind wording

view details

Mazdak Farrokhzad

commit sha 842027f35bd0c957fff862ef864f4fc57988ed7e

parse: `NtItem` -> `parse_item_common`.

view details

push time in a day

pull request commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

r? @Mark-Simulacrum cc @rust-lang/wg-diagnostics

jakevossen5

comment created time in a day

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

+use crate::registry::RegistryResult::HasLongDescription; use rustc_data_structures::fx::FxHashMap; +pub enum RegistryResult {+    InvalidErrorCode,+    NoLongDescription,+    HasLongDescription(&'static str),+}++impl RegistryResult {+    pub fn has_value(&self) -> bool {+        match self {+            HasLongDescription(_s) => true,+            _ => false,+        }+    }+}+ #[derive(Clone)] pub struct Registry {-    descriptions: FxHashMap<&'static str, &'static str>,+    long_descriptions: FxHashMap<&'static str, Option<&'static str>>, }  impl Registry {-    pub fn new(descriptions: &[(&'static str, &'static str)]) -> Registry {-        Registry { descriptions: descriptions.iter().cloned().collect() }+    pub fn new(long_descriptions: &[(&'static str, Option<&'static str>)]) -> Registry {+        Registry { long_descriptions: long_descriptions.iter().cloned().collect() }     } -    pub fn find_description(&self, code: &str) -> Option<&'static str> {-        self.descriptions.get(code).cloned()+    pub fn find_description(&self, code: &str) -> RegistryResult {+        if !self.long_descriptions.contains_key(code) {+            return RegistryResult::InvalidErrorCode;+        }+        let entry = self.long_descriptions.get(code).unwrap(); // use unwrap here because we checked the key exists already

Nit: let's move the comment to it's own line above the statement; getting a bit too long to the right.

jakevossen5

comment created time in a day

delete branch Centril/pareen

delete branch : patch-1

delete time in a day

issue commentrust-lang/rust

Tracking issue for conflicting `repr(...)` hints future compatibility

Beta crater results in https://github.com/rust-lang/rust/pull/68586#issuecomment-586624786:

error[E0566]: conflicting representation hints

Number of crates regressed: 2

* [`enum-utils v0.1.2`](https://crater-reports.s3.amazonaws.com/beta-1.42-1/beta-2020-02-05/reg/enum-utils-0.1.2/log.txt)

* [`ovr-mobile-sys v0.4.0`](https://crater-reports.s3.amazonaws.com/beta-1.42-rustdoc-1/beta-2020-02-05/reg/ovr-mobile-sys-0.4.0/log.txt)
  • enum-utils has 0 rev deps, (btw, cc @ecstatic-morse)
  • ovr-mobile-sys was the servo dependency and it seems to have been fixed already.

Based on these very limited results I don't think it's justified to retcon this into the specification, and making it an error again in the near future should be possible.

Centril

comment created time in a day

Pull request review commentrust-lang/rust

Generalized article_and_description

 LL |     fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {    |            lifetime `'a` defined here LL |  LL |         if x > y { x } else { y }-   |                    ^ function was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1`+   |                    ^ method was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1`

We should rename DefKind::Method to DefKind::AssocFn so that it fits with the scheme used for AssocTy, AssocConst, etc. cc @petrochenkov @eddyb

mark-i-m

comment created time in a day

pull request commentrust-lang/rust

Account for bounds and asociated items when denying `_`

@estebank Sorry, I don't think I have the time to invest into understanding this as well as I would want to to get to r+. :(

estebank

comment created time in a day

delete branch Centril/rust-libp2p

delete branch : patch-1

delete time in a day

pull request commentrust-lang/rust

Mark attributes consumed by `check_mod_attrs` as normal

r? @Mark-Simulacrum @petrochenkov

tmiasko

comment created time in a day

pull request commentrust-lang/rfcs

Cargo report future-incompat

@pnkfelix

  1. The inference is correct. :)
  2. I do take issue with:

If our primary goal is to minimize user frustration with our tools and ecosystem, then future-incompatibility reporting for a given lint should be turned only after much of the crate ecosystem have new fixed versions. In other words, we should strive for a steady-state where the typical user response to a future-incompatibility report is that user then runs cargo update, or they ask for a (pre-existing) PR to be merged.

I think this nudges us towards a policy that is more conservative than today, whereas I think we need to move in the opposite direction as the compiler team has failed to actually triage the C-future-compatibility bugs as e.g. noted in:

At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.

and generally does not invest the time into fixing the spec bugs.

  1. But it is conditional, as you mention, so perhaps since there is disagreement re. X, then Y won't happen? I don't know what to make of that, as it sorta still implies that X is true, and so it implies a shift in sentiment towards a more conservative breakage policy than I believe is the case today.
pnkfelix

comment created time in a day

pull request commentrust-lang/rfcs

Cargo report future-incompat

One may argue that this is exactly the right alignment of incentives: those who are proposing things that may break should feel the pain that they may break. That this disincentives them to make said changes is a positive, not a negative.

I think it's definitely not a positive to dis-incentivize fixing bugs (and worse yet, soundness holes when those occurs) in the compiler. This also increases the requirements to get things right when shipping and the speed at which we can make improvements if we then impose a lot of constraints when mistakes are made in implementation. Dis-incentivizing making the change in the first place, particularly as it relates to soundness holes is I think counter to the spirit (and text) of RFC 1122 and to the notion that Rust is a safe language (which is more important than backwards compatibility).

It could also be considered unfair that the community bears the burden of unglamorous, repetitive, and boring work, simply because a team would rather not do it, yet wants to make a change anyway.

It's not repetitive because it's distributed to several people who might only have to do a small change in a single crate as opposed to the team or the PR author who would have to do the same fix over and over again (particularly if the regression is large). So no, I do not agree that it is an unfair burden when any individual person's burden is small. (It's even less unfair when large companies are involved.)

pnkfelix

comment created time in a day

pull request commentrust-lang/rfcs

Cargo report future-incompat

Oh so I should also mention that I'm assuming a similar transitionary role that happens today, which looks something like:

  • Behavior is changed, crates says impact is huge, warning is implemented instead

  • Time passes, some authors see the warning, some crates are updated

  • Eventually another rust-lang/rust PR attempts to make the warning a hard error, crater still says there's lots of breakage

  • rust-lang/rust authors proactively send PRs to core broken crates. Some changes are merged

  • this is when the future incompat lint is turned on, literally everyone gets warnings

  • More crates are published and more builds are warning-free

I think it's true that taken literally it's a bit too strict to require something actionable. I feel though that when future incompat lints are turned on is late enough in the process that your action item is very likely to either be cargo update or "go ping the PR and ask for a merge"

I don't really mind one way or another whether it's in the RFC itself, but I think it may be worthwhile to perhaps write a bit about when we expect future incompat lints to get turned on. For example the idea that given a warning it's "at least somewhat actionable", with examples such as cargo update or "go poke an already-existing PR" or something like that may be good to have.

I do not think this is the place to decide on such a policy and that this should be left to the language and compiler teams to tweak things as necessary. I also don't agree with the guidance proposed. It is wildly more conservative than was discussed originally regarding when the infrastructure in https://github.com/rust-lang/rust/pull/59658 would be activated. Imposing these requirements also doesn't seem justifiable by RFC 1122. There are a number of problems with it that render the guidance quite counter productive to fixing bugs in the compiler:

  • It moves almost all of the burden on fixing the bugs in the crates to the compiler and language teams and the PR author which do not have these resources to file PRs actively to all the crates when they are numerous. I think it's also unfair to centralize the (mostly unglamorous, repetitive, and boring) work to a few people who mostly do free work and don't have time rather than to distribute the work to more people.

  • It's not applicable (or not practically applicable) in cases like https://github.com/rust-lang/rust/issues/56484 where the author of the traitobject crate has disappeared and no attempt to reach them via PRs, emails, etc. has been productive. The only fix here is to fork the crate.

  • Because it places heavy burdens on fixing the bugs the practical effect is that the compiler team doesn't triage these bugs to drive fixing them to completion and so the bugs won't be fixed.

pnkfelix

comment created time in a day

pull request commentholochain/holochain-rust

holochain_metrics: use `StatsByMetric(...)` due to differing type params

I assume you'll deal with merging this into develop then. :)

Centril

comment created time in a day

issue commentrust-lang/rust

Meta tracking issue for `const fn`

This issue is not for discussion about specific extensions to const fn or const evaluation and only exists to provide links to other places that track the progress of specific issues. If you wish to discuss some subject related to const evaluation or const fn, please find an existing appropriate issue below or create an new issue and comment here with a link to the newly created issue.

Lokathor

comment created time in a day

Pull request review commentrust-lang/rust

Parse & reject postfix operators after casts

 impl<'a> Parser<'a> {                             )                             .emit(); -                        Ok(expr)+                        expr                     }                     Err(mut path_err) => {                         // Couldn't parse as a path, return original error and parser state.                         path_err.cancel();                         mem::replace(self, parser_snapshot_after_type);-                        Err(type_err)+                        return Err(type_err);                     }                 }             }-        }+        };++        self.parse_and_disallow_postfix_after_cast(cast_expr)+    }++    /// Parses a postfix operators such as `.`, `?`, or index (`[]`) after a cast,+    /// then emits an error and returns the newly parsed tree.+    /// The resulting parse tree for `&x as T[0]` has a precedence of `((&x) as T)[0]`.+    fn parse_and_disallow_postfix_after_cast(+        &mut self,+        cast_expr: P<Expr>,+    ) -> PResult<'a, P<Expr>> {+        use std::collections::hash_map::DefaultHasher;+        use std::hash::Hasher;+        // Hash the memory location of expr before parsing any following postfix operators.+        // This will be compared with the hash of the output expression.+        // If they different we can assume we parsed another expression because the existing expression is not reallocated.+        let mut before_hasher = DefaultHasher::new();+        std::ptr::hash(&*cast_expr, &mut before_hasher);+        let before_hash = before_hasher.finish();+        let span = cast_expr.span;+        let with_postfix = self.parse_dot_or_call_expr_with_(cast_expr, span)?;++        let mut after_hasher = DefaultHasher::new();+        std::ptr::hash(&*with_postfix, &mut after_hasher);+        let after_hash = after_hasher.finish();++        // Check if an illegal postfix operator has been added after the cast.+        // If the resulting expression is not a cast, or has a different memory location, it is an illegal postfix operator.+        if !matches!(with_postfix.kind, ExprKind::Cast(_, _) | ExprKind::Type(_, _))+            || after_hash != before_hash+        {+            let msg = format!(+                "casts cannot be followed by {}",+                match with_postfix.kind {+                    ExprKind::Index(_, _) => "indexing",+                    ExprKind::Try(_) => "?",+                    ExprKind::Field(_, _) => "a field access",+                    ExprKind::MethodCall(_, _) => "a method call",+                    ExprKind::Call(_, _) => "a function call",+                    ExprKind::Await(_) => "`.await`",+                    _ => unreachable!("parse_dot_or_call_expr_with_ shouldn't produce this"),+                }+            );+            let mut err = self.struct_span_err(span, &msg);+            // if type ascription is "likely an error", the user will already be getting a useful
            // If type ascription is "likely an error", the user will already be getting a useful
daboross

comment created time in a day

Pull request review commentrust-lang/rust

Parse & reject postfix operators after casts

 impl<'a> Parser<'a> {                             )                             .emit(); -                        Ok(expr)+                        expr                     }                     Err(mut path_err) => {                         // Couldn't parse as a path, return original error and parser state.                         path_err.cancel();                         mem::replace(self, parser_snapshot_after_type);-                        Err(type_err)+                        return Err(type_err);                     }                 }             }-        }+        };++        self.parse_and_disallow_postfix_after_cast(cast_expr)+    }++    /// Parses a postfix operators such as `.`, `?`, or index (`[]`) after a cast,+    /// then emits an error and returns the newly parsed tree.+    /// The resulting parse tree for `&x as T[0]` has a precedence of `((&x) as T)[0]`.+    fn parse_and_disallow_postfix_after_cast(+        &mut self,+        cast_expr: P<Expr>,+    ) -> PResult<'a, P<Expr>> {+        use std::collections::hash_map::DefaultHasher;+        use std::hash::Hasher;+        // Hash the memory location of expr before parsing any following postfix operators.+        // This will be compared with the hash of the output expression.+        // If they different we can assume we parsed another expression because the existing expression is not reallocated.+        let mut before_hasher = DefaultHasher::new();+        std::ptr::hash(&*cast_expr, &mut before_hasher);+        let before_hash = before_hasher.finish();+        let span = cast_expr.span;+        let with_postfix = self.parse_dot_or_call_expr_with_(cast_expr, span)?;++        let mut after_hasher = DefaultHasher::new();+        std::ptr::hash(&*with_postfix, &mut after_hasher);+        let after_hash = after_hasher.finish();

Maybe simplify this to:

let addr_before = &*cast_expr as *const _ as usize;
let span = cast_expr.span;
let with_postfix = self.parse_dot_or_call_expr_with_(cast_expr, span)?;
let changed = addr_before != &*with_postfix as *const _ as usize;
daboross

comment created time in a day

pull request commentrust-lang/rust

Allow calculating the layout behind a pointer

From @RalfJung's comments it seems like the language level component of the PR was removed cause of the addition of unsafe, so removing T-Lang accordingly.

CAD97

comment created time in a day

pull request commentrust-lang/rust

Replace uses of Cell::get + Cell::set with Cell::replace.

r? @Centril @bors r+

anyska

comment created time in a day

pull request commentlibp2p/rust-libp2p

Onion3Addr::acquire: fix bug due to differing lifetimes

CI seems happy :)

Centril

comment created time in a day

pull request commentholochain/holochain-rust

holochain_metrics: use `StatsByMetric(...)` due to differing type params

CI seems happy :)

Centril

comment created time in a day

pull request commentrust-lang/rust

instantiate_value_path: on `SelfCtor`, avoid unconstrained tyvars

Crater triage:

  • There are 6 root regressions.
    • 1 was in my own crate and has already been fixed (with a point release).
    • All the others have PRs open fixing the problem.
Centril

comment created time in 2 days

push eventCentril/refl

Mazdak Farrokhzad

commit sha 5061f33d9194a1efd1df79045a28d4d7bd1ff0a2

prepare for 0.2.1

view details

push time in 2 days

push eventCentril/refl

Mazdak Farrokhzad

commit sha 754ac67fbce29dc609347bcb4be498e9ed0e60be

Use `Id(..)` instead of `Self(..)`

view details

push time in 2 days

PR opened zesterer/parze

Use `Fail(..)` instead of `Self(..)`

Due to a compiler bug fixed by rust-lang/rust#69340, this crate will stop compiler as discovered in https://crater-reports.s3.amazonaws.com/pr-69340/try%239ff4d07208097950831ed4ea9d76feb1eafc8baa/reg/parze-0.7.3/log.txt. This PR fixes the problem for you.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventCentril/parze

Mazdak Farrokhzad

commit sha d20f4ca0622e89dc7d4e226613378dc60c418311

Use `Fail(..)` instead of `Self(..)` (accepted previously due to compiler bug)

view details

push time in 2 days

fork Centril/parze

A clean, efficient parser combinator

https://docs.rs/parze

fork in 2 days

PR opened leod/pareen

Use `Anim(..)` instead of `Self(...)`

Due to a compiler bug fixed by https://github.com/rust-lang/rust/pull/69340, this crate will stop compiler as discovered in https://crater-reports.s3.amazonaws.com/pr-69340/try%239ff4d07208097950831ed4ea9d76feb1eafc8baa/reg/pareen-0.2.1/log.txt. This PR fixes the problem for you.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventCentril/pareen

Mazdak Farrokhzad

commit sha f3580805c94415080acf8cfbe63d3e95b9276996

Use `Anim(..)` instead of `Self(...)` (accepted previously due to compiler bug)

view details

push time in 2 days

fork Centril/pareen

Rust library for parameterized inbetweening

fork in 2 days

push eventCentril/vector-spaces-rs

Mazdak Farrokhzad

commit sha 374a36b60970e7b3d4790efa1d2ee8d30571138a

Update num_traits.rs

view details

push time in 2 days

PR opened finegeometer/vector-spaces-rs

impls::ops: use `Linear` instead of `Self`

Due to a compiler bug fixed in https://github.com/rust-lang/rust/pull/69340, the crate as-is will stop compiling as per https://crater-reports.s3.amazonaws.com/pr-69340/try%239ff4d07208097950831ed4ea9d76feb1eafc8baa/gh/finegeometer.vector-spaces-rs/log.txt. This PR fixes the issue.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventCentril/vector-spaces-rs

Mazdak Farrokhzad

commit sha d34374600ee2a61f917b50ea439dd483510f90dd

impls::ops: use `Linear` instead of `Self` (accepted due to compiler bug)

view details

push time in 2 days

fork Centril/vector-spaces-rs

nalgebra with more type safety: distinguish vector spaces of the same dimension

fork in 2 days

PR opened holochain/holochain-rust

holochain_metrics: use `StatsByMetric(...)` due to differing type params

This PR fixes a bug in stats.rs (the holochain_metrics crate) discovered in https://crater-reports.s3.amazonaws.com/pr-69340/try%239ff4d07208097950831ed4ea9d76feb1eafc8baa/reg/holochain_metrics-0.0.42-alpha5/log.txt. The problem here is that the type parameter D used in the Self type is not the same as the one returned by the function. This was accepted due to a bug in the compiler and is being fixed by https://github.com/rust-lang/rust/pull/69340.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventCentril/holochain-rust

Mazdak Farrokhzad

commit sha 7ade52cb945542c3cd61514a84ebca1b9a53622e

holochain_metrics: use `StatsByMetric(...)` due to differing type params

view details

push time in 2 days

fork Centril/holochain-rust

The core Holochain framework written in rust, a container API for running it (with rust and node implementations), and hdk-rust library for writing Zomes

fork in 2 days

PR opened libp2p/rust-libp2p

Onion3Addr::acquire: fix bug due to differing lifetimes

Because the Self type is Onion3Addr<'a> and the return type uses 'b, the usage of Self as a constructor is illegal as per https://crater-reports.s3.amazonaws.com/pr-69340/try%239ff4d07208097950831ed4ea9d76feb1eafc8baa/reg/libp2p-plaintext-0.15.0/log.txt and the bug fix in https://github.com/rust-lang/rust/pull/69340. This PR fixes that problem for you.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventCentril/rust-libp2p

Mazdak Farrokhzad

commit sha e291408df70f4edadee88c06f8f4b12da45c5916

Onion3Addr::acquire: fix bug due to differing lifetimes

view details

push time in 2 days

fork Centril/rust-libp2p

The Rust Implementation of libp2p networking stack.

https://libp2p.io

fork in 2 days

Pull request review commentrust-lang/rust

librustc_typeck: remove loop that never actually loops

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {                     break;                 }             }-            for binding in segment.generic_args().bindings {++            if let Some(binding) = segment.generic_args().bindings.get(0) {
            if let [binding, ..] = segment.generic_args().bindings {

Although cc @varkor re. whether this weird break was correct in the first place. I think this deserves a comment at any rate.

matthiaskrgr

comment created time in 2 days

Pull request review commentrust-lang/rust

syntax: Remove `Nt(Impl,Trait,Foreign)Item`

 pub enum Nonterminal {     NtPath(ast::Path),     NtVis(ast::Visibility),     NtTT(TokenTree),-    // Used only for passing items to proc macro attributes (they are not-    // strictly necessary for that, `Annotatable` can be converted into-    // tokens directly, but doing that naively regresses pretty-printing).

Should this comment be moved to NtItem?

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

syntax: Remove `Nt(Impl,Trait,Foreign)Item`

 impl<'a> Parser<'a> {     }      pub fn parse_impl_item(&mut self) -> PResult<'a, Option<Option<P<AssocItem>>>> {-        maybe_whole!(self, NtImplItem, |x| Some(Some(x)));         self.parse_assoc_item(|_| true)     }      pub fn parse_trait_item(&mut self) -> PResult<'a, Option<Option<P<AssocItem>>>> {-        maybe_whole!(self, NtTraitItem, |x| Some(Some(x)));         // This is somewhat dubious; We don't want to allow         // param names to be left off if there is a definition...

Btw... this is pre-existing, and unrelated, but should we drop this paragraph? I don't see how we could change it, so saying "it's dubious" doesn't seem helpful.

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

syntax: Remove `Nt(Impl,Trait,Foreign)Item`

 impl<'a, 'b> MacroExpander<'a, 'b> {                     let item_tok = TokenTree::token(                         token::Interpolated(Lrc::new(match item {                             Annotatable::Item(item) => token::NtItem(item),-                            Annotatable::TraitItem(item) => token::NtTraitItem(item),-                            Annotatable::ImplItem(item) => token::NtImplItem(item),-                            Annotatable::ForeignItem(item) => token::NtForeignItem(item),+                            Annotatable::TraitItem(item)+                            | Annotatable::ImplItem(item)+                            | Annotatable::ForeignItem(item) => {+                                token::NtItem(item.and_then(|item| {+                                    let ast::Item { attrs, id, span, vis, ident, kind, tokens } =+                                        item;+                                    let kind = match kind {+                                        AssocItemKind::Const(a, b, c) => ItemKind::Const(a, b, c),+                                        AssocItemKind::Static(a, b, c) => ItemKind::Static(a, b, c),+                                        AssocItemKind::Fn(a, b, c, d) => ItemKind::Fn(a, b, c, d),+                                        AssocItemKind::TyAlias(a, b, c, d) => {+                                            ItemKind::TyAlias(a, b, c, d)+                                        }+                                        AssocItemKind::Macro(a) => ItemKind::Mac(a),+                                    };

Perhaps move this to ast.rs as a method; I don't think anything else in rustc is interested in this by-move transformation (by-ref is a different story), but perhaps clippy or rustfmt would like a simple way to only deal in terms of ItemKinds.

petrochenkov

comment created time in 2 days

Pull request review commentrust-lang/rust

Remove use of `unwrap()` from save-analysis

+// compile-flags: -Zsave-analysis

My general sentiment is that we should not have files at all in src/test/ui, only directories. I have a question though... is the purpose of this test just for save-analysis? If not, then it doesn't seem fit for a save-analysis/ folder, which I would expect to be targeted specifically at testing save-analysis as opposed to some other aspect (and save analysis being incidentally also tested).

JohnTitor

comment created time in 2 days

delete branch Centril/rust

delete branch : unified-items

delete time in 2 days

push eventCentril/rust

Vadim Petrochenkov

commit sha bcd7e2b38b3eb26004bf94a63814341329233491

rustc_lint: Move `unused_doc_comments` from pre-expansion to early lints

view details

Vadim Petrochenkov

commit sha 1bd6b98220a7d161288f04a03111ca77b0a4845d

Emit some additional `unused_doc_comments` lints outside of the main pass

view details

Mark Rousskov

commit sha e7ee42baeb54f6484fa76a88e03b3168ff3147ce

Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.

view details

Mateusz Mikuła

commit sha b3b252b401ad133fac6d7ea2b452da921ff7f3b4

Fix MinGW detection for Cygwin

view details

Mateusz Mikuła

commit sha 4904b9c228317a9cba963afb87425754a586acf2

Detect Chocolatey MinGW installation

view details

Mazdak Farrokhzad

commit sha 9f3dfd29a21f1bdc26720703f79d3fabdc7471de

parse: allow `type Foo: Ord` syntactically.

view details

Jane Lusby

commit sha fa73b617c23a529b1ad966a9814961f1cbc78f6c

clean things up

view details

Jane Lusby

commit sha b44b4ca60257d80a431b4c1aceb3c1e09fb8389e

rustfmt you cruel mistress

view details

Maxim Zholobak

commit sha 20c9a40fec886826a3e7c4ec0c33ea4692f2c6a8

Rename CodeMap to SourceMap follow up

view details

Vadim Petrochenkov

commit sha 4356d18e4ab262a6703fa3a901c7cf00e9d27cc7

parser: Cleanup `Parser::bump_with` and its uses

view details

Jane Lusby

commit sha 494dd0b71936813e3a5565d5ea88c6fdf07240e3

Remove trait

view details

Jane Lusby

commit sha 40c67221e272c007cfae407d4398b166754491c9

make doc comments regular comments

view details

Jane Lusby

commit sha 09bc5e3d969a154ffcbeb6827a901d36a6a854eb

rustfmt darnit

view details

Dylan DPC

commit sha b76099429babcaf1aed86b7a2b7fb53291dd9ddb

Rollup merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying. cc rust-lang/infra -- does anyone *want* these notifications?

view details

Dylan DPC

commit sha cec00033a78d46df814728bcd831e71355a0efb0

Rollup merge of #69351 - mati865:mingw-ultimate-fix, r=cramertj Improve external MinGW detection Fixes #68872

view details

Dylan DPC

commit sha ae50725dc3e272a46726f548aaff801a4f456563

Rollup merge of #69361 - Centril:free-ty-alias, r=petrochenkov parse: allow `type Foo: Ord` syntactically This addresses: > (Work still remains to fuse this with free type aliases, but this can be done later.) in https://github.com/rust-lang/rust/pull/69194. r? @petrochenkov

view details

Dylan DPC

commit sha bdd275de2affa203d5ef4185d32b9b68109e38ca

Rollup merge of #69375 - Menschenkindlein:master, r=Dylan-DPC Rename CodeMap to SourceMap follow up See https://github.com/rust-lang/rust/issues/51574

view details

Dylan DPC

commit sha d6414f5f8c30593cd250fddf315e6f0098c3239a

Rollup merge of #69376 - petrochenkov:bumpwith, r=Centril parser: Cleanup `Parser::bump_with` and its uses Follow-up to https://github.com/rust-lang/rust/pull/69006. r? @Centril

view details

bors

commit sha 9c230f39c159cf7645bc4dbab511b9586d033021

Auto merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying. cc rust-lang/infra -- does anyone *want* these notifications?

view details

bors

commit sha 87b0d83745c0cc5b3679e406fbdbf0e8a8bfd3c6

Auto merge of #69351 - mati865:mingw-ultimate-fix, r=cramertj Improve external MinGW detection Fixes #68872

view details

push time in 2 days

pull request commentrust-lang/rust

parse: unify item parsing & filter illegal item kinds

@bors r=petrochenkov

Centril

comment created time in 2 days

push eventCentril/rust

Vadim Petrochenkov

commit sha bcd7e2b38b3eb26004bf94a63814341329233491

rustc_lint: Move `unused_doc_comments` from pre-expansion to early lints

view details

Vadim Petrochenkov

commit sha 1bd6b98220a7d161288f04a03111ca77b0a4845d

Emit some additional `unused_doc_comments` lints outside of the main pass

view details

Mark Rousskov

commit sha e7ee42baeb54f6484fa76a88e03b3168ff3147ce

Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.

view details

Mateusz Mikuła

commit sha b3b252b401ad133fac6d7ea2b452da921ff7f3b4

Fix MinGW detection for Cygwin

view details

Mateusz Mikuła

commit sha 4904b9c228317a9cba963afb87425754a586acf2

Detect Chocolatey MinGW installation

view details

Mazdak Farrokhzad

commit sha 9f3dfd29a21f1bdc26720703f79d3fabdc7471de

parse: allow `type Foo: Ord` syntactically.

view details

Jane Lusby

commit sha fa73b617c23a529b1ad966a9814961f1cbc78f6c

clean things up

view details

Jane Lusby

commit sha b44b4ca60257d80a431b4c1aceb3c1e09fb8389e

rustfmt you cruel mistress

view details

Maxim Zholobak

commit sha 20c9a40fec886826a3e7c4ec0c33ea4692f2c6a8

Rename CodeMap to SourceMap follow up

view details

Vadim Petrochenkov

commit sha 4356d18e4ab262a6703fa3a901c7cf00e9d27cc7

parser: Cleanup `Parser::bump_with` and its uses

view details

Jane Lusby

commit sha 494dd0b71936813e3a5565d5ea88c6fdf07240e3

Remove trait

view details

Jane Lusby

commit sha 40c67221e272c007cfae407d4398b166754491c9

make doc comments regular comments

view details

Jane Lusby

commit sha 09bc5e3d969a154ffcbeb6827a901d36a6a854eb

rustfmt darnit

view details

Dylan DPC

commit sha b76099429babcaf1aed86b7a2b7fb53291dd9ddb

Rollup merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying. cc rust-lang/infra -- does anyone *want* these notifications?

view details

Dylan DPC

commit sha cec00033a78d46df814728bcd831e71355a0efb0

Rollup merge of #69351 - mati865:mingw-ultimate-fix, r=cramertj Improve external MinGW detection Fixes #68872

view details

Dylan DPC

commit sha ae50725dc3e272a46726f548aaff801a4f456563

Rollup merge of #69361 - Centril:free-ty-alias, r=petrochenkov parse: allow `type Foo: Ord` syntactically This addresses: > (Work still remains to fuse this with free type aliases, but this can be done later.) in https://github.com/rust-lang/rust/pull/69194. r? @petrochenkov

view details

Dylan DPC

commit sha bdd275de2affa203d5ef4185d32b9b68109e38ca

Rollup merge of #69375 - Menschenkindlein:master, r=Dylan-DPC Rename CodeMap to SourceMap follow up See https://github.com/rust-lang/rust/issues/51574

view details

Dylan DPC

commit sha d6414f5f8c30593cd250fddf315e6f0098c3239a

Rollup merge of #69376 - petrochenkov:bumpwith, r=Centril parser: Cleanup `Parser::bump_with` and its uses Follow-up to https://github.com/rust-lang/rust/pull/69006. r? @Centril

view details

bors

commit sha 9c230f39c159cf7645bc4dbab511b9586d033021

Auto merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC Do not ping the infrastructure team on toolstate changes To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying. cc rust-lang/infra -- does anyone *want* these notifications?

view details

bors

commit sha 87b0d83745c0cc5b3679e406fbdbf0e8a8bfd3c6

Auto merge of #69351 - mati865:mingw-ultimate-fix, r=cramertj Improve external MinGW detection Fixes #68872

view details

push time in 2 days

create barnchCentril/rust

branch : soyuz

created branch time in 2 days

delete branch Centril/rust

delete branch : free-ty-alias

delete time in 2 days

issue commentrust-lang/rust

internal compiler error: missing type for `const` item

Hmm, bummer. It looks like they are getting the same span and so the stashed error is overwritten. We might need to insert a Vec<_> there to handle the possibility of span reuse from different things.

dwrensha

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: unify item parsing & filter illegal item kinds

+// check-pass++fn main() {}++macro_rules! mac_impl {+    ($i:item) => {+        struct S;+        impl S { $i }+    }+}++mac_impl! {+    fn foo() {}+}++macro_rules! mac_trait {+    ($i:item) => {+        trait T { $i }+    }+}++mac_trait! {+    fn foo() {}+}++macro_rules! mac_extern {+    ($i:item) => {+        extern "C" { $i }+    }+}++mac_extern! {+    fn foo();+}

Added another test. :)

Centril

comment created time in 3 days

push eventCentril/rust

Mazdak Farrokhzad

commit sha ae60173bae00c73032f765cf2b65ef2bba959be1

parse: tweak diagnostic wordings

view details

Mazdak Farrokhzad

commit sha d7f39d5613026024eade9fb4377c4b7be4a1d71b

parse: test bad variants wrt. issue 48137.

view details

push time in 3 days

Pull request review commentrust-lang/rust

parse: unify item parsing & filter illegal item kinds

 impl<'a> Parser<'a> {                     self.error_on_foreign_const(span, ident);                     ForeignItemKind::Static(a, Mutability::Not, b)                 }-                _ => {-                    let span = self.sess.source_map().def_span(span);-                    self.struct_span_err(span, "item kind not supported in `extern` block").emit();-                    return None;-                }+                _ => return self.error_bad_item_kind(span, &kind, "`extern` block"),             };             Some(P(Item { attrs, id, span, vis, ident, defaultness, kind, tokens }))         }))     } +    fn error_bad_item_kind<T>(&self, span: Span, kind: &ItemKind, ctx: &str) -> Option<T> {+        let span = self.sess.source_map().def_span(span);+        let msg = format!("{} not supported in {}", kind.descr(), ctx);

👍

Centril

comment created time in 3 days

Pull request review commentrust-lang/rust

parse: unify item parsing & filter illegal item kinds

+// check-pass++fn main() {}++macro_rules! mac_impl {+    ($i:item) => {+        struct S;+        impl S { $i }+    }+}++mac_impl! {+    fn foo() {}+}++macro_rules! mac_trait {+    ($i:item) => {+        trait T { $i }+    }+}++mac_trait! {+    fn foo() {}+}++macro_rules! mac_extern {+    ($i:item) => {+        extern "C" { $i }+    }+}++mac_extern! {+    fn foo();+}

By this you mean for example a struct S; inside one of the nested contexts?

Centril

comment created time in 3 days

pull request commentrust-lang/rust

parse: unify item parsing & filter illegal item kinds

Also, I threw in a small refactoring https://github.com/rust-lang/rust/pull/69366/commits/0564b71499b4f71d8d59fd16ca92a3656067001a which I had not pushed yet.

Centril

comment created time in 3 days

more