profile
viewpoint
Felix S Klock II pnkfelix Paris, France

pnkfelix/boxdraw-rs 2

Library for drawing ASCII art rectangles

Manishearth/rust 1

a safe, concurrent, practical language

pnkfelix/BinFiles 1

Little scripts that my ConfigFiles and DotFiles sometimes reference. Meant to be alias of ~/bin/

pnkfelix/ack 0

A replacement for grep for programmers

pnkfelix/ack2 0

ack 2.0

pnkfelix/add3 0

A demo project for illustrating dependency handling in Cargo

pnkfelix/add6 0

Toy crate that depends on past version of add3 crate.

pnkfelix/agents 0

Agent based simulation

pnkfelix/alexa-rs 0

Rust library for building Alexa skills

issue commentrust-lang/rust

nalgebra NoSolution Broken MIR ICE

@WildCryptoFox the discussion you linked talks about the problem going away between nightlies for 2019-11-15 and 2019-11-16. to my eye, that is not an example of this code having worked in the past, but rather makes it an example of an intermittent failure...

(I know at that point it may be in the eye of the beholder...)

Andlon

comment created time in 7 days

issue commentrust-lang/cargo-bisect-rustc

Flag to check for internal compiler errors

(the main reason I haven't put up a PR yet is due to the issue described by PR #45 )

fenhl

comment created time in 7 days

issue commentrust-lang/cargo-bisect-rustc

Flag to check for internal compiler errors

Hmm. I've been working on putting support into cargo-bisect-rustc itself for this and a few other testing variations.

I've been assuming that building the support into cargo-bisect-rustc would be best for the long term, but maybe that is an incorrect assumption.

fenhl

comment created time in 7 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 8 days

pull request commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

Okay I'm done with the review.

I had some nits, but they are mostly about clarifying the commit messages or the commit history, along with a few small stylistic issues; so the fixes should be easy.

r=me after fixes are made.

ecstatic-morse

comment created time in 8 days

Pull request review commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

 impl<'cx, 'tcx> dataflow::generic::ResultsVisitor<'cx, 'tcx> for MirBorrowckCtxt         let span = term.source_info.span;          match term.kind {-            TerminatorKind::Yield { value: _, resume: _, drop: _ } if self.movable_generator => {-                // Look for any active borrows to locals-                let borrow_set = self.borrow_set.clone();-                for i in flow_state.borrows.iter() {-                    let borrow = &borrow_set[i];-                    self.check_for_local_borrow(borrow, span);+            TerminatorKind::Yield { value: _, resume: _, ref resume_arg, drop: _ } => {

When I first looked at this commit, I wasn't sure from the commit message whether the "bitrot" here was superficial (i.e. if this was just cleaning up formatting) or if it was semantically significant.

Further reading led me to conclude that the code in its prior state .... probably didn't even build? Is that right?

If so, this commit should probably be merged backwards in the commit series, right?

ecstatic-morse

comment created time in 8 days

Pull request review commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

 impl<'tcx> MirPass<'tcx> for SanityCheck {         if has_rustc_mir_with(&attributes, sym::rustc_peek_definite_init).is_some() {             sanity_check_via_rustc_peek(tcx, body, def_id, &attributes, &flow_def_inits);         }+        // FIXME: Uncomment these as analyses are migrated to the new framework+        /*         if has_rustc_mir_with(&attributes, sym::rustc_peek_indirectly_mutable).is_some() {

so wait, not all of the rustc peek tests are completely ported over then, right?

ecstatic-morse

comment created time in 8 days

Pull request review commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

 // compile-flags: -Zunleash-the-miri-inside-of-you +// ignore-test Temporarily ignored while this analysis is migrated to the new framework.

wow look at that, an ignored test came back! How often does that happen around here?! :)

ecstatic-morse

comment created time in 8 days

Pull request review commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

 impl<'cx, 'tcx> DataflowResultsConsumer<'cx, 'tcx> for MirBorrowckCtxt<'cx, 'tcx                 // StorageDead, but we don't always emit those (notably on unwind paths),                 // so this "extra check" serves as a kind of backup.                 let borrow_set = self.borrow_set.clone();-                flow_state.with_outgoing_borrows(|borrows| {-                    for i in borrows {-                        let borrow = &borrow_set[i];-                        self.check_for_invalidation_at_exit(loc, borrow, span);-                    }-                });-            }-            TerminatorKind::Goto { target: _ }-            | TerminatorKind::Abort-            | TerminatorKind::Unreachable-            | TerminatorKind::FalseEdges { real_target: _, imaginary_target: _ }-            | TerminatorKind::FalseUnwind { real_target: _, unwind: _ } => {-                // no data used, thus irrelevant to borrowck+                for i in flow_state.borrows.iter() {+                    let borrow = &borrow_set[i];+                    self.check_for_invalidation_at_exit(loc, borrow, span);+                }             }++            _ => {}

I personally would prefer leaving the explicit enumeration of cases, rather than relying on a catch-all.

ecstatic-morse

comment created time in 8 days

Pull request review commentrust-lang/rust

Migrate borrowck dataflow impls to new framework

 pub trait Analysis<'tcx>: AnalysisDomain<'tcx> {         args: &[mir::Operand<'tcx>],         return_place: &mir::Place<'tcx>,     );++    /// Creates an `Engine` to find the fixpoint for this dataflow problem.+    ///+    /// This is functionally equivalent to calling the appropriate `Engine` constructor. It should+    /// not be overridden. Its purpose is to allow consumers of this API to use method-chaining.

nit: it is a little weird to make the statement "it should not be overridden", and in the same commit, include an overriding (i.e. non-default) implementation.

I do understand what's going on, i just couldn't help but point it out. (I'd probably be satisfied if it said "it should not be overridden apart from specialized instances such as in GenKillAnalysis.")

ecstatic-morse

comment created time in 8 days

push eventpnkfelix/rust

Erin Power

commit sha 49d78fcd901700c5a14e19a6679db1646b5ca901

Add GitHub issue templates

view details

Tomasz Miąsko

commit sha 7e3c51d085d9eaa2204cc18763bc7d98b66435fd

Instrument C / C++ in MemorySanitizer example Modify the example to instrument C / C++ in addition to Rust, since it will be generally required (e.g., when using libbacktrace for symbolication). Additionally use rustc specific flag to track the origins of unitialized memory rather than LLVM one.

view details

Andreas Molzer

commit sha 47ae565ed4f1b2a7cc754d4cf0af520b5e6841b9

Add a method to query the capacity of a BufWriter

view details

Andreas Molzer

commit sha aebd0d733940d62566c66a923c7b9f7078209e98

Add capacity to BufReader with same unstable gate

view details

John Kåre Alsaker

commit sha bfba6ef328bbba327cae8918e795c11b89217672

Add an option to use LLD to link the compiler on Windows platforms

view details

John Kåre Alsaker

commit sha 95318f8d859dc55cc5e06722c96f6e492529d6ca

Link a linking issue

view details

John Kåre Alsaker

commit sha 2124a85260fdf0851bb4de369d311bcfc05b205f

Don't use a whitelist for use_lld

view details

Trevor Spiteri

commit sha aa046da61f8722dfe46204cb303dbc9d2b4cb32e

rustdoc: attempt full build for compile_fail test Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.

view details

Trevor Spiteri

commit sha 6d768ddecc13c4acf45730952c0af401a990383a

error code examples: replace some ignore with compile_fail

view details

Mark Rousskov

commit sha 39e502744c7db993eb0269285082ac5c7b7d4bdd

Install robots.txt into rust-docs tarballs

view details

Mark Rousskov

commit sha b613b0cb3641a7a5be74471e8e5963e52adf30ea

Correctly reinstall rustfmt on channel change

view details

Mark Rousskov

commit sha ff95473b5e8fe4a25f59778e6a071abc026e6447

Bump rustfmt and stage0

view details

Mark Rousskov

commit sha 31dcdc9e13c324d33a18db3aed7f4b3208ff3744

Drop cfg(bootstrap) code

view details

hman523

commit sha 346920c3c844e650aff6428c6b5c6e70cbce9954

Fixed issue 68593

view details

Matthew Jasper

commit sha a81c59f9b84b6519785a4e0ae9234107d149f454

Remove some unsound specializations

view details

kennytm

commit sha 847d5b4d1387a30f1798a5c3c59c3e0c31e00319

Derive Clone + PartialEq + Eq for std::string::FromUtf8Error

view details

Trevor Spiteri

commit sha fd2282388140ea0f370ee25c82f00be81c2f822c

implement AsMut<str> for String

view details

Yuki Okushi

commit sha 9d8058fb423ff21a6c05945ef83f0d5eb4b33fb8

Do not ICE in `type-alias-impl-trait` with save-analysis

view details

Matthew Jasper

commit sha 425e494fceb2f88bec344ef07d0f2db4c74dd2d1

Remove or_patterns from INCOMPLETE_FEATURES

view details

Matthew Jasper

commit sha eecee76652dafe25f2cd6453f33bf4c298e84463

Generate prebinding blocks lazily

view details

push time in 8 days

PR closed rust-lang/rust

[WIP] Commenting out unsound specialization. S-waiting-on-author

If perf results indicate that we need this, then we should try to emulate it via a series of implementations on concrete types.

cc #67194

+9 -6

17 comments

1 changed file

pnkfelix

pr closed time in 8 days

pull request commentrust-lang/rust

[WIP] Commenting out unsound specialization.

We do not need this anymore; PR #68835 resolved the unsoundness in question (by changing the representation of RangeInclusive so that we do not need to use the unsound specialization).

pnkfelix

comment created time in 8 days

issue commentrust-lang/rust

nalgebra NoSolution Broken MIR ICE

BTW I made extensive use of C-reduce and rust-reduce to get here, which I notice @pnkfelix didn't mention in his blog ;)

shots fired!

(I admit I didn't mention them there, in part because I have little experience using them. I should try using them, and maybe try adding my techniques to rust-reduce.)

Andlon

comment created time in 11 days

issue commentrust-lang/rust

nalgebra NoSolution Broken MIR ICE

Did this ever work, by the way? This is tagged "needs-bisect", but that won't help if this isn't a regression... (or maybe the bisection is just to identify whether or not this is a regression?)

Andlon

comment created time in 11 days

pull request commentrust-lang/rfcs

Cargo report future-incompat

@rfcbot fcp merge

pnkfelix

comment created time in 11 days

push eventpnkfelix/rfcs

Felix S Klock II

commit sha 1f5a1ebf3dc060e7233c40502d9832c18d7c6bb3

Update 0000-cargo-report-future-incompat.md

view details

push time in 11 days

push eventpnkfelix/rfcs

Felix S. Klock II

commit sha 2241fa7910f6a9341a014707adcdeea8f38b2b19

Address review concern, clarifying interaction with `-Dwarnings`.

view details

push time in 12 days

Pull request review commentrust-lang/rfcs

Cargo report future-incompat

+- Feature Name: N/A+- Start Date: 2019-12-10+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: N/A++# Summary+[summary]: #summary++Cargo should alert developers to upstream dependencies that trigger+future-incompatibility warnings. Cargo should list such dependencies+even when these warnings have been suppressed (e.g. via cap-lints or+`#[allow(..)]` attributes.)++Cargo could additionally provide feedback for tactics a maintainer of+the downstream crate could use to address the problem (the details of+such tactics is not specified nor mandated by this RFC).++# Motivation+[motivation]: #motivation++From [rust-lang/rust#34596][]:++> if you author a library that is widely used, but which you are not+> actively using at the moment, you might not notice that it will+> break in the future -- moreover, your users won't either, since+> cargo will cap lints when it builds your library as a dependency.++[rust-lang/rust#34596]: https://github.com/rust-lang/rust/issues/34596++Today, cargo will cap lints when it builds libraries as dependencies.+This behavior includes future-incompatibility lints.++As a running example, assume we have a crate `unwary` with an upstream+crate dependency `brash`, and `brash` has code that triggers a+future-incompatibility lint, in this case a borrow `&x.data.0` of a packed field+(see [rust-lang/rust#46043][], "safe packed borrows").++[rust-lang/rust#46043]: https://github.com/rust-lang/rust/issues/46043++If `brash` is a non-path dependency of `unwary`, then building+`unwary` will suppress the warning associated with `brash` in its+diagnostic output, because the build of `brash` will pass+`--cap-lints=allow` to its `rustc` invocation. This means that a+future version of Rust is going to fail to compile the `unwary`+project, with no warning to the developer of `unwary`.++Example of today's behavior (where in this case, `brash` is non-path dependency of `unwary`):++```+crates % cd unwary+unwary % cargo build                                                # no warning issued about problem in the `brash` dependency.+   Compiling brash v0.1.0+   Compiling unwary v0.1.0 (/tmp/unwary)+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s+unwary % cd ../brash+brash % cargo build                                                 # (but a `brash` developer will see it when they build.)+   Compiling brash v0.1.0 (/tmp/brash)+warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133)+  --> src/lib.rs:13:9+   |+13 | let y = &x.data.0;+   |         ^^^^^^^^^+   |+   = note: `#[warn(safe_packed_borrows)]` on by default+   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!+   = note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>+   = note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s+brash %+```++Cargo passes `--cap-lints=allow` on upstream dependencies for good+reason, as discussed in [Rust RFC 1193][] and the comment thread from+[rust-lang/rust#59658][].+For cases like future-incompatibility lints, which+are more severe warnings for the long-term viability of a crate, we+need to provide some feedback to the `unwary` maintainer. ++But this feedback should not be *just* the raw diagnostic output for+`brash`! The developer of a crate like `unwary` typically cannot do+anything in the short term about warnings emitted by upstream crates,++ * (The `unwary` developer *can* file issues against `brash` or even+    contribute code to fix `brash`, but that does not resolve the+    immediate problem until new version of `brash` is released by its+    maintainer.)++Therefore the diagnostics associated with building upstream+`brash` are usually just noise from the viewpoint of `unwary`'s+maintainer.++[Rust RFC 1193]: https://github.com/rust-lang/rfcs/blob/master/text/1193-cap-lints.md++[rust-lang/rfcs#1193]: https://github.com/rust-lang/rfcs/pull/1193++[rust-lang/rust#59658]: https://github.com/rust-lang/rust/issues/59658++[rust-lang/rust#27260]: https://github.com/rust-lang/rust/pull/27260++[rust-lang/cargo#1830]: https://github.com/rust-lang/cargo/pull/1830++Therefore, we want to continue passing `--cap-lints=allow` for+upstream dependencies. But we also want `rustc` to tell `cargo` (via+some channel) about when future-incompatibility lints are triggered,+and we want `cargo` to provide a succinct report of the triggers.++This RFC suggests the provided feedback take the form of a summary at+the end of cargo's build of `unwary`, as illustrated in the explanation below.++Furthermore, we want the feedback to provide guidance as to how the+`unwary` maintainer can address the issue. Here are some potential+forms this additional guidance could take.++ * cargo could respond to the future-incompatibilty signaling by querying+   the local index to find out if a newer version of the upstream crate is+   available. If a newer version is available, then it could +   suggest to the user they might upgrade to it.+   If such an upgrade could be done via `cargo update`, then the+   output could obviously suggest that as well.++   (This is just a heuristic measure, as it would not attempt to+   check ahead of time if the newer version actually resolves the+   problem in question.)++   A further refinement on this idea would be to query+   `crates.io` itself If cargo is not running in "offline mode". But+   querying the index may well suffice in practice.++ * Cargo could suggest to the `unwary` maintainer that they file a bug+   (or search for previously-filed bugs) in the source repository for+   the upstream crate that is issuing the future-incompatibility+   warning. (That is, the `brash` author might not be aware of the+   issue; for example, if they last updated their crate before the+   lint in question was deployed on the Rust compiler.)++ * `rustc` itself could embed, for each future-incompatibility lint,+   how soon the Rust developers will turn the lint to a hard error.+   This would give the `unwary` maintainer an idea of how much time+   they have before they will be forced to address the issue (by+   posting a PR upstream, or switching to a fork of `brash`, et+   cetera).+++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++After cargo finishes compiling a crate and its upstream dependencies,+it may include a final warning about *future incompatibilties*.++A future incompatibility is a pattern of code that is scheduled to be+removed from the Rust language in some future release. Such code patterns+are usually instances of constructs that can exhibit undefined behavior+(i.e. they are unsound) or do not have a well-defined semantics,+but are nonetheless in widespread use and thus need a+grace period before they are removed.++If any crate or any of its upstream dependencies has code that+triggers a future incompatibility warning, but the overall compilation+is otherwise without error, then cargo will report all instances of+crates with future incompatibilities at the end of the compilation.+When possible, this report includes the future date or release version+where we expect Rust to stop compiling the code in question.++Example:++```+crates % cd unwary+unwary % cargo build+   Compiling brash v0.1.0+   Compiling bold v0.1.0+   Compiling rash v0.1.0+   Compiling unwary v0.1.0+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s++    warning: the crates brash, bold, and rash contain code that will be rejected by a future version of Rust.+    note: the crate rash will stop compiling in Rust 1.50 (scheduled for February 2021).+    note: to see what the problems were, invoke `cargo describe-future-incompatibilities`+unwary %+```++If the dependency graph for the current crate contains multiple versions of+a crate listed by the end report, then the end report should include which+version (or versions) of that crate are causing the lint to fire.++Invoking the command `cargo describe-future-incompatibilities` will make cargo+query information cached from the previous build and print out a more informative+diagnostic message:++```+unary % cargo describe-future-incompatibilities+The `brash` crate currently triggers a future incompatibility warning with Rust,+with the following diagnostic:++> warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133)+>   --> src/lib.rs:12:9+>    |+> 12 | let y = &x.data.0; // UB, also future-compatibility warning+>    |         ^^^^^^^^^+>    |+>    = note: `#[warn(safe_packed_borrows)]` on by default+>    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!+>    = note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>+>    = note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior+++The `bold` crate currently triggers a future incompatibility warning with Rust,+with the following diagnostic:++> warning: private type `foo::m::S` in public interface (error E0446)+>  --> src/lib.rs:5:5+>   |+> 5 |     pub fn f() -> S { S }+>   |     ^^^^^^^^^^^^^^^^^^^^^+>   |+>   = note: `#[warn(private_in_public)]` on by default+>   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!+>   = note: for more information, see issue #34537 <https://github.com/rust-lang/rust/issues/34537>+++The `rash` crate currently triggers a future incompatibility warning with Rust,+with the following diagnostic:++> error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions.+>  --> src/lib.rs:4:8+>   |+> 4 | fn bar<T=i32>(x: T) { }+>   |        ^+>   |+>   = note: `#[deny(invalid_type_param_default)]` on by default+>   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!+>   = note: for more information, see issue #36887 <https://github.com/rust-lang/rust/issues/36887>+```++This way, developers who want to understand the problem have a way to find out more,+without flooding everyone's diagnostics with information they cannot use with their+own local development.+++Rebuilding `unwary` continues to emit the report even if the upstream+dependencies are not rebuilt.++Example:++```+unwary % touch src/main.rs+unwary % cargo build+   Compiling unwary v0.1.0+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s++    warning: the crates brash, bold, and rash contain code that will be rejected by a future version of Rust.+    note: the crate rash will stop compiling in Rust 1.50 (scheduled for February 2021).+unwary %+    note: to see what the problems were, invoke `cargo describe-future-incompatibilities`+```++To keep the user experience consistent, we should probably emit the same warning at the end+even when the root crate is the sole trigger of incompatibility lints.++```+crates % cd brash+brash % cargo build+   Compiling brash v0.1.0 (/tmp/brash)+warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133)+  --> src/lib.rs:13:9+   |+13 | let y = &x.data.0;+   |         ^^^^^^^^^+   |+   = note: `#[warn(safe_packed_borrows)]` on by default+   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!+   = note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>+   = note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s++    warning: the crate brash contains code that will be rejected by a future version of Rust.+brash % cargo build+    Finished dev [unoptimized + debuginfo] target(s) in 0.00s++    warning: the crate brash contains code that will be rejected by a future version of Rust.+    note: to see what the problems were, invoke `cargo describe-future-incompatibilities`+brash %+```++And as you might expect, if there are no future-incompatibilty warnings issused, then the output of `cargo` is unchanged from today.+Example:++```+crates % cd unwary+unwary % cargo build+   Compiling brash v0.2.0+   Compiling bold2 v0.1.0+   Compiling unwary v0.2.0+    Finished dev [unoptimized + debuginfo] target(s) in 0.30s+unwary %+```++Here, the unwary (sic) crate has updated its version of `brash`,+switched to `bold2` (a fork of `bold`), and replaced its internal+usage of `rash` with some local code, thus completely eliminating all+current future-incompatibility lint triggers.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++As noted above, we want to continue to suppress normal lint checks for+upstream dependencies. Therefore, Cargo will continue to pass+`--cap-lints=allow` for non-path upstream dependencies.++At the same time, we want to minimize disruption to existing users of Rust.+Therefore, the behavior of flags that directly interact with lints, like+`-Dwarnings`, will remain unchanged by this RFC.++For example, in our running example of `unwary`:+  * running `cargo rustc -- -Dwarnings` will behave the same as today+    (the lints in the downstream `brash` dependency will be capped+    and their warnings hidden), and+  * running `RUSTFLAGS=-Dwarnings` will also behave the same as today+    (the `rustc` invocation on the downstream `brash` depedency+    will be invoked with `-Dwarnings` and thus the build of the `brash`+    dependency will fail).++However, the Rust compiler's behavior will change slightly. Even when+`--cap-lints=allow` is turned on, we need Cargo to know when a+future-incompatibilty lint is triggered.++The division of responsbiilties between Cargo and the Rust compiler+may be a little subtle:++The responsibilities of the Rust compiler (`rustc`):++  * `rustc` must differentiate future-incompatibility lints (c.f.+     [PR #59658: "Minimum Lint Levels"][rust-lang/rust#59658]) from+     other lints that are expected to remain as mere warnings forever.++  * `rustc` will need to have some new mode of operation, which this+    RFC will call the where it will check for instances of+    future-incompatibility lints, *regardless* of whether+    `--cap-lints=allow` is also set. This RFC calls this the+    *future-incompatibility checking mode*.++    * In the future-incompatibility checking mode of invocation,+      `rustc` will also need to check for such lints *regardless* of+      whether the code appears in the scope of an `#[allow(..)]`+      attribute for the lint.++    * In the future-incompatibility checking mode of invocation,+      *emission* of the diagnostics themselves may still be silenced+      as specified by `--cap-lints=allow` or `#[allow(..)]` attributes.++    * That is, those flags and annotations should be interpreted by+      `rustc` as silencing the diagnostic report, but *not* as+      silencing the feedback about there existing some instance of the+      lint triggering somewhere in the crate's source code.

My intent is that the future-incompatibility report issued by cargo is itself not a warning. It is a report.

More specifically: my intent is that the observable behavior of -Dwarnings remain exactly the same with this RFC as it is without.

Does that address your concern?

pnkfelix

comment created time in 12 days

Pull request review commentrust-lang/rfcs

Cargo report future-incompat

 As noted above, we want to continue to suppress normal lint checks for upstream dependencies. Therefore, Cargo will continue to pass `--cap-lints=allow` for non-path upstream dependencies. +At the same time, we want to minimize disruption to existing users of Rust.+Therefore, the behavior of flags that directly interact with lints, like+`-Dwarnings`, will remain unchanged by this RFC.++For example, in our running example of `unwary`:+  * running `cargo rustc -- -Dwarnings` will behave the same as today+    (the lints in the downstream `brash` dependency will be capped+    and their warnings hidden), and+  * running `RUSTFLAGS=-Dwarnings` will also behave the same as today+    (the `rustc` invocation on the downstream `brash` depedency+    will be invoked with `-Dwarnings` and thus the build of the `brash`+    dependency will fail).

Ugh, sorry: I was testing via a local workspace with both crates as local paths, and I think that (once again) burned me.

cargo's behavior is pretty frustrating in this scenario where all I'm trying to do is directly explore the current semantics.

Is there a way to force it to treat a local path dependency the same way that it would treat a remote dependency?

(But also: I am a little surprised that passing -Dwarnings to rustc via the RUSTFLAGS env var does not override the passing of --cap-lints... but what do I know...)

pnkfelix

comment created time in 12 days

push eventpnkfelix/rfcs

Felix S. Klock II

commit sha 93532afd95f54babeac8775e5dac3c80c0d638e2

Tried to add text addressing alex's concern about our policy for when these get turned on.

view details

push time in 12 days

push eventpnkfelix/rfcs

Felix S. Klock II

commit sha 4a737c4e815a88752948a2752869368879403723

add explicit note that this change does not effect existing `-Dwarnings` usage.

view details

push time in 12 days

issue commentrust-lang/rust

1.40.0 ICE while reporting ICE

I looked at this a bit more.

I see the ICE on stable and beta.

I do not see the ICE on nightly.

On nightly, I instead get the following error:

<details> <summary>Click here to see error diagnostics</summary>

% cargo +nightly build
warning: unnecessary parentheses around block return value
   --> /private/tmp/rust-lightning/lightning/src/chain/keysinterface.rs:449:3
    |
449 |         (Sha256::from_engine(sha).into_inner())
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
    |
    = note: `#[warn(unused_parens)]` on by default

warning: use of deprecated item 'std::error::Error::description': use the Display impl or to_string()
   --> /private/tmp/rust-lightning/lightning/src/ln/msgs.rs:741:32
    |
741 |             DecodeError::Io(ref e) => e.description(),
    |                                         ^^^^^^^^^^^
    |
    = note: `#[warn(deprecated)]` on by default

warning: use of deprecated item 'std::error::Error::description': use the Display impl or to_string()
   --> /private/tmp/rust-lightning/lightning/src/ln/msgs.rs:747:20
    |
747 |         f.write_str(self.description())
    |                          ^^^^^^^^^^^

warning: field is never read: `logger`
   --> /private/tmp/rust-lightning/lightning/src/chain/chaininterface.rs:303:2
    |
303 |     logger: Arc<Logger>,
    |     ^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` on by default

warning: field is never read: `logger`
   --> /private/tmp/rust-lightning/lightning/src/chain/keysinterface.rs:295:2
    |
295 |     logger: Arc<Logger>,
    |     ^^^^^^^^^^^^^^^^^^^

warning: variant is never constructed: `Watchtower`
   --> /private/tmp/rust-lightning/lightning/src/ln/channelmonitor.rs:351:2
    |
351 |       Watchtower {
    |  _____^
352 | |         revocation_base_key: PublicKey,
353 | |         htlc_base_key: PublicKey,
354 | |     }
    | |_____^

warning: unused import: `lightning::ln::peer_handler::SocketDescriptor as LnSocketTrait`
 --> /private/tmp/rust-lightning/lightning-net-tokio/src/lib.rs:9:5
  |
9 | use lightning::ln::peer_handler::SocketDescriptor as LnSocketTrait;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused `std::result::Result` that must be used
   --> /private/tmp/rust-lightning/lightning-net-tokio/src/lib.rs:174:4
    |
174 |             tokio::spawn(Self::schedule_read(peer_manager, us, reader, receiver)).await;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_must_use)]` on by default
    = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
   --> /private/tmp/rust-lightning/lightning-net-tokio/src/lib.rs:195:4
    |
195 |             tokio::spawn(Self::schedule_read(peer_manager, us, reader, receiver)).await;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: this `Result` may be an `Err` variant, which should be handled

   Compiling rust-lightning-bitcoinrpc v0.0.1 (/private/tmp/rust-lightning-bitcoinrpc)
error[E0277]: `std::sync::MutexGuard<'_, lightning_net_tokio::Connection>` cannot be sent between threads safely
   --> src/main.rs:521:30
    |
521 |                                             join_handles.push(tokio::spawn(async move {
    |                                                               ^^^^^^^^^^^^ `std::sync::MutexGuard<'_, lightning_net_tokio::Connection>` cannot be sent between threads safely
    | 
   ::: /Users/felixklock/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.11/src/task/spawn.rs:123:21
    |
123 |         T: Future + Send + 'static,
    |                     ---- required by this bound in `tokio::task::spawn::spawn`
    |
    = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `std::sync::MutexGuard<'_, lightning_net_tokio::Connection>`
    = note: required because it appears within the type `for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6, 't7, 't8, 't9> {std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, tokio::net::tcp::stream::TcpStream, tokio::io::split::ReadHalf<tokio::net::tcp::stream::TcpStream>, tokio::sync::mpsc::bounded::Receiver<()>, std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, &'r lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>, &'s std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, lightning_net_tokio::SocketDescriptor, std::result::Result<std::vec::Vec<u8>, lightning::ln::peer_handler::PeerHandleError>, std::vec::Vec<u8>, &'t0 std::sync::Mutex<lightning_net_tokio::Connection>, std::result::Result<std::sync::MutexGuard<'t1, lightning_net_tokio::Connection>, std::sync::PoisonError<std::sync::MutexGuard<'t2, lightning_net_tokio::Connection>>>, lightning_net_tokio::Connection, std::sync::MutexGuard<'t3, lightning_net_tokio::Connection>, &'t4 mut std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<&'t5 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, &'t6 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>, &'t7 [u8], &'t8 std::vec::Vec<u8>, tokio::io::util::write_all::WriteAll<'t9, tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, (), impl std::future::Future, tokio::task::join::JoinHandle<()>}`
    = note: required because it appears within the type `[static generator@DefId(75:54 ~ lightning_net_tokio[f695]::{{impl}}[0]::setup_outbound[0]::{{closure}}[0]) 0:std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, 1:tokio::sync::mpsc::bounded::Sender<()>, 2:secp256k1::key::PublicKey, 3:tokio::net::tcp::stream::TcpStream for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6, 't7, 't8, 't9> {std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, tokio::net::tcp::stream::TcpStream, tokio::io::split::ReadHalf<tokio::net::tcp::stream::TcpStream>, tokio::sync::mpsc::bounded::Receiver<()>, std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, &'r lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>, &'s std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, lightning_net_tokio::SocketDescriptor, std::result::Result<std::vec::Vec<u8>, lightning::ln::peer_handler::PeerHandleError>, std::vec::Vec<u8>, &'t0 std::sync::Mutex<lightning_net_tokio::Connection>, std::result::Result<std::sync::MutexGuard<'t1, lightning_net_tokio::Connection>, std::sync::PoisonError<std::sync::MutexGuard<'t2, lightning_net_tokio::Connection>>>, lightning_net_tokio::Connection, std::sync::MutexGuard<'t3, lightning_net_tokio::Connection>, &'t4 mut std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<&'t5 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, &'t6 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>, &'t7 [u8], &'t8 std::vec::Vec<u8>, tokio::io::util::write_all::WriteAll<'t9, tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, (), impl std::future::Future, tokio::task::join::JoinHandle<()>}]`
    = note: required because it appears within the type `std::future::GenFuture<[static generator@DefId(75:54 ~ lightning_net_tokio[f695]::{{impl}}[0]::setup_outbound[0]::{{closure}}[0]) 0:std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, 1:tokio::sync::mpsc::bounded::Sender<()>, 2:secp256k1::key::PublicKey, 3:tokio::net::tcp::stream::TcpStream for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6, 't7, 't8, 't9> {std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, tokio::net::tcp::stream::TcpStream, tokio::io::split::ReadHalf<tokio::net::tcp::stream::TcpStream>, tokio::sync::mpsc::bounded::Receiver<()>, std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, &'r lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>, &'s std::sync::Arc<std::sync::Mutex<lightning_net_tokio::Connection>>, lightning_net_tokio::SocketDescriptor, std::result::Result<std::vec::Vec<u8>, lightning::ln::peer_handler::PeerHandleError>, std::vec::Vec<u8>, &'t0 std::sync::Mutex<lightning_net_tokio::Connection>, std::result::Result<std::sync::MutexGuard<'t1, lightning_net_tokio::Connection>, std::sync::PoisonError<std::sync::MutexGuard<'t2, lightning_net_tokio::Connection>>>, lightning_net_tokio::Connection, std::sync::MutexGuard<'t3, lightning_net_tokio::Connection>, &'t4 mut std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, std::option::Option<&'t5 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, &'t6 mut tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>, &'t7 [u8], &'t8 std::vec::Vec<u8>, tokio::io::util::write_all::WriteAll<'t9, tokio::io::split::WriteHalf<tokio::net::tcp::stream::TcpStream>>, (), impl std::future::Future, tokio::task::join::JoinHandle<()>}]>`
    = note: required because it appears within the type `impl std::future::Future`
    = note: required because it appears within the type `impl std::future::Future`
    = note: required because it appears within the type `{std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, std::net::TcpStream, std::result::Result<tokio::net::tcp::stream::TcpStream, std::io::Error>, tokio::net::tcp::stream::TcpStream, impl std::future::Future, ()}`
    = note: required because it appears within the type `[static generator@src/main.rs:521:54: 524:13 peer_manager:std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, event_notify:tokio::sync::mpsc::bounded::Sender<()>, pk:secp256k1::key::PublicKey, stream:std::net::TcpStream {std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, std::net::TcpStream, std::result::Result<tokio::net::tcp::stream::TcpStream, std::io::Error>, tokio::net::tcp::stream::TcpStream, impl std::future::Future, ()}]`
    = note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:521:54: 524:13 peer_manager:std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, event_notify:tokio::sync::mpsc::bounded::Sender<()>, pk:secp256k1::key::PublicKey, stream:std::net::TcpStream {std::sync::Arc<lightning::ln::peer_handler::PeerManager<lightning_net_tokio::SocketDescriptor, std::sync::Arc<lightning::ln::channelmanager::ChannelManager<lightning::chain::keysinterface::InMemoryChannelKeys, std::sync::Arc<ChannelMonitor>>>>>, tokio::sync::mpsc::bounded::Sender<()>, secp256k1::key::PublicKey, std::net::TcpStream, std::result::Result<tokio::net::tcp::stream::TcpStream, std::io::Error>, tokio::net::tcp::stream::TcpStream, impl std::future::Future, ()}]>`
    = note: required because it appears within the type `impl std::future::Future`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `rust-lightning-bitcoinrpc`.

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

</details>

TheBlueMatt

comment created time in 12 days

issue commentrust-lang/rust

1.40.0 ICE while reporting ICE

Note that when I had a go at building rust-lightning-bitcoinrpc on my Mac laptop, it failed with this message:

error: cannot find attribute `error` in this scope
   --> src/main.rs:253:3
    |
253 | #[error("OSX creatively eats your data, using Lightning on OSX is unsafe")]
    |   ^^^^^

error: aborting due to previous error

error: could not compile `rust-lightning-bitcoinrpc`.

This is due to this line in the source crate:

(due to [this line](https://github.com/TheBlueMatt/rust-lightning-bitcoinrpc/blob/3243d5efc6198e373006ebac3e8843da7ebd0292/src/main.rs#L254

So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)

TheBlueMatt

comment created time in 12 days

fork pnkfelix/rust-lightning-bitcoinrpc

Sample rust-lightning client using Bitcoin Core's RPC/REST Interface

fork in 12 days

PR opened rust-lang/rustc-guide

Added example of icebreakers-cleanup-crew

(I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.)

+1 -0

0 comment

1 changed file

pr created time in 12 days

issue commentrust-lang/rust

1.40.0 ICE while reporting ICE

@rustbot ping icebreakers-cleanup-crew

TheBlueMatt

comment created time in 12 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 12 days

push eventpnkfelix/rust

Jethro Beekman

commit sha ea11b244d9793c9c7a2bcf61e95ea0f7e9aed6ec

Fix SGX RWLock representation for UnsafeCell niche fix

view details

push time in 12 days

Pull request review commentrust-lang/rust

Hide niches under UnsafeCell

 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ # We pass the commit id of the port of LLVM's libunwind to the build script. # Any update to the commit id here, should cause the container image to be re-built from this point on.-RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "53b586346f2c7870e20b170decdc30729d97c42b"+RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "63b1b1c5b1ca008099095aa0f8a081a80c8d27f4"

This whole thing strikes me as quite fragile ...

pnkfelix

comment created time in 12 days

push eventrust-lang/measureme

Felix S Klock II

commit sha ba0b079ec67be4fae9e38883334c777da8fd2694

Update Readme.md

view details

push time in 13 days

push eventrust-lang/measureme

Felix S Klock II

commit sha 875ce34ff39e5d710348b853bb370ad8de40e8ca

Update Readme.md

view details

push time in 13 days

pull request commentrust-lang/rust

Resolve long compile times when evaluating always valid constants

discussed at T-compiler meeting. stable-accepted.

wesleywiser

comment created time in 13 days

issue commentrust-lang/rust

[spurious] thread 'rustc' panicked at 'slice index starts at 24722962 but ends at 13279232', src/libcore/slice/mod.rs:2680:5

discussed at T-compiler triage meeting. Prioritizing as P-low, with intent to close in near term as non-actionable

bjorn3

comment created time in 13 days

pull request commentrust-lang/rust

Do not ICE on multipart suggestions touching multiple files

discussed at T-compiler triage meeting. approved for beta backport.

estebank

comment created time in 13 days

pull request commentrust-lang/rust

Correct ICE caused by macros generating invalid spans.

(we discussed backporting this in today's T-compiler meeting. We are not certain what warn! will do here, in terms of what an end-user will see, so we held off on approving this change until after we've double-checked the default UX there...)

MichaelBurge

comment created time in 13 days

fork pnkfelix/cargo-bisect-rustc

Bisects rustc, either nightlies or CI artifacts

fork in 13 days

issue commentrust-lang/rust

cargo check --message-format json regression of error span data on empty main.rs file

triage: P-high. Assigning to self.

Veetaha

comment created time in 13 days

issue commentrust-lang/rust

Worsened debug build codegen in beta

triage: leaving unprioritized. Nominating for discussion at today's T-compiler triage meeting.

rodrimati1992

comment created time in 13 days

issue commentrust-lang/rust

Worsened debug build codegen in beta

@rodrimati1992 out of curiosity, what prompted you to investigate this specific code sequence?

(I'm trying to evaluate the severity of this code-quality regression, and it might help for me to get some idea of how wide-spread the problem might be. There are obviously a couple different features interacting in the example you have provided...)

rodrimati1992

comment created time in 13 days

issue commentrust-lang/rust

25% compile time increase on beta when building async-std

triage: P-high. Removing nomination. Assigning to self. might be good to see if we can extract a case to add to perf.rlo from this.

jonas-schievink

comment created time in 13 days

issue commentrust-lang/rust

25% compile time increase on beta when building async-std

@jonas-schievink i figure until we've narrowed to a specific PR, we can keep the needs-bisect tag, right?

jonas-schievink

comment created time in 13 days

issue commentrust-lang/rust

internal compiler error: unexpected lifetime bound

(the bisection here would be entirely automatable if https://github.com/rust-lang/cargo-bisect-rustc/issues/34 were addressed.)

dwrensha

comment created time in 13 days

issue commentrust-lang/rust

internal compiler error: unexpected lifetime bound

triage : P-medium, removing nomination, adding needs-bisect.

dwrensha

comment created time in 13 days

issue commentrust-lang/rust

ICE: cannot convert `ReEarlyBound(0, 'a)` to a region vid

triage: P-high, assiging to self, removing nomination label

95th

comment created time in 13 days

issue commentrust-lang/rust

Rustc bug:cannot convert `ReEmpty` to a region vid

triage: P-high, assigning to self, removing nomination label.

lispc

comment created time in 13 days

issue commentrust-lang/rust

ICE field: higher-rank trait bound (HRTB) `for<'a> ...` hits OutputTypeParameterMismatch in librustc/traits/codegen

Nominating for discussion at compiler team meeting: Do we think we might try to address lazy-norm this year?

pnkfelix

comment created time in 13 days

issue closedrust-lang/rust

Compiler panic evaluating complex associated types

Compiler panic evaluating complex associated types meant to emulate generic associated types.

Playground

closed time in 13 days

svenknobloch

issue commentrust-lang/rust

Compiler panic evaluating complex associated types

triage: Closing as duplicate (or at least "instance") of #62529

svenknobloch

comment created time in 13 days

issue commentrust-lang/rust

ICE with const enum method returning Self

triage: P-high. Removing nomination. Assigning to self.

dylni

comment created time in 13 days

issue commentrust-lang/rust

'index out of bounds: the len is 1 but the index is 1': libcore/slice/mod.rs

triage: I don't want to assign a priority to this without more information. leaving nominated to ensure I come back to it.

harrisonthorne

comment created time in 13 days

issue commentrust-lang/rust

'index out of bounds: the len is 1 but the index is 1': libcore/slice/mod.rs

@threecgreen that is great that you can reproduce this bug. Can you provide a code sample for the reproduction, or a link to the source code for your crate where you are seeing it?

harrisonthorne

comment created time in 13 days

issue commentrust-lang/rust

Unable to compile syntex_syntax using Rust 1.41

triage: P-low, with intent to close. Leaving nominated because I want to at least discuss 1. whether we need/want to collect data on instances of such breakage, and 2. whether we were too aggressive in deciding that going straight to an error without some mitigating mechanism was too aggressive.

yaa110

comment created time in 13 days

issue commentrust-lang/rust

Unable to compile syntex_syntax using Rust 1.41

Hmm I hadn't noticed that syntex_syntax had been updated in that manner; I just saw that it has not been maintained in three years (see their readme)

This problem is expected fallout from PR #65785

yaa110

comment created time in 13 days

issue commentrust-lang/rust

TEXTREL in i686 since 1.41.0

triage: P-high. Assigning to self. Leaving nominated because I'd like to discuss this at today's meeting.

Cogitri

comment created time in 13 days

issue commentrust-lang/rust

1.40.0 ICE while reporting ICE

triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.

TheBlueMatt

comment created time in 13 days

issue commentrust-lang/rust

1.40.0 ICE while reporting ICE

Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see https://github.com/rust-lang/compiler-team/issues/207

TheBlueMatt

comment created time in 13 days

issue commentrust-lang/rust

`miri` no longer builds after rust-lang/rust#68861

triage: P-medium, removing nomination tag.

rust-highfive

comment created time in 13 days

issue commentrust-lang/compiler-team

Make incr. comp. respect the -Ccodegen-units setting

You say at the outset that "Incremental compilation currently will always create 1-2 codegen units per source-level module, regardless of the -Ccodegen-units setting passed to the compiler."

Just to be absolutely clear: Your intention, with the change proposed here, is that -Ccodegen-units will denote the (upper-bound on the) number of codegen-units across the entire crate currently being compiled, correct?

  • (For example, another interpretation of your words is that -Ccodegen-units would denote the number of codegen-units per source-level module, since today incrementatal always selects a value in the range 1-2 for that. This would be an admittedly strange interpretation given the other points you make.)
michaelwoerister

comment created time in 14 days

issue commentrust-lang/rust

Mutex and RwLock are unsound in presence of discriminant elision

(assigning self, since I authored PR #68491)

tmiasko

comment created time in 15 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

cc @jethrogb regarding above question ^

pnkfelix

comment created time in 15 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

looks like the fix doesn't quite work ...

2020-02-03T18:39:05.8494339Z In file included from /tmp/x86_64-fortanix-unknown-sgx_temp/llvm-project/libunwind/src/libunwind.cpp:34:0:
2020-02-03T18:39:05.8495103Z /tmp/x86_64-fortanix-unknown-sgx_temp/llvm-project/libunwind/src/UnwindCursor.hpp: In instantiation of 'RWLock libunwind::DwarfFDECache<libunwind::LocalAddressSpace>::_lock':
2020-02-03T18:39:05.8496130Z /tmp/x86_64-fortanix-unknown-sgx_temp/llvm-project/libunwind/src/UnwindCursor.hpp:177:3: required from 'static void libunwind::DwarfFDECache<A>::iterateCacheEntries(void (*)(unw_word_t, unw_word_t, unw_word_t, unw_word_t)) [with A = libunwind::LocalAddressSpace; unw_word_t = long unsigned int]'
2020-02-03T18:39:05.8496938Z /tmp/x86_64-fortanix-unknown-sgx_temp/llvm-project/libunwind/src/libunwind.cpp:321:37: required from here
2020-02-03T18:39:05.8497406Z /tmp/x86_64-fortanix-unknown-sgx_temp/llvm-project/libunwind/src/UnwindCursor.hpp:96:18: error: too many initializers for 'RWLock'
2020-02-03T18:39:05.8497557Z pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER;
2020-02-03T18:39:05.8497815Z ^~~~~~~~~~~~~~~~
2020-02-03T18:39:05.9671696Z make[3]: *** [src/CMakeFiles/unwind_objects.dir/libunwind.cpp.o] Error 1
2020-02-03T18:39:05.9672135Z src/CMakeFiles/unwind_objects.dir/build.make:62: recipe for target 'src/CMakeFiles/unwind_objects.dir/libunwind.cpp.o' failed
2020-02-03T18:39:05.9672465Z CMakeFiles/Makefile2:197: recipe for target 'src/CMakeFiles/unwind_objects.dir/all' failed
2020-02-03T18:39:05.9672761Z make[2]: *** [src/CMakeFiles/unwind_objects.dir/all] Error 2
2020-02-03T18:39:05.9673053Z CMakeFiles/Makefile2:172: recipe for target 'src/CMakeFiles/unwind_static.dir/rule' failed
2020-02-03T18:39:05.9673819Z make[1]: *** [src/CMakeFiles/unwind_static.dir/rule] Error 2
2020-02-03T18:39:05.9674520Z Makefile:190: recipe for target 'unwind_static' failed
2020-02-03T18:39:05.9674810Z make: *** [unwind_static] Error 2
2020-02-03T18:39:13.0779823Z The command '/bin/sh -c /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "63b1b1c5b1ca008099095aa0f8a081a80c8d27f4"' returned a non-zero code: 2

is this an artifact of the below change to the Dockerfile, which I rubber-stamped?

  COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/
  # We pass the commit id of the port of LLVM's libunwind to the build script.
  # Any update to the commit id here, should cause the container image to be re-built from this point on.
- RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "53b586346f2c7870e20b170decdc30729d97c42b"
+ RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "63b1b1c5b1ca008099095aa0f8a081a80c8d27f4"

  COPY dist-various-2/build-wasi-toolchain.sh /tmp/
  RUN /tmp/build-wasi-toolchain.sh
pnkfelix

comment created time in 15 days

issue commentrust-lang/rust

PartialEq implementation for RangeInclusive is unsound

To be honest, I'm trying to understand the actual goal here, in terms of how the T-libs team expects ranges to behave.

If it suffices to implement on a set of built-in integer types, then we can just do that right now. Certainly that is a simple approach. But is it actually sufficient, @xfix? Your comment seems to imply it would be...

xfix

comment created time in 15 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 16 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

Thanks for the patch @jethrogb !

pnkfelix

comment created time in 16 days

push eventpnkfelix/rust

varkor

commit sha f4f96e294335de13bc7341c626837affdb2e4a45

Normalise diagnostics with respect to "the X is declared/defined here"

view details

varkor

commit sha 24a2929ed1d3e1760bf89c878352448fb5ee2087

Normalise notes with the/is

view details

varkor

commit sha 45832839087da140eeb2a85a8b98927ec27ba21c

Update new tests

view details

Mazdak Farrokhzad

commit sha dc17f38e041e6bde95c6f6c5c6170dbb3917d51e

check_unsafety: more code reuse

view details

Andrew Paverd

commit sha c0744e1e0c35b1083733fd5c74fc3fb5a6cd04f7

Add support for Control Flow Guard on Windows. This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.

view details

Waffle

commit sha 1aff08010d6b35f2c7cef685b77ff1245c45a523

Add `Iterator::map_while` method and corresponding `MapWhile` adapter

view details

Waffle

commit sha db1a107b3f920637dc785fcc6d6bbe247a271e7b

Fill tracking issue for `iter_map_while` feature

view details

Yuki Okushi

commit sha cef7764a7624fabeb151b861f005a9d89da91a09

Avoid ICE in macro's diagnostics

view details

Nicholas Nethercote

commit sha 0d69fe8308a76630a104504c14e1d3d74e2a3f15

Use `P` for `NtTraitItem`, `NtImplItem`, and `NtForeignItem`. This commit reduces the size of `Nonterminal` from a whopping 240 bytes to 72 bytes (on x86-64), which gets it below the `memcpy` threshold. It also removes some impedance mismatches with `Annotatable`, which already uses `P` for these variants.

view details

Nicholas Nethercote

commit sha 7d2173ed27c1cddc4d4a7a9755f244b66cf1ec81

Use `P` for `NtMeta`. This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).

view details

Hiroki Noda

commit sha 50ed6cbf9836a48c938e74bb28501ffbbe59585e

Fix typo.

view details

Hiroki Noda

commit sha c870ca6217038e80138b69a88b2340b62859f52b

Update

view details

Nicholas Nethercote

commit sha 6961db2024aa96bc1ba2d8f38c5dc1ba49fdabd9

Remove unused `read_uleb128` parameter.

view details

Alex Crichton

commit sha ad0e4a167d950607430ff95022219671ab7054db

Update jobserver crate to 0.1.21 Brings in a fix for alexcrichton/jobserver-rs#23 which could cause Cargo to unnecessarily hang in some situations.

view details

Yuki Okushi

commit sha b1c91ee1b1a671e1d277763169abd9986195712a

Change Applicability to `HasPlaceholders`

view details

bors

commit sha 212b2c7da87f3086af535b33a9ca6b5242f2d5a7

Auto merge of #68661 - nnethercote:rm-unused-read_uleb128-param, r=Mark-Simulacrum Remove unused `read_uleb128` parameter.

view details

Guillaume Gomez

commit sha 2f575dab3030467525acae204e47f7a9a8311530

Add missing links for cmp traits

view details

Andy Russell

commit sha db319a8fb0126b84e0a0abbac83d4e1adeca6a95

suggest adding space in accidental doc comments

view details

Andy Russell

commit sha 7632ade65bde6160c46f31495532f5beadcaa3d8

clarify "incorrect issue" error

view details

Gregor Peach

commit sha 0d52c562db18e85cf53078c9ddb40abe469a4aab

Change opt-level from 2 back to 3 In Cargo.toml, the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is no longer needed. This creates a small compile time regression in MIR constant eval, so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small, so I've bumped the limit there.

view details

push time in 16 days

issue closedrust-lang/rust

ICE: 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:931:9

This may have a duplicate, since there are similar panics already reported, but this is on a different line number.

The compilation log and source code are listed below

pub mod client;
pub mod msg;

use std::collections::HashMap;
use std::sync::Arc;
use tokio::sync::broadcast::{channel, Receiver, Sender};

/**
 * A channel is named and typed with the type of messages it should be carrying
 */
struct Channel {
    name: String,
    send: Sender<Message>,
    recv: Receiver<Message>,
}

struct Message {}

impl Channel {
    fn send(&self, msg: Message) {}
    fn recv(&self, msg: Message) {}
}

struct Bus {
    /**
     * Channels are named and can implement a number of different types. This should
     * allow the Bus to handle different channels with different message payloads
     * while still taking advantage of compile-time checks
     */
    channels: HashMap<String, Channel>,
}

#[cfg(test)]
mod tests {
    use super::*;
}

compile.log

closed time in 16 days

rtyler

issue commentrust-lang/rust

ICE: 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:931:9

Since PR #68289 has landed, and there isn't enough information here to reproduce the bug as originally described (and thus I cannot test to see whether it is actually fixed, or create a regression test), I'm going to close this issue under the assumption that PR #68289 did fix the problem here.

rtyler

comment created time in 16 days

pull request commentrust-lang/rust

Implement MIR lowering for or-patterns

@bors r+

matthewjasper

comment created time in 16 days

Pull request review commentrust-lang/rust

Implement MIR lowering for or-patterns

 impl<'a, 'tcx> Builder<'a, 'tcx> {                 true,             )         } else {+            // It's helpful to avoid scheduling drops multiple times to save+            // drop elaboration from having to clean up the extra drops.+            //+            // If we are in a `let` then we only schedule drops for the first+            // candidate.+            //+            // If we're in a `match` arm then we could have a case like so:+            //+            // Ok(x) | Err(x) if return => { /* ... */ }+            //+            // In this case we don't want a drop of `x` scheduled when we

thank you so much for the elaboration here

matthewjasper

comment created time in 16 days

issue commentjmacdonald/amp

Dependence on syntex_syntax causes breakage as of nightly-2019-11-09.

I asked alexcrichton about this last week, and they told me that you should probably switch to https://crates.io/crates/syn

(So I figure use that, or throw away the build script and figure out how to redo your use case as a proc-macro.)

pnkfelix

comment created time in 16 days

push eventpnkfelix/rust

Jethro Beekman

commit sha 28151318d86c4bfcf8fee90de822a52decfa6f51

Fix SGX RWLock representation for UnsafeCell niche fix

view details

Felix S Klock II

commit sha 224caeea779b788677cde8f4e8b200fbab4aec72

Merge pull request #1 from jethrogb/jb/sgx-unsafecell-niche-fix Fix SGX RWLock representation for UnsafeCell niche fix

view details

push time in 16 days

PR merged pnkfelix/rust

Reviewers
Fix SGX RWLock representation for UnsafeCell niche fix

Also pulls in https://github.com/fortanix/llvm-project/pull/8

+14 -12

1 comment

2 changed files

jethrogb

pr closed time in 16 days

issue openedjmacdonald/amp

Dependence on syntex_syntax causes breakage as of nightly-2019-11-09.

Here is the output from trying to build on the currently nightly.

% cargo +nightly-2019-11-09 build
[...]
   Compiling syntex_syntax v0.58.1
   Compiling syntect v2.1.0
error[E0423]: expected function, tuple struct or tuple variant, found struct `ast::Name`
   --> /Users/felixklock/.cargo/registry/src/github.com-1ecc6299db9ec823/syntex_syntax-0.58.1/src/symbol.rs:146:27
    |
146 |                       name: ast::Name($index),
    |                             ^^^^^^^^^
...
165 | / declare_keywords! {
166 | |     // Invalid identifier
167 | |     (0,  Invalid,        "")
168 | |
...   |
231 | |     (56, CrateRoot, "{{root}}")
232 | | }
    | |_- in this macro invocation

   Compiling scribe v0.7.2
error: aborting due to previous error

For more information about this error, try `rustc --explain E0423`.
error: could not compile `syntex_syntax`.

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

This is known fallout from https://github.com/rust-lang/rust/pull/65785#issuecomment-546499161

created time in 20 days

pull request commentrust-lang/rust

[WIP] Commenting out unsound specialization.

(see also PR ##68358 )

pnkfelix

comment created time in 20 days

issue commentrust-lang/rust

PartialEq implementation for RangeInclusive is unsound

Just to keep people up to date: We (or I) tried removing the specialization in PR #68280.

The CI run for that revealed a regression test failure: This particular specialization has semantic meaning. It is not just a performance optimization, as I understand it.

I talked to @alexcrichton about this today, and they told me that the T-libs team would take charge on resolving this.

xfix

comment created time in 20 days

pull request commentrust-lang/rust

[WIP] Commenting out unsound specialization.

I discussed this with @alexcrichton today. He said the libs team would take charge on how to handle this PR and issue #67194

pnkfelix

comment created time in 20 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 20 days

push eventpnkfelix/rust

Charles Gleason

commit sha 293cdf7ac5d14811debdec3408afde104935caef

Make RangeMut::next_unchecked() output a mutable key reference

view details

Charles Gleason

commit sha f547978392872684085c96a3d5c1d00bad24b724

Implement clone_from for BTree collections

view details

Charles Gleason

commit sha 8651aa066fdbbcfaa082531969469c3fa289de9e

Add test for BTreeMap::clone_from

view details

CAD97

commit sha f76177ce4376ea15b1b303da347e8f653679cf88

Stabilize ptr::slice_from_raw_parts[_mut]

view details

CAD97

commit sha 1c0d4851a6a686d09b03fab575fb0847d1e9f665

Fix incorrect slice->ptr conversion in slice_from_raw_parts docs

view details

Linus Färnstrand

commit sha b5ff8064a4fe5b2bc70ee209b19d129b8ffc3ebc

Add MIN/MAX associated constants to the integer types

view details

Linus Färnstrand

commit sha 22dcfa1d8d18687d7ca0b91974bce4202d3383e9

Add relevant associated constants to the float types

view details

Linus Färnstrand

commit sha 9d257579fcaa44f69c8f7d5f668b05ae89e4507b

Fix some float operations to work together with the assoc consts

view details

Linus Färnstrand

commit sha 6ce16cfa42dcb1acd2c823a1d45269132d372409

Remove no longer valid test

view details

Linus Färnstrand

commit sha 9fcbaa4158948324f395ff2eb8061abdf6dbc21f

Fix broken show-const-contents test

view details

Linus Färnstrand

commit sha 4d9e90d2a5146e3f8639b53f29e210be94b30933

Unlock assoc_int_consts in core+std

view details

Linus Färnstrand

commit sha 002c7897a6c92397f6682bf7e9e86c9b4efd5c51

Unlock assoc_int_consts in documentation examples using it

view details

Linus Färnstrand

commit sha 61fecfb82fe088af6d3a7832b72f298064398aff

Add test accessing the module level int/float consts

view details

Guillaume Gomez

commit sha 85079f8b1fa8291593735b9b577e8e0dc22ad3b6

Fix run button positionning in case of scrolling

view details

Oliver Middleton

commit sha bbc2ae7590ad53fca02fda187e7f9c2470c9e949

rustdoc: Fix re-exporting primitive types * Generate links to the primitive type docs for re-exports. * Don't ICE on cross crate primitive type re-exports. * Make primitive type re-exports show up cross crate.

view details

Tomasz Miąsko

commit sha a6137fb730d59141ff2f5744b6cf36e29ef74e94

compiletest: Remove unnecessary memory allocation in iter_header Replace `BufRead::lines` with `BuRead::read_line` to reduce memory allocations.

view details

Tomasz Miąsko

commit sha 5ebec91abbfdbf6040918cb797765550812a03fd

compiletest: Parse EarlyProps from a reader

view details

Tomasz Miąsko

commit sha bb6aac38131528384343e6724578a89bf8daf68f

compiletest: Update mode list displayed in `--help`

view details

Tomasz Miąsko

commit sha d857f6f1aba6308cb4458ec1d210f722d55017cb

compiletest: Add unit tests for EarlyProps

view details

Tomasz Miąsko

commit sha 9a154a94b30baa333fe7399ee6dc2a01f395a27d

compiletest: Remove unused llvm-cxxflags option

view details

push time in 20 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 21 days

push eventpnkfelix/rust

Guillaume Gomez

commit sha 6590339c31ab934add15ec49bc474ba9d78435e2

Clean up E0205 explanation

view details

Guillaume Gomez

commit sha 94fcda0e1346f284c44a27c5c07c2b0999e5bc29

clean up E0214 explanation

view details

Guillaume Gomez

commit sha 3850d96379126087240b640470632362a5d32234

clean up error codes explanation

view details

Guillaume Gomez

commit sha 0f5ed4d2cdc3678cdd3a5c2dceb85a0ac8564f87

Clean up E0207 explanation

view details

Aaron Hill

commit sha 9ad1a8c97f8ee0c6af75bca7fae41f7c37d3e73c

Don't call `tcx.fn_sig` on closures Fixes #68542

view details

Guillaume Gomez

commit sha 833ffd7b839caa843f51bfa992baea89fe4fd2fb

Update src/librustc_error_codes/error_codes/E0220.md Co-Authored-By: Dylan DPC <dylan.dpc@gmail.com>

view details

William D. Jones

commit sha b0174ecf346830cedc038daa596672376219086b

Fix LLVM assertion failure in MSP430 interrupt generation.

view details

Mazdak Farrokhzad

commit sha de7f16d4313791a51b28822cbf08e8fbcaf78bde

check_match: extract common logic

view details

Guillaume Gomez

commit sha 4b0fe2ac63b983425c82a45cdb930019f36409bf

Clean up E0262 explanation

view details

Umesh Kalappa

commit sha 2a38eb3a86cd8f2679e046ca08c1102638ad316d

Disable the testcase for Vxworks.

view details

Santiago Pastorino

commit sha 3124603f0948fd5e2a1dc88908436d508846b7c6

Add support for icebreakers-cleanup-crew commands

view details

Ashley Mannix

commit sha 2c07a621ef80e059d788f9846c8bdfd2e44b5c58

stabilize the debug_map_key_value feature

view details

Yuki Okushi

commit sha 5c42ffe1504193fe526f23987b5430adf3895d47

Rollup merge of #68200 - KodrAus:stabilize/debug_map_key_value, r=alexcrichton Stabilize the debug_map_key_value feature RFC: https://github.com/rust-lang/rfcs/pull/2696 Tracking issue: #62482 Stabilizes the `debug_map_key_value` feature, which covers: ```rust impl<'a, 'b> DebugMap<'a, 'b> { pub fn key(&mut self, key: &dyn fmt::Debug) -> &mut DebugMap<'a, 'b> {} pub fn value(&mut self, value: &dyn fmt::Debug) -> &mut DebugMap<'a, 'b> {} } ``` These methods are small and self-contained, and are used as the basis for the existing `DebugMap::entry` method, so have been used in the wild for the last 6 months or so.

view details

Yuki Okushi

commit sha 2bfa058074abbf28b1a35e89aad83a8d291fc38b

Rollup merge of #68383 - GuillaumeGomez:clean-up-e0205, r=Dylan-DPC Clean up E0205 explanation r? @Dylan-DPC

view details

Yuki Okushi

commit sha dc33cd3500e6c59461e784253c4cb3ebffa97098

Rollup merge of #68412 - GuillaumeGomez:clean-up-e0207, r=Dylan-DPC Clean up E0207 explanation r? @Dylan-DPC

view details

Yuki Okushi

commit sha 39407c9ab7115cb521384014ed5499ff1a81cba9

Rollup merge of #68454 - GuillaumeGomez:clean-up-e0214, r=Dylan-DPC clean up E0214 explanation r? @Dylan-DPC

view details

Yuki Okushi

commit sha 8ed586581dd8336f54abc45f913680060c5e4187

Rollup merge of #68482 - GuillaumeGomez:clean-up-err-codes, r=Dylan-DPC clean up error codes explanation r? @Dylan-DPC

view details

Yuki Okushi

commit sha c38e97cc61d05601843624047bca9cb0dfe794a9

Rollup merge of #68563 - Aaron1011:fix/fn-sig-closure, r=varkor Don't call `tcx.fn_sig` on closures Fixes #68542

view details

Yuki Okushi

commit sha 1e47ca518f3efcbdd7b45baba6eead385c909878

Rollup merge of #68570 - cr1901:msp430-fix-1-2020, r=alexcrichton Bump LLVM submodule to fix LLVM assertion failure in MSP430 interrupt generation. This PR brings in changes introduced by [this cherry-pick](https://github.com/rust-lang/llvm-project/pull/37) to the Rust repository. Nightlies downloaded from `rustup` do not appear to have llvm assertions enabled; the assertion failure [sometimes](https://github.com/YuhanLiin/msp430fr2355-quickstart/issues/3) causes link errors that shouldn't occur. I couldn't find any indication of other bugs; however, it should still be fixed.

view details

Yuki Okushi

commit sha 8bc0e48540b38edfae892828db6cacd3bc4e5b95

Rollup merge of #68571 - Centril:check_in_cx, r=oli-obk check_match: extract common logic This is part of work on `hir::ExprKind::Let` which I thought made sense on its own (though makes even more sense with `::Let`). r? @oli-obk

view details

push time in 21 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@nikomatsakis The standard approach to internal feature gates is to put them in the "internal feature gates" section without a tracking issue:

https://github.com/rust-lang/rust/blob/b181835a6bacfa449f55d46764a10e25d1c471dc/src/librustc_feature/active.rs#L96-L98

@Centril I did put it in the "// feature-group-start: internal feature gates" section this time around (or at least that is what I think I did); but I also saw examples of some features in that sections that do have issue numbers, so I figured I was better off including it ...

at this point since this is internal only, I guess I will leave it out, since I am worried that making a tracking issue for it will mislead people into thinking it is a feature on the path to stabilization (even if the description for the tracking issue explicitly says otherwise).

pnkfelix

comment created time in 21 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

The standard approach to internal feature gates is to put them in the "internal feature gates" section without a tracking issue:

Or oh, maybe I won't then.

pnkfelix

comment created time in 21 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

I think I would prefer to have a true tracking issue, myself, versus pointing to this PR

Okay, I'll file a tracking issue (and do a proper local test run this time instead of assuming I got it right via x.py test tidy)

pnkfelix

comment created time in 21 days

pull request commentrust-lang/rust

Make conflicting_repr_hints a deny-by-default c-future-compat lint

@bors r+

Centril

comment created time in 21 days

pull request commentrust-lang/rust

[WIP] Commenting out unsound specialization.

Test failure is legit. The specialization is being used for correct behaviour. I think that RangeInclusive is maintaining an invariant that should allow working around this, but I need to check the code carefully.

I'll try to look into this during whatever down-time I have today.

pnkfelix

comment created time in 22 days

push eventpnkfelix/rust

Felix S. Klock II

commit sha d979fa2218465287e49f4f23045614c1d602d91e

placate tidy.

view details

push time in 22 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

👉 "who's got two thumbs and thought 'surely nothing bad could happen if I just change the issue number in the feature meta-data to point at this PR rather than the issue!' ...? This guy!" 👈

pnkfelix

comment created time in 22 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

@bors r=oli

pnkfelix

comment created time in 22 days

push eventpnkfelix/rust

Felix S. Klock II

commit sha fbbfbbb46095d9c6d096261d4fad9d5f7e05d475

Add `#[repr(no_niche)]`. This repr-hint makes a struct/enum hide any niche within from its surrounding type-construction context. It is meant (at least initially) as an implementation detail for resolving issue 68303. We will not stabilize the repr-hint unless someone finds motivation for doing so. (So, declaration of `no_niche` feature lives in section of file where other internal implementation details are grouped.)

view details

Felix S. Klock II

commit sha 73262c95e0e5935d4a803918832b6b0e1bfe0482

tests for `#[repr(no_niche)]`.

view details

Felix S. Klock II

commit sha 1be805f8e597692051e2d6af7f4ba3234fa930d4

Add `repr(no_niche)` to `UnsafeCell`. Fix #68303.

view details

Felix S. Klock II

commit sha 56491287a37cbd684c341c8c0d982ac215ff9dfc

incorporate review feedback.

view details

push time in 22 days

push eventpnkfelix/rust

Markus Westerlind

commit sha a5657dbc43d84133bd95e5de178d68634973b1b3

perf: Avoid creating a SmallVec if nothing changes during a fold Not sure if this helps but in theory it should be less work than what the current micro optimization does for `ty::Predicate` lists. (It would explain the overhead I am seeing from `perf`.)

view details

Markus Westerlind

commit sha 898ed636a3f44e3aa0156c1bb5ebc86b08aef5fa

Fix copy_from_slice which should be extend_from_slice

view details

Thom Chiovoloni

commit sha 6a7a69bde9813ac2868f36a01567c633ed6cd023

Add {leading,trailing}_ones to primitive int types

view details

Thom Chiovoloni

commit sha 2330e325ccee2e91d7aec6c0d4068748619bf588

Tests for leading_trailing_ones

view details

Markus Westerlind

commit sha a1586f1d2b17d687444d3b94aedd7ce24ae074ed

Explain fold_list

view details

Thom Chiovoloni

commit sha 783a7dc8ed03a38910b9ea5ded11139616dfa67b

Mark leading_trailing_ones with tracking issue 57969

view details

csmoe

commit sha 42b6ed13be779499d118af721913a66bd3d946ea

account temporary borrow by raw-ptr

view details

csmoe

commit sha cd7b5edc2cac3fa0db6b464a6e94edd8f334274d

update test ui for raw-ptr borrow inside generator

view details

Tianjiao Huang

commit sha d336e593cc07139468c8f6f12b929e80ae365159

Fix invalid link to C++ Exception Handling ABI documentation

view details

Mazdak Farrokhzad

commit sha 93efe41b4ef9e0cccedbf962381002d48b3f780c

stabilize transparent_enums

view details

Mazdak Farrokhzad

commit sha 25460ebef6ae94494fc89a736a2f51bef2ea55c3

transparent_enums: test alignment

view details

Tomasz Miąsko

commit sha 6d218db26df424722d13db0ed3babae3cf450bb3

compiletest: Simplify multi-debugger support Previous implementation used a single mode type to store various pieces of otherwise loosely related information: * Whether debuginfo mode is in use or not. * Which debuggers should run in general. * Which debuggers are enabled for particular test case. The new implementation introduces a separation between those aspects. There is a single debuginfo mode parametrized by a debugger type. The debugger detection is performed first and a separate configuration is created for each detected debugger. The test cases are gathered independently for each debugger which makes it trivial to implement support for `ignore` / `only` conditions. Functional changes: * A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.). * Debugger name is included in the test name. * Test outputs are placed in per-debugger directory. * Fixed spurious hash mismatch. Previously, the config mode would change from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or `DebugInfoLldb` (when running them) which would affect hash computation. * PYTHONPATH is additionally included in gdb hash. * lldb-python and lldb-python-dir are additionally included in lldb hash.

view details

Erin Power

commit sha c75a1f0e4dfd6e4a3929bc6496018734b5ef60c9

Update RELEASES.md for 1.41.0

view details

XAMPPRocky

commit sha 5918e9f02595a4b9ffacc4ecf5a0d470528a3824

Update RELEASES.md

view details

Esteban Küber

commit sha c775927d7fee06743631d138eac91a862c8f6faf

Suggest borrowing `Vec<NonCopy>` in for loop Partially address #64167.

view details

Aaron Hill

commit sha 4ee4287b1da13f56d063fa5b4234780def0d5af1

Account for non-types in substs for opaque type error messages Fixes #68368 Previously, I assumed that the substs contained only types, which caused the computed index number to be wrong.

view details

Oliver Middleton

commit sha 9d3e84432dae2e96a5e0f97be18ee09b5a2217b1

Avoid overflow in `std::iter::Skip::count` The call to `count` on the inner iterator can overflow even if `Skip` itself would return less that `usize::max_value()` items.

view details

Aaron Green

commit sha 4210409f443a40c72876e5e8398e8652a47a2ba6

Enable ASan on Fuchsia This change adds the x86_64-fuchsia and aarch64-fuchsia LLVM targets to those allowed to invoke -Zsanitizer. Currently, the only overlap between compiler_rt sanitizers supported by both rustc and Fuchsia is ASan.

view details

Aaron Green

commit sha 192650a9aac7a2e006afbbafb83088eaf0d9d820

Fix tidy warnings

view details

Tomasz Miąsko

commit sha 5c73d21eaa48b7c94bedcc5352fcbc7d749ed48b

Use check-pass mode for nll tests

view details

push time in 22 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

(I lost the race with PR #68122; I'll rebase atop current master and update the test to remove #![feature(transparent_enums)])

pnkfelix

comment created time in 22 days

pull request commentrust-lang/rust

Don't ICE on path-collision in dep-graph

@michaelwoerister okay I've incorporated your proposal into this version.

pnkfelix

comment created time in 22 days

push eventpnkfelix/rust

Felix S. Klock II

commit sha c29be616278e583b76d8aa2d486585ae8112c1c2

incorporate review feedback.

view details

push time in 23 days

Pull request review commentrust-lang/rust

Hide niches under UnsafeCell

 impl<'tcx> LayoutCx<'tcx, TyCtxt<'tcx>> {             debug!("univariant offset: {:?} field: {:#?}", offset, field);             offsets[i as usize] = offset; -            if let Some(mut niche) = field.largest_niche.clone() {-                let available = niche.available(dl);-                if available > largest_niche_available {-                    largest_niche_available = available;-                    niche.offset += offset;-                    largest_niche = Some(niche);+            if !repr.hide_niche() {+                if let Some(mut niche) = field.largest_niche.clone() {

(oh, believe you me, I spent a while trying to convince myself that if let (false, Some(mut niche)) = (repr.hide_niche(), ...) { ... } was the way to go. But I just couldn't deal with having the false be that "far" from the hide_niche() method call. I even considered making an enum NicheHidden { ... } to make the bit's meaning more apparent.)

pnkfelix

comment created time in 23 days

push eventpnkfelix/rust

Oliver Scherer

commit sha 9158e17997db0a21a27774a66b944539f4ef441a

Document more use cases of dataflow

view details

cad97

commit sha c842f02dee81e52f3b63a8b46021a8e18f143a7e

Use pointer offset instead of deref for A/Rc::into_raw

view details

CAD97

commit sha eb77f7ec6e9460c1ca70fbb7bb655f1a0a1bacfc

Add internal safety docs to (A)Rc::into_raw

view details

Oliver Scherer

commit sha 5f08df104742ce400e966f6cd80c9029f0328922

Address review comments

view details

Mikhail Zabaluev

commit sha a20013b129c10907aee0bfb5bf1cac387e48eb51

Add Result::unwrap_infallible Implementation of https://github.com/rust-lang/rfcs/pull/2799

view details

Mikhail Zabaluev

commit sha 9a99a2159bb57ee0f1a52bb3f989a903df2f8cb4

libcore: test Result::unwrap_infallible

view details

Mikhail Zabaluev

commit sha 6f0672c08b7609c7ed77245a3feea3040221b804

Rename Result::unwrap_infallible to into_ok

view details

Matt Brubeck

commit sha 207e60a364a23e15261f4fdd6471907d4fa906f4

Stabilize Condvar::wait_until and wait_timeout_until

view details

Matt Brubeck

commit sha 98d054af08017e4b7f68c4985b1ed821b845fc00

Rename wait_until/wait_timeout_until to wait_while/white_timeout_while

view details

Matthew Jasper

commit sha 4843f227885bf23a34cc8485173c11601b00d977

Handle recursive instantiation of drop shims

view details

Erin Power

commit sha 2ccf65c7eba519dcc407cb76f08d04ac00d05851

Remove appendix from LICENCE-APACHE

view details

Felix S. Klock II

commit sha 0435c1b0a5fbc0cbaef8cb9f1711d3e30c944781

When a codegen worker has a FatalError, propagate it instead of ICE'ing.

view details

Felix S. Klock II

commit sha 7c5cff717ffb13c8d0b9eb4d287bd2c565a9d7f4

regression test for 66530. it uses normalize-stderr-test because not all targets hit the same OS error number nor message ... ... and ignores tidy since I dont know how to make the normalize line shorter ... and has effectively a no-op for its error-pattern because the targets' error messages are so wildly different (and the error-pattern check occurs *before* stderr normalization.)

view details

Stein Somers

commit sha 8314b7fd27350681ecbe5d55f840ddc5873d222f

More thorough testing of BTreeMap::range

view details

Mark Rousskov

commit sha 73996df6291001f0742b6409249329301aa77a23

Reset Formatter flags on exit from pad_integral This fixes a bug where after calling pad_integral with appropriate flags, the fill and alignment flags would be set to '0' and 'Right' and left as such even after exiting pad_integral, which meant that future calls on the same Formatter would get incorrect flags reported. This is quite difficult to observe in practice, as almost all formatting implementations in practice don't call `Display::fmt` directly, but rather use `write!` or a similar macro, which means that they cannot observe the effects of the wrong flags (as `write!` creates a fresh Formatter instance). However, we include a test case.

view details

Mateusz Mikuła

commit sha 66207ae7f8e793c58bccca6464feb9deeed24adf

ci: bump ubuntu 19.04 images to 19.10 Ubuntu 19.04 goes EOL this month.

view details

Matthew Jasper

commit sha 5e92625004546005c3bc59351dd6c5132312f0f7

Correctly check for opaque types in `assoc_ty_def`

view details

Guillaume Gomez

commit sha 9876f6bd9c2927633e6df21889a585469dc5fce6

Fix error code failure check in rustdoc test

view details

Thomas de Zeeuw

commit sha d288c28ff323445e6157b95893072a571009a434

Relax the Sized bounds on Pin::map_unchecked(_mut)

view details

varkor

commit sha 3ab95ceb12b60c1564d037e8d8d6e2406fad44b3

Detail transitive containment in E0588 diagnostic

view details

push time in 23 days

Pull request review commentrust-lang/rust

Hide niches under UnsafeCell

 impl<'tcx> LayoutCx<'tcx, TyCtxt<'tcx>> {                     return Ok(tcx.intern_layout(st));                 } +                // At this point, we have handled all unions and+                // structs. (We have also handled univariant enums+                // that allow niche-optimization.)

fair enough, I'll sed -e s/niche-optimization/representation optimization/ here. I just didn't want to accidentally imply that all enums are handled in the remaining code.

pnkfelix

comment created time in 23 days

pull request commentrust-lang/rust

Don't ICE on path-collision in dep-graph

@michaelwoerister I'll look into using your revised approach

pnkfelix

comment created time in 23 days

pull request commentrust-lang/rust

Hide niches under UnsafeCell

Was the choice of #[repr(no_niche)] discussed, as opposed to making just UnsafeCell special?

We did discuss it at the relevant lang team meeting. I think it is fair to say that no one there was a strong champion of the #[repr(no_niche)] approach.

I nonetheless went with it.

It is more readily adaptable if we discover other cases that should be treated like this.

It is also more flexible: for example, if we decide that we want Cell<T> to expose its niche, then we could rewrite the stdlib this way, without having to modify rustc:

#[lang = "unsafe_cell"]
#[repr(transparent)]
struct UnsafeCellWithExposedNiche<T: ?Sized> {
    value: T,
}

#[repr(transparent)]
#[repr(no_niche)]
pub struct UnsafeCell<T: ?Sized> {
    value: UnsafeCellWithExposedNiche<T>,
}

#[repr(transparent)]
pub struct Cell<T: ?Sized> {
    value: UnsafeCellWithExposedNiche<T>,
}
pnkfelix

comment created time in 25 days

more