profile
viewpoint

lalrpop/lalrpop 1477

LR(1) parser generator for Rust

graydon/bors 360

Integration robot for buildbot and github

brson/rust-sdl 171

SDL bindings for Rust

dslomov/typed-objects-es7 112

ES7 typed objects spec draft

aatxe/oxide 68

The essence of Rust.

nikomatsakis/borrowck 55

Modeling NLL and the Rust borrowck

nikomatsakis/bidir-type-infer 29

Implementing the type system described in the paper "Complete and Easy Bidirectional Type Inference" in Rust

jbclements/rust-redex 22

A Redex Model of Rust, or more specifically an encoding of Patina, the formal model for rust's type safety

Pull request review commentrust-lang/chalk

Variance

 mod test {         let a = table.new_variable(U0).to_ty(interner);         let b = table.new_variable(U0).to_ty(interner);         table-            .unify(interner, &environment0, &a, &ty!(apply (item 0) (expr b)))+            .relate(+                interner,+                &TestDatabase,+                &environment0,+                Variance::Invariant,+                &a,+                &ty!(apply (item 0) (expr b)),+            )             .unwrap();-        assert_eq!(-            DeepNormalizer::normalize_deep(&mut table, interner, &a),-            ty!(apply (item 0) (expr b))-        );+        // FIXME: can't just assert these are equal because the inference var gets set to a new var (?2)+        // which is unified with b (?1). It might be good to pick a root to return. For now,+        // this doesn't work as-is.+        //assert_eq!(+        //    DeepNormalizer::normalize_deep(&mut table, interner, &a),+        //    &ty!(apply (item 1)),+        //);

hmm I don't get what's going on here

daboross

comment created time in 3 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rfcs

RFC: Custom DSTs

Some updates from the @rust-lang/lang team:

  • We are planning to have a design meeting on November 4th to discuss https://github.com/rust-lang/rfcs/pull/2580 and to touch on some of the extensions to it, including this RFC. Feel free to ping me if you'd like more info about the meeting.
  • To that end, I've been preparing a hackmd that summarizes key points from RFC 2580 and this RFC along with other related work. I'd appreciate any comments on it for inaccuracies or other mistakes.
strega-nil

comment created time in 4 hours

issue commentrust-lang/rust

repr(transparent) on generic type skips "exactly one non-zero-sized field" check

Indeed, ZSTs exist though only in non-standard extensions.

The real question here is whether there exists some "special" 1-ZST that would be treated differently by the ABI than any other 1-ZST. I do not believe that is the case, which is why () is kind of "as good as any other". (There are some C structs, as I understand it, that are treated somewhat specially by ABIs, but very few -- I think maybe having to do with complex types? Can't remember.)

mahkoh

comment created time in 5 hours

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous

I'm going to leave this nominated.

jmesmon

comment created time in 5 hours

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous

We discussed this in the @rust-lang/lang meeting today. Our consensus was that in light of the larger-than-expected impact, as well as @petrochenkov's comment, that we should revert #77421 and restore the older behavior. There is a reasonable case to be made for either behavior: there is a self-cycle here, but there is also only one reasonable way to resolve the cycle at present. (I presume that if

However @petrochenkov I'd like to get your take. I was reading a bit into https://github.com/rust-lang/rust/issues/74556 and especially this comment of yours which seems to be the best summary of what we are "giving up" by accepting this pattern. I'm having a bit of trouble parsing it though, I admit.

I did find the example from #74556 interesting and I don't feel like we explored it in the @rust-lang/lang meeting. The example is:

mod foo {
    pub mod bar {
        pub mod bar {
            pub fn foobar() {}
        }
    }
}

use foo::*;
use bar::bar;
use bar::foobar;

fn main() {
    bar::foobar();
}

What happens here, as best as I can tell, is that use foo::* imports bar as crate::foo::bar but it is "from a glob". We then see the use bar::bar which is resolved based on that import but then shadows it. This is precisely the "time traveling" we were trying to avoid, where the name bar has multiple meanings across different paths. What's worse, the new version of bar (crate::foo::bar::bar) is then used to resolve foobar.

It seems important to me to reject this case, but perhaps it is not so easy to reject this case while also permitting cases like the one in the OP?

jmesmon

comment created time in 5 hours

issue commentrust-lang/rust

regression: target_feature no longer permitted in some places

Summary:

  • unused #[target_feature] attributes appearing in surprising places because of https://github.com/rust-lang/rust/pull/71205, places that have no effect
  • another case where we have to think about our regression policy
  • seems clear that the "detect if attributes are used" part of the compiler winds up incorrectly thinking that things are used fairly regularly
  • given limited impact and the fact that it's clearly a bug, we're inclined to let this change go forward as a bug fix (we can revisit if/when we receive more complaints)
Mark-Simulacrum

comment created time in 5 hours

issue commentrust-lang/lang-team

Discuss RFC 2580 (Pointer metadata and vtable)

This is now scheduled for Nov 4. We'll need some preparation work.

Sense for the meeting:

  • Immediate desire is to be able to manipulate representation of trait objects
    • Summary of the RFC and what it propses
  • But want to be forwards compatible with future developments like custom dst, dyn A + B, etc
    • Will therefore want a summary of some of those ideas and notes on how they interact

If folks can leave comments with notes on some of the future developments (e.g., pointers to RFCs, etc) that would be useful to help in preparing this document.

nikomatsakis

comment created time in 6 hours

issue commentrust-lang/lang-team

never type stabilization

Status update 2020-10-26:

Still poking at this. Lint currently warns about libstd more than we'd like.

nikomatsakis

comment created time in 6 hours

issue commentrust-lang/lang-team

RFC 2229

Update 2020-10-26:

Uncovered a few interesting things this far. For example, this changes behavior:

let c = || {
    let _ = x;  // today: borrows `x`
};

In the new edition, using the new RFC, x would not be captured.

nikomatsakis

comment created time in 6 hours

issue commentrust-lang/lang-team

project-safe-transmute

Update 2020-10-26:

  • Would still like a follow-up design meeting, but haven't gotten organized yet.
nikomatsakis

comment created time in 6 hours

issue commentrust-lang/lang-team

Declarative macro repetition counts

No update this week.

nikomatsakis

comment created time in 6 hours

issue commentrust-lang/lang-team

const-generics

2020-10-26:

  • lcnr and I prepared a list of test cases last week.
  • What is the next procedural step?
    • Stabilization report seems appropriate but is not a great place for lasting documentation
    • RFC would be more visible but we don't really need the "comment requirement"
nikomatsakis

comment created time in 6 hours

Pull request review commentrust-lang/lang-team

Initial draft of copy ergonomics design note

+# Copy type ergonomics++## Background++There are a number of pain points with `Copy` types that the lang team is+interested in exploring, though active experimentation is not currently ongoing.++Some key problems are:++## `Copy` cannot be implemented with non-`Copy` members++There are standard library types where the lack of a `Copy` impl is an+active pain point, e.g., [`MaybeUninit`](https://github.com/rust-lang/rust/issues/62835)+and [`UnsafeCell`](https://github.com/rust-lang/rust/issues/25053)++### History++ * `unsafe impl Copy for T` which avoids the requirement that T is recursively+   Copy, but is obviously unsafe.+    * https://github.com/rust-lang/rust/issues/25053#issuecomment-218610508+ * `Copy` is dangerous on types like `UnsafeCell` where `&UnsafeCell<T>`+   otherwise would not permit access to `T` in [safe+   code](https://github.com/rust-lang/rust/issues/25053#issuecomment-98447164).++## `Copy` types can be (unintentionally) copied++Even if a type is Copy (e.g., `[u8; 1024]`) it may not be a good idea to make+use of that in practice, since copying large amounts of data is slow.++This also comes up with `Copy` impls on `Range`, which would generally be+desirable but is error-prone given the `Iterator/IntoIterator` impls on ranges.++Note that "large copies" comes up with moves as well (whih are copies, just+taking ownership as well), so a size-based lint is plausibly desirable for both.++### History++* Tracking issue: [#45683](https://github.com/rust-lang/rust/issues/45683)++## References to `Copy` types++Frequently when dealing with code generic over T you end up needing things like+`[u8]::contains(&5)` which is ugly and annoying. Iterators of copy types also+produce `&&u64` and similar constructs which can produce unexpected type errors.

Here is one:

for x in &vec![1, 2, 3, 4, 5, 6, 7] {
    process(*x); // <-- annoying that we need `*x`
}

fn process(x: i32) { }
Mark-Simulacrum

comment created time in 7 hours

Pull request review commentrust-lang/lang-team

Initial draft of copy ergonomics design note

+# Copy type ergonomics++## Background++There are a number of pain points with `Copy` types that the lang team is+interested in exploring, though active experimentation is not currently ongoing.++Some key problems are:++## `Copy` cannot be implemented with non-`Copy` members++There are standard library types where the lack of a `Copy` impl is an+active pain point, e.g., [`MaybeUninit`](https://github.com/rust-lang/rust/issues/62835)+and [`UnsafeCell`](https://github.com/rust-lang/rust/issues/25053)++### History++ * `unsafe impl Copy for T` which avoids the requirement that T is recursively+   Copy, but is obviously unsafe.+    * https://github.com/rust-lang/rust/issues/25053#issuecomment-218610508+ * `Copy` is dangerous on types like `UnsafeCell` where `&UnsafeCell<T>`+   otherwise would not permit access to `T` in [safe+   code](https://github.com/rust-lang/rust/issues/25053#issuecomment-98447164).++## `Copy` types can be (unintentionally) copied++Even if a type is Copy (e.g., `[u8; 1024]`) it may not be a good idea to make+use of that in practice, since copying large amounts of data is slow.++This also comes up with `Copy` impls on `Range`, which would generally be+desirable but is error-prone given the `Iterator/IntoIterator` impls on ranges.

I think it'd be useful to have canonical examples here of the kinds of code that can be surprising. I think one particularly compelling case has to do with closures:

let mut x = (0..10);
let c = move || x.next();
println!("{}", x.next()); // prints 0
println!("{}", c()); // prints 0

Of course, if you remove the move then this code behaves quite differently. (You get 0 and 1.)

You can make a very similar example with Cell.

I'm not sure of the best examples otherwise. Certainly if you write let y = x you get the same behavior, but it doesn't seem especially surprising to me (it's kind of the same as with any integer, for example).

One interesting example might be let x = &Cell::new(10).

Mark-Simulacrum

comment created time in 7 hours

Pull request review commentrust-lang/lang-team

Initial draft of copy ergonomics design note

+# Copy type ergonomics++## Background++There are a number of pain points with `Copy` types that the lang team is+interested in exploring, though active experimentation is not currently ongoing.++Some key problems are:++## `Copy` cannot be implemented with non-`Copy` members++There are standard library types where the lack of a `Copy` impl is an+active pain point, e.g., [`MaybeUninit`](https://github.com/rust-lang/rust/issues/62835)+and [`UnsafeCell`](https://github.com/rust-lang/rust/issues/25053)++### History++ * `unsafe impl Copy for T` which avoids the requirement that T is recursively+   Copy, but is obviously unsafe.+    * https://github.com/rust-lang/rust/issues/25053#issuecomment-218610508+ * `Copy` is dangerous on types like `UnsafeCell` where `&UnsafeCell<T>`+   otherwise would not permit access to `T` in [safe+   code](https://github.com/rust-lang/rust/issues/25053#issuecomment-98447164).++## `Copy` types can be (unintentionally) copied++Even if a type is Copy (e.g., `[u8; 1024]`) it may not be a good idea to make+use of that in practice, since copying large amounts of data is slow.++This also comes up with `Copy` impls on `Range`, which would generally be+desirable but is error-prone given the `Iterator/IntoIterator` impls on ranges.++Note that "large copies" comes up with moves as well (whih are copies, just+taking ownership as well), so a size-based lint is plausibly desirable for both.++### History++* Tracking issue: [#45683](https://github.com/rust-lang/rust/issues/45683)++## References to `Copy` types++Frequently when dealing with code generic over T you end up needing things like+`[u8]::contains(&5)` which is ugly and annoying. Iterators of copy types also+produce `&&u64` and similar constructs which can produce unexpected type errors.

Again I think specific examples would be useful

Mark-Simulacrum

comment created time in 7 hours

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

issue commentrust-lang/rust

repr(transparent) on generic type skips "exactly one non-zero-sized field" check

That's a good point. So here is a proposed set of rules:

  • A repr(transparent) type T must meet the following rules:
    • It may have any number of 1-ZST fields
    • In addition, it may have at most one other field of type U

If that other field is present, then T behaves like type U for ABI purposes. Otherwise, T consists only of 1-ZST types, and it behaves like (), which is the "canonical" 1-ZST.

I'm going to go ahead and kick off an FCP request...

@rfcbot fcp merge

mahkoh

comment created time in 11 hours

PullRequestReviewEvent

issue commentrust-lang/rust

Increasingly slow compilation as more levels of `async` are added in Rust 1.46

@udoprog nice reduction! I wonder if it's the same root issue. Regardless, worth exploring.

nicholasbishop

comment created time in 11 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

TypeFoldable: take self by value

Perf impact looks negligible.

lcnr

comment created time in 11 hours

pull request commentrust-lang/rust

Revert "Allow dynamic linking for iOS/tvOS targets."

I agree with the conclusion to revert, but I also agree with @aspenluxxxy that we don't have the "right fix" here long term and it'd be good to pursue something better. It sounds like this is likely more on the cargo side, however.

francesca64

comment created time in 11 hours

issue commentrust-lang/rust

ICE: tuple_fields called on non-tuple: async fn with unknown macro

Fix in #78392 (in progress)

matthiaskrgr

comment created time in 11 hours

issue commentrust-lang/rust

Increasingly slow compilation as more levels of `async` are added in Rust 1.46

@pnkfelix can you verify whether #72796 and/or #75443 would fix the problem for that test?

nicholasbishop

comment created time in 11 hours

issue commentrust-lang/rust

repr(transparent) on generic type skips "exactly one non-zero-sized field" check

@chorman0773 Ah, sorry, I missed that comment. I agree that "first member" is an option, though I have a mild preference for avoiding a reliance on the ordering that things were written. That said, I also have a mild preference for avoiding introducing an arbitrary type like (). I doubt it matters much in practice since I imagine that all 1-ZSTs basically behave the same with respect to the ABI, though.

mahkoh

comment created time in 11 hours

pull request commentrust-lang/rust

Fix control flow check for breaking with diverging values

@bors r+

varkor

comment created time in 11 hours

pull request commentrust-lang/rust

impl<A, B> IntoIterator for (A, B) as Zip

I wasn't aware of Python's interpretation. That seems like a negative.

The cartesian product interpretation doesn't worry me as much because (ime) it is used far less frequently than zip.

That said I agree that a free function or inherent tuple method might make for an interesting choice, although the need to import it is certainly a bit of a drag. But writing std::iter::zip(a, b) in place is also not that terrible, actually. (I've found that ever since the module changes in Rust 2018, I am much less reluctant to write out full paths...)

cuviper

comment created time in 11 hours

issue commentrust-lang/rust

Tracking issue for `X..`, `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)

@joshtriplett

I found your comments somewhat confusing. Specifically, I think you said that ..5 (RangeTo) is not an iterator (which seems to be true), but then you said that for loops over something like ..5 might be confusing (because they might start with negative numbers). Can you clarify?

It seems to me that pattern matching is less problematic than for loops, since it only "validates" the data that is coming in, and if that data is actually unsigned (despite having a signed type) than everything will be fine. I guess it seems unlikely to me that people would write ..5 to mean 0..5 when they know that negative numbers are a possibility (though perhaps they are not thinking of negative numbers at all, but that's kind of a separate problem I suppose).

(I do tend to agree that it is going to be a source of confusion whether ..5 starts from zero or not, but then, the behavior is already stable, and I do tend to agree having (..5).contains(_) and match x { ..5 => ... } both work and work the same seems desirable.)

Centril

comment created time in 11 hours

Pull request review commentrust-lang/rust

Ensure no type errors when calling Closure/Generator upvars_ty

 impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> {              ty::Closure(_, substs) => {                 // (*) binder moved here-                let ty = self.infcx.shallow_resolve(substs.as_closure().tupled_upvars_ty());-                if let ty::Infer(ty::TyVar(_)) = ty.kind() {-                    // Not yet resolved.-                    Ambiguous++                if let Ok(tupled_tys) = substs.as_closure().tupled_upvars_ty() {

Nit: it feels like we may want a helper for this pattern of shallow resolving the tupled_upvars_ty, but maybe it doesn't occur that often actually.

arora-aman

comment created time in 12 hours

Pull request review commentrust-lang/rust

Ensure no type errors when calling Closure/Generator upvars_ty

 impl<'tcx> GeneratorSubsts<'tcx> {      #[inline]     pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx {

Nit: I think this function merits a comment too. Something like

Returns an iterator over the upvar types for this closure/generator. This should only be invoked after type check is complete; before that, the upvar types may still be being inferred or may be an inference variable. To access the upvar types before type check is known to have completed, use tupled_upvar_tys.

That said, this will still ICE in the event of a Ty::Err, right? I'm not sure if that's a great idea, as it means that every use of this function has to be guarded by a call to tupled_upvars_ty. Why not make this function return a Result as well (or perhaps an empty vector)?

arora-aman

comment created time in 12 hours

Pull request review commentrust-lang/rust

Ensure no type errors when calling Closure/Generator upvars_ty

 impl<'tcx> UpvarSubsts<'tcx> {     }      #[inline]-    pub fn tupled_upvars_ty(self) -> Ty<'tcx> {+    pub fn tupled_upvars_ty(self) -> Result<Ty<'tcx>, ErrorReported> {

Pre-existing to some extent, but I think this function merits a comment. Something like:

Returns a tuple type whose elements are the types of the upvars captured by this closure/generator. Returns Err(ErrorReported) if a type error prevented us from figuring out the types of the upvars for this closure.

arora-aman

comment created time in 12 hours

PullRequestReviewEvent
PullRequestReviewEvent

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha d832025f9400a2d8d9bb75c30aa26898856b7128

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in a day

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 2351c3f1c7050aece57fbf9f56113d937dd79c54

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in a day

pull request commentalumxi22/website

2020 10 event descriptions

OK, I regenerated the site. (Sigh, I had to cherry-pick the two commits to modify gnu parallel and then remove them =)

nikomatsakis

comment created time in 3 days

push eventalumxi22/website

Niko Matsakis

commit sha 938de3319e6775d7ecdfbfa025784fd1ddaeff94

regenerate site

view details

push time in 3 days

pull request commentrust-lang/rfcs

Amend RFC2603 to allow mangled identifiers to start with a digit.

Merging as this reflects the actual implementation.

eddyb

comment created time in 3 days

push eventrust-lang/rfcs

Eduard-Mihai Burtescu

commit sha 5a4d1548467e28866dc1328b305da81589381b76

Amend RFC2603 to allow identifiers to start with a digit.

view details

Niko Matsakis

commit sha c849288a19be8883b2ba938144b25543fd31e2cc

Merge pull request #2705 from eddyb/mangling-underscore-escaping Amend RFC2603 to allow mangled identifiers to start with a digit.

view details

push time in 3 days

PR merged rust-lang/rfcs

Amend RFC2603 to allow mangled identifiers to start with a digit. I-nominated T-compiler

This was suggested by @pnkfelix in https://github.com/rust-lang/rfcs/pull/2603#discussion_r279670424, and @michaelwoerister seemed to agree to it, but it didn't make it into the RFC before merging.

I also removed the 0-9 -> A-J rewriting of Punycode's base-36 encoding, as it only existed to avoid having identifiers start with decimal digits, which would now work.

cc @rust-lang/compiler Do we have a procedure for amending RFCs?

+19 -23

4 comments

1 changed file

eddyb

pr closed time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/blog.rust-lang.org

Core team membership changes

+---+layout: post+title: "Core team membership changes"+author: Mark Rousskov+team: The Core Team <https://www.rust-lang.org/governance/teams/core>+---++The core team has had a few membership updates in the last month, and we wanted to provide an update.
The core team has had a few membership updates in the last month and we wanted to provide an update.

I can't tell if there should be a comma here or not :P whichever looks better to you

Mark-Simulacrum

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/blog.rust-lang.org

Core team membership changes

LGTM.

Mark-Simulacrum

comment created time in 3 days

PullRequestReviewEvent

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 6c264680ce079352b5159ff868a730ba481bd88d

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 4 days

Pull request review commentrust-lang/rust

Fix control flow check for breaking with diverging values

+#![feature(never_type)]++fn loop_break_return() -> i32 {+    let loop_value = loop { break return 0 }; // ok+}++fn loop_break_loop() -> i32 {+    let loop_value = loop { break loop {} }; // ok+}++fn loop_break_break() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break break };+}++fn loop_break_return_2() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break { return; () } };
varkor

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Fix control flow check for breaking with diverging values

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

I think this is the change that @eddyb was proposing and I suspect it will fix the break { return 0; () } example.

varkor

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Fix control flow check for breaking with diverging values

+#![feature(never_type)]++fn loop_break_return() -> i32 {+    let loop_value = loop { break return 0 }; // ok+}++fn loop_break_loop() -> i32 {+    let loop_value = loop { break loop {} }; // ok+}++fn loop_break_break() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break break };+}++fn loop_break_return_2() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break { return; () } };

I believe this is because of the point that @eddyb raised earlier.

varkor

comment created time in 4 days

PullRequestReviewEvent

issue commentrust-lang/rust

repr(transparent) on generic type skips "exactly one non-zero-sized field" check

OK, so, to restate the above point:

We should check whether you can use generics to "sneak" in a ZST with alignment other than 1 (e.g., [i32; 0]).

However, I don't think that you can. Based on some quick play experiments I believe we treat generic types "as if" they were a non-zero-sized field.

Ah, ok, I think I understand now. The point is that we enforce (currently) a rule that says "any ZST must have alignment 1 in a repr(transparent) type" but that rule can be circumvented via generics.

So, the proposed rule is something like. A repr(transparent) type T must meet the following rules:

  • It may have any number of 1-ZST fields
  • In addition, it may have at most one other field of type U

If that other field is present, then T behaves like type U for the purposes of ABIs.

Otherwise it behaves like...? Is there a reason we can't just say ()?

mahkoh

comment created time in 4 days

pull request commentrust-lang/rust

Don't run `resolve_vars_if_possible` in `normalize_erasing_regions`

@lcnr "known" inference variables are indeed what I meant. I guess I don't generally expect that as an invariant from any particular function I imagine that sometimes we wind up substituting or returning things that may reference inference variables that not been fully "resolved" to their known types. I can believe that it's true that in this case that we maintain the invariant, but if so I don't feel like it was intentional (but maybe if I re-read the code I'll realize it has to be that way).

jyn514

comment created time in 4 days

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous

@petrochenkov how difficult would it be to continue supporting this pattern?

jmesmon

comment created time in 4 days

issue commentrust-lang/rust

repr(transparent) on generic type skips "exactly one non-zero-sized field" check

Point of clarification: What is a 1-ZST? A ZST with alignment 1?

mahkoh

comment created time in 4 days

Pull request review commentrust-lang/rust

Fix control flow check for breaking with diverging values

+#![feature(never_type)]++fn loop_break_return() -> i32 {+    let loop_value = loop { break return 0 }; // ok+}++fn loop_break_loop() -> i32 {+    let loop_value = loop { break loop {} }; // ok+}++fn loop_break_break() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break break };+}++fn loop_break_return_2() -> i32 { //~ ERROR mismatched types+    let loop_value = loop { break { return; () } };

Can you change this to break { return 0; () }?

I think in this case I expect // ok, same as break return 0, do you agree?

varkor

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

Add built-in implementations of `Default` for function definition and…

I'm nominating this for discussion in the @rust-lang/lang meeting, this will require sign-off.

Diggsey

comment created time in 4 days

pull request commentrust-lang/rust

impl<A, B> IntoIterator for (A, B) as Zip

As I expressed before, I'm a fan of this change. I really like being able to write for (a, b) in (as, bs) and I am always sad that I cannot.

cuviper

comment created time in 4 days

issue commentrust-lang/rust

regression: could not fully normalize type

Hmm, this may be a distinct problem, but maybe not. Hard to tell.

Mark-Simulacrum

comment created time in 4 days

pull request commentrust-lang/rust

Rename `overlapping_patterns` lint

Nominating to discuss the name in the lang-team meeting.

Nadrieril

comment created time in 4 days

issue openedrust-lang/rust

permit coercion in type ascription

The current implementation of type ascription always equates the type of the expression with the required type (so e: T would force e to have type T). But the original plan was that type ascription would also permit coercions, so that one could do e.g. return x: &dyn Foo and coerce x to the type dyn Foo explicitly.

The challenge is that we can't always permit coercions because that would be unsound. In particular it would cause problems in contexts where references are being created, such as &mut (x: T). This is because the reference that results would actually reference x, since x: T is defined to be a "place expression" just like x is. The problem then is that if the type of x and the type T are not the same, this permits unsoundness:

let mut x: &'static u32 = &22;
let y = 44;
let p = &mut (x:&T); // here we coerce to a shorter lifetime
*p = &y;

The fix proposed in the original RFC was to force coercion to do type equality in reference contexts. But https://github.com/rust-lang/rfcs/pull/2623 proposed a simpler formulation. The idea is this: we already have a notion of coercion contexts where coercion can occur. If we are typing the expression E in a coercion context, and E is an ascription expression E1: T, then we coerce the type of E1 to T.

To implement this, I think the idea would be to intercept the function check_expr_coercable_to_type and look to see if the expression is an ascription expression. If so, we would recursively invoke check_expr_coercable_to_type on the inner expression. This might be kind of a pain in terms of duplicating code, though, so it might be better to thread the info down to check_expr_with_expectation or something like that (maybe add a new kind of Expectation).

created time in 4 days

pull request commentrust-lang/rfcs

RFC: Type Ascribed Coercions

By the way, I think a better example of where this approach might differ from the original RFC would be something like (e: &dyn Foo).bar(), where e: &T and T: Foo. This would not work with this approach because a.b() syntax cannot coerce the type of a. And indeed it probably should not because of &mut self and so forth. I guess it's a bit debatable about whether it would have worked in the older RFC, I would have to look at what we wrote about reference contexts.

haslersn

comment created time in 4 days

pull request commentrust-lang/rfcs

RFC: Type Ascribed Coercions

Er, I meant to add, thanks @haslersn for the suggestion, though, this seems like it is indeed a better approach!

haslersn

comment created time in 4 days

PR closed rust-lang/rfcs

RFC: Type Ascribed Coercions A-ascription A-inference A-typesystem T-lang

Rendered

This improves on the merged RFC 803.

Motivation and summary

The subsection "Type ascription and temporaries" of the merged RFC 803 defines certain contexts (so-called reference contexts) in which a type ascription that needs coercion can not occur. Meanwhile and in contrast, the Rust reference defines coercion sites which are contexts in which a coercion can occur.

For consistency, we change the specification as of RFC 803 such that a type ascribed expression that needs to be coerced can only occur at these coercion sites. The aim is to reduce language complexity and increase consistency.

This change shouldn't in any way conflict with RCF 2522.

+187 -1

8 comments

2 changed files

haslersn

pr closed time in 4 days

pull request commentrust-lang/rfcs

RFC: Type Ascribed Coercions

We discussed this in the backlog bonanza and decided to close the RFC as unnecessary -- this feels like it falls well within the realm of "implementation detail". So what I am going to do is to open a tracking issue that corresponds to this RFC and link it from the type ascription issue as a suggested implementation path.

There are however some doubts within the lang-team about whether the existing type ascription syntax is the right one, as you can see in this recent Zulip thread.

haslersn

comment created time in 4 days

pull request commentrust-lang/rust

Make closures inherit the parent function's target features

@bors r+

LeSeulArtichaut

comment created time in 4 days

PullRequestReviewEvent

issue commentrust-lang/rust

regression: could not fully normalize type

Do we know if removing needs_drop fixes the problem? We also could use an MVCE, right?

Mark-Simulacrum

comment created time in 4 days

pull request commentrust-lang/rust

Revert "Allow dynamic linking for iOS/tvOS targets."

I'm just catching up here -- can someone confirm whether there is a known workaround that works for @francesca64 and @cutsoy?

I realize there are also pending cargo PRs, though I suspect they will take some time to land.

francesca64

comment created time in 4 days

issue commentrust-lang/rust

ICE: tuple_fields called on non-tuple: async fn with unknown macro

Potential fix in https://github.com/sexxi-goose/rust/pull/26

matthiaskrgr

comment created time in 4 days

issue closedrust-lang/compiler-team

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

Proposal

  • Rename ty.kind() and similar methods to ty.data() -- the data method, more generally, would be used to get from the interned thing to data that was interned
  • Rename TyKind to TyData
  • Same for other types

This matches the chalk naming scheme. There are two main advantages:

  • the term Kind also has a meaning in type theory, where it refers to the "kinds" of generic arguments one can have (e.g., types, lifetimes, constants)
  • the term Kind doesn't apply to all the things we would like to intern, such as slices of types and so forth

The eventual goal of extracting a shared type library is that we should be able to work generically with all interned types (to allow for alternative interning schemes), and in that case we need a generic term to access their "data".

Mentors or Reviewers

@leseulartichaut is willing to do the impl work, and @nikomatsakis can review.

Process

The main points of the Major Change Process is as follows:

  • [x] File an issue describing the proposal.
  • [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

closed time in 4 days

nikomatsakis

issue commentrust-lang/compiler-team

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

Given the concerns that were raised and recent discussion in the traits working group, I'm going to close this issue. We're considering two things now:

  • first off, there's a bunch of other work we can pursue, and we can defer this particular change
  • second, we may wish to have data() yield a TyData that is actually corresponding to TyS, and leave TyKind the same
nikomatsakis

comment created time in 4 days

Pull request review commentsexxi-goose/rust

Fix ICE: tuple_fields called on non-tuple: async fn with unknown macro

 where                 // Skip lifetime parameters of the enclosing item(s)                 // Also skip the witness type, because that has no free regions. -                substs.as_generator().tupled_upvars_ty().visit_with(self);+                // We need to shallow resolve to ensure tuple_upvars_ty is of kind Tuple+                // At this point, the kind should not be of type Infer but could potentially+                // be of kind Error+                let ty = self.infcx.shallow_resolve(substs.as_generator().tupled_upvars_ty()); -                for upvar_ty in substs.as_generator().upvar_tys() {-                    upvar_ty.visit_with(self);-                }+                if let ty::Tuple(_) = ty.kind() {

It would be better to write the code more robustly, I think, so that it permits Error or Tuple but not other cases. I suspect the right fix is going to be to modify upvar_tys -- wouldn't we expect ICEs from other callers?

roxelo

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 2742d7146a95df94f85ad241bfcd6f21b74e78dd

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 4 days

pull request commentalumxi22/website

2020 10 event descriptions

OK, I removed the use of find and the changes related to parallel. I left the bash tweaks since CI was testing them and complaining about them. (I still have the changes related to parallel locally, I used them to run just build, since I'm not able to do so without them for some reason.)

Regarding parallel, we could presumably just replace parallel with for loops, too.

nikomatsakis

comment created time in 5 days

push eventalumxi22/website

Niko Matsakis

commit sha 1acbce693e025f4dc675d4673acd3975f30c0a6c

run just build

view details

Niko Matsakis

commit sha 49e358b07ba50800f0081d2149999d6da93476b1

quote shell variables to satisfy lint

view details

Niko Matsakis

commit sha 6dd7e402ef61568b38c875facffe4a3ad2780909

don't write `cat foo | ...` to satisfy lint

view details

push time in 5 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 948466ecd1ad0dfe33620b617e7cd7640b61f429

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 5 days

push eventrust-lang/rustc-dev-guide

Deployment Bot (from Travis CI)

commit sha 5dc6f68716f44b451cb012052de1bddf26d221b0

Deploy rustc-dev-guide.rust-lang.org to github.com/rust-lang/rustc-dev-guide.git:gh-pages

view details

push time in 5 days

pull request commentrust-lang/rfcs

Introduce '$self' macro metavar for hygienic macro items

We discussed this in today's backlog bonanza, but our conclusion was roughly the same as what @withoutboats already wrote some time back:

We are uncertain about allowing access to private members visible to def-site right now; it feels like a bigger addition to macro capabilities than we'd want to make under the 2021 roadmap.

In short, tackling and exposing hygiene feels like a bigger project and one that we don't currently have enough expertise to tackle (and this is basically a hygiene system). Right now @petrochenkov definitely understands that system best, the main problem is that we haven't made much progress in spreading understanding of the current system or documenting how it works. As @petrochenkov noted:

The privacy component of this proposal requires a more significant part of macro 2.0 machinery to be available and stable in the compiler.

and this feels like a decent chunk of work to vet and manage that we'd have to schedule carefully.

There remains some interest in $self (and presumably $super) as nice sugar, though in our conversation we hadn't fully read through the rfc thread yet and so the backwards compatibility issues that @petrochenkov raised were not discussed.

SergioBenitez

comment created time in 5 days

issue openedrust-lang/chalk

add flags to `InternedTy` and `InternedRegion` types

In rustc, we have a "flags" system that propagates information about a type upward and which can be used to shortcircuit a lot of work. The [TypeFlags] propagates various bits. Each time a type is interned, the flags from any subtypes are combined to form the flags for the new interned type. This allows us to do things like skip subtrees that don't contain the sort of thing we are looking for efficiently.

In the meeting today we discussed different ways of doing this. I'll add a comment with more notes.

created time in 6 days

pull request commentrayon-rs/rayon

impl FromParallelIterator for tuple pairs

I see.

cuviper

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrayon-rs/rayon

Add array-based chunks and windows from slices

 pub trait ParallelSlice<T: Sync> {             rem: snd,         }     }++    /// Returns a parallel iterator over `N`-element chunks of+    /// `self` at a time. The chunks do not overlap.+    ///+    /// If `N` does not divide the length of the slice, then the+    /// last up to `N-1` elements will be omitted and can be+    /// retrieved from the remainder function of the iterator.+    ///+    /// # Examples+    ///+    /// ```+    /// use rayon::prelude::*;+    /// let chunks: Vec<_> = [1, 2, 3, 4, 5].par_array_chunks().collect();+    /// assert_eq!(chunks, vec![&[1, 2], &[3, 4]]);+    /// ```+    fn par_array_chunks<const N: usize>(&self) -> ArrayChunks<'_, T, N> {+        assert_ne!(N, 0);+        let slice = self.as_parallel_slice();+        let len = slice.len() / N;+        let (fst, snd) = slice.split_at(len * N);+        // SAFETY: We cast a slice of `len * N` elements into+        // a slice of `len` many `N` elements chunks.+        let array_slice = unsafe {+            let ptr = fst.as_ptr() as *const [T; N];+            ::std::slice::from_raw_parts(ptr, len)+        };

Oof, this is .. clever. I mean it makes sense, but for some reason it was hurting my head, I think because I was thinking of this as a &[&[T]] but of course that's not what we have here, it's a &[[T;N]].

cuviper

comment created time in 6 days

Pull request review commentrayon-rs/rayon

Add array-based chunks and windows from slices

 pub trait ParallelSlice<T: Sync> {         }     } +    /// Returns a parallel iterator over all contiguous array windows of+    /// length `N`. The windows overlap.+    ///+    /// # Examples+    ///+    /// ```+    /// use rayon::prelude::*;+    /// let windows: Vec<_> = [1, 2, 3].par_array_windows().collect();+    /// assert_eq!(vec![&[1, 2], &[2, 3]], windows);+    /// ```+    fn par_array_windows<const N: usize>(&self) -> ArrayWindows<'_, T, N> {

clearly we're not going to land with const N: usize in here, right?

cuviper

comment created time in 6 days

PullRequestReviewEvent

PR closed rayon-rs/rayon

Add env vars for ROUNDS_UNTIL_SLEEPY and ROUNDS_UNTIL_ASLEEP

Running rayon in a rather tight loop can cause very high cpu and power consumption that is not proportional to the amount of work being performed. As documented in the sleep module, this is caused by the work stealing algorithm and workers spinning in a hot loop while looking for work.

This commit adds two environment variables that serve as configuration knobs and allows the user to adjust how aggressive the workers behave.

  • RAYON_ROUNDS_UNTIL_SLEEPY
  • RAYON_ROUNDS_UNTIL_ASLEEP
+16 -8

6 comments

1 changed file

aloucks

pr closed time in 6 days

pull request commentrayon-rs/rayon

Add env vars for ROUNDS_UNTIL_SLEEPY and ROUNDS_UNTIL_ASLEEP

The sleeping code has been completely rewritten by now, so I think we can close this PR. @aloucks have you had a chance to try the new scheduler by the way? Hopefully it is doing a better job when it comes to CPU performance.

aloucks

comment created time in 6 days

pull request commentrayon-rs/rayon

Use structopt instead of docopt

For the record I'm fine with structopt :)

lu-zero

comment created time in 6 days

pull request commentrayon-rs/rayon

impl FromParallelIterator for tuple pairs

@cuviper

The possibility of short-circuiting into Result<(T, U), E> for #801 is particularly motivating.

Can you explain this a bit more? Is that potential future work or did I miss something.

cuviper

comment created time in 6 days

more