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.

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

I'm going to leave this nominated.

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?

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)

Scheduled for Nov 18.

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.

Status update 2020-10-26:

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

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.

Update 2020-10-26:

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

No update this week.

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"

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) { }

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

Again I think specific examples would be useful

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

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

Perf impact looks negligible.

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.

Fix in #78392 (in progress)

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

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

@bors r+

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

@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.)

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.

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)?

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.

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

Merging as this reflects the actual implementation.

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?

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

LGTM.

See this comment

            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.

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

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 ()?

@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).

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

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

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

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

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

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.

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

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

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

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.

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

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.

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.

@bors r+

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

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.

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

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.

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

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?

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.

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.

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.

I see.

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

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

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

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.

For the record I'm fine with structopt :)

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

@iRaiko can you run rustfmt on the result?

I agree that this will be challenging. The first problem as you said is that, in the desugaring, the #[must_use] is being applied to the function that returns the impl Future, and we don't have a clear place where it would be applied to mean "the value awaited by this future". So that's something we'd have to teach the lint somehow.

Second problem then would be that the lint would have to have the idea of a "must use future" (let's call it), and it would have to track when that future is awaited and figure out that the resulting value is itself #[must_use].

I'm pondering if there is a generalization that might make this easier and less special case, not clear.

@rfcbot reviewed