Stream: t-compiler

Topic: #54818 weekly meeting 2018-10-18


pnkfelix (Oct 18 2018 at 13:51, on Zulip):

hey @T-compiler we'll be starting our weekly meeting here in about 10 minutes

pnkfelix (Oct 18 2018 at 14:00, on Zulip):

okay so i was a little overextended today and didn't get a chance to do a prepass

pnkfelix (Oct 18 2018 at 14:00, on Zulip):

But lets see what we have on our plates

pnkfelix (Oct 18 2018 at 14:00, on Zulip):

Our agenda is linked from the topic

pnkfelix (Oct 18 2018 at 14:01, on Zulip):

P-high first

pnkfelix (Oct 18 2018 at 14:01, on Zulip):

from the bottom: "ICE on edition 2018 with anonymous impl lifetime in the wrong place" #52098

pnkfelix (Oct 18 2018 at 14:01, on Zulip):

@nikomatsakis can you put a status update on this issue?

pnkfelix (Oct 18 2018 at 14:01, on Zulip):

(should we reassign it?)

pnkfelix (Oct 18 2018 at 14:02, on Zulip):

oh wait there's a PR

pnkfelix (Oct 18 2018 at 14:02, on Zulip):

#55162

pnkfelix (Oct 18 2018 at 14:02, on Zulip):

okay so that's in hand then

pnkfelix (Oct 18 2018 at 14:03, on Zulip):

next: "Underscore lifetimes are incorrectly accepted as lifetime bounds in impl headers" #54902

nikomatsakis (Oct 18 2018 at 14:03, on Zulip):

sorry sorry

nikomatsakis (Oct 18 2018 at 14:03, on Zulip):

was afk

nikomatsakis (Oct 18 2018 at 14:03, on Zulip):

but...yes there is a PR :)

nikomatsakis (Oct 18 2018 at 14:03, on Zulip):

same PR also covers #54902

pnkfelix (Oct 18 2018 at 14:03, on Zulip):

hmm but github doesn't say so?

nikomatsakis (Oct 18 2018 at 14:04, on Zulip):

the PR says "Fixes #54902" in the description... not sure why GH wouldn't link it

pnkfelix (Oct 18 2018 at 14:04, on Zulip):

nonetheless your description for PR #54902 said so

pnkfelix (Oct 18 2018 at 14:04, on Zulip):

yeah

pnkfelix (Oct 18 2018 at 14:04, on Zulip):

I just don't see the same message from github that "PR #54902 will close this")

pnkfelix (Oct 18 2018 at 14:04, on Zulip):

okay last p-high: "Weird filesystem hierarchy with nested modules" #55094

nikomatsakis (Oct 18 2018 at 14:04, on Zulip):

I've never noticed that before

nikomatsakis (Oct 18 2018 at 14:05, on Zulip):

ok, so, I was planning to investigate this this morning...

pnkfelix (Oct 18 2018 at 14:05, on Zulip):

hmm there's a PR up, assigned to me for review

nikomatsakis (Oct 18 2018 at 14:05, on Zulip):

oh, I hadn't seen that

pnkfelix (Oct 18 2018 at 14:05, on Zulip):

but it failed travis

pnkfelix (Oct 18 2018 at 14:05, on Zulip):

b/c the PR doesn't backwards compatiibly support instances involving #[path], i guess...?

nikomatsakis (Oct 18 2018 at 14:06, on Zulip):

I see ehuss has a number of comments

nikomatsakis (Oct 18 2018 at 14:06, on Zulip):

yeah it's all a big mess

pnkfelix (Oct 18 2018 at 14:06, on Zulip):

I'll assign self to #55094

nikomatsakis (Oct 18 2018 at 14:07, on Zulip):

it sounds like ehuss has explored some of the space

pnkfelix (Oct 18 2018 at 14:07, on Zulip):

yeah I don't know if we're going to need to raise this up to a higher group for discussion

pnkfelix (Oct 18 2018 at 14:07, on Zulip):

and unfortunately I have like zero time between end of this meeting and the lang teasm mtg tonight...

pnkfelix (Oct 18 2018 at 14:07, on Zulip):

(sigh)

nikomatsakis (Oct 18 2018 at 14:08, on Zulip):

I can do that probably

nikomatsakis (Oct 18 2018 at 14:08, on Zulip):

I won't be at the lang team meeting though but I can try to investigate and write up some notes

pnkfelix (Oct 18 2018 at 14:09, on Zulip):

of course another option would be to get someone other than the two of us ...

nikomatsakis (Oct 18 2018 at 14:09, on Zulip):

indeed :)

nikomatsakis (Oct 18 2018 at 14:09, on Zulip):

cc @Taylor Cramer are you around by any chance? Probably @Taylor Cramer doesn't have much time either, but they implemented the "non-mod-rs" file change

pnkfelix (Oct 18 2018 at 14:09, on Zulip):

if anyone from @T-compiler wants to volunteer to investigate #55094 and its associated PR in near term, please feel free to post a note on the issue and/or PR

pnkfelix (Oct 18 2018 at 14:10, on Zulip):

Still, it seems like the P-high's are mostly in hand

pnkfelix (Oct 18 2018 at 14:10, on Zulip):

so lets move along

pnkfelix (Oct 18 2018 at 14:10, on Zulip):

RC2

pnkfelix (Oct 18 2018 at 14:10, on Zulip):

(I suspect @nikomatsakis added this to our regular agenda)

nikomatsakis (Oct 18 2018 at 14:10, on Zulip):

I did :)

pnkfelix (Oct 18 2018 at 14:10, on Zulip):

so there's a bunch of NLL issues here

nikomatsakis (Oct 18 2018 at 14:11, on Zulip):

list without NLL issues

pnkfelix (Oct 18 2018 at 14:11, on Zulip):

Should we skip those here? I suspect mitigating them/reclassifying them should not wait until next NLL meeting

nikomatsakis (Oct 18 2018 at 14:11, on Zulip):

there were two I was not certain about:

pnkfelix (Oct 18 2018 at 14:11, on Zulip):

but I also think we shouldn't get bogged down in them during this meeting

pnkfelix (Oct 18 2018 at 14:12, on Zulip):

so okay lets look at the list niko just postedd

nikomatsakis (Oct 18 2018 at 14:12, on Zulip):

I think you and I can prob triage the NLL ones — we had some discussion in #wg-nll already, I didn't have time to fully follow up on that

pnkfelix (Oct 18 2018 at 14:12, on Zulip):

For "[Rust 2018] rustdoc doesn't link "pub use whatever_crate;"" #52509

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

not clear if imperio will have time or what

pnkfelix (Oct 18 2018 at 14:13, on Zulip):

I'm not really sure if T-compiler can or should do anything here

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

I guess we can live with this

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

I mean, we certainly could :P

pnkfelix (Oct 18 2018 at 14:13, on Zulip):

well okay

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

it seems like it will..probably be backportable

pnkfelix (Oct 18 2018 at 14:13, on Zulip):

I think the other matters are higher priority

pnkfelix (Oct 18 2018 at 14:13, on Zulip):

I vote we either remove T-compiler, or take it off RC2

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

also

nikomatsakis (Oct 18 2018 at 14:13, on Zulip):

the crate is listed

nikomatsakis (Oct 18 2018 at 14:14, on Zulip):

it's just not linked

nikomatsakis (Oct 18 2018 at 14:14, on Zulip):

I think we can take it off of RC2

pnkfelix (Oct 18 2018 at 14:14, on Zulip):

lets do that

nikomatsakis (Oct 18 2018 at 14:14, on Zulip):

it's not a fatal flaw

pnkfelix (Oct 18 2018 at 14:14, on Zulip):

next: "Rustc does not warn about use with paths incompatible with uniform_paths for edition 2018" #53797

nikomatsakis (Oct 18 2018 at 14:15, on Zulip):

@eddyb left some comments there..

pnkfelix (Oct 18 2018 at 14:29, on Zulip):

okay

nikomatsakis (Oct 18 2018 at 14:30, on Zulip):

(for reference, a separate topic was created)

pnkfelix (Oct 18 2018 at 14:30, on Zulip):

(for those looking at log of topic later, I forked off a discussion to topic "#53797 uniform path ambiguity" )

pnkfelix (Oct 18 2018 at 14:30, on Zulip):

:smile:

pnkfelix (Oct 18 2018 at 14:30, on Zulip):

Okay so I think that's all of RC2

eddyb (Oct 18 2018 at 14:31, on Zulip):

it's funny because I'm on the #t-compiler view so I see both topics at once

pnkfelix (Oct 18 2018 at 14:31, on Zulip):

next, beta-nominations

pnkfelix (Oct 18 2018 at 14:31, on Zulip):

it's funny because I'm on the #t-compiler view so I see both topics at once

that's a feature

nikomatsakis (Oct 18 2018 at 14:31, on Zulip):

it's funny because I'm on the #t-compiler view so I see both topics at once

try All Messages ;)

pnkfelix (Oct 18 2018 at 14:32, on Zulip):

first up, "resolve: Scale back hard-coded extern prelude additions on 2015 edition" #54671

Pietro Albini (Oct 18 2018 at 14:32, on Zulip):

fyi, this cycle beta is going to be promoted to stable tomorrow (or the day after), not on monday

pnkfelix (Oct 18 2018 at 14:33, on Zulip):

so #54671 is said to fix #53166

nikomatsakis (Oct 18 2018 at 14:33, on Zulip):

(I approve the backport)

pnkfelix (Oct 18 2018 at 14:33, on Zulip):

does anyone object to the backport?

pnkfelix (Oct 18 2018 at 14:33, on Zulip):

It seems fine to me too

pnkfelix (Oct 18 2018 at 14:34, on Zulip):

marking as beta-accepted

nagisa (Oct 18 2018 at 14:34, on Zulip):

no objections

pnkfelix (Oct 18 2018 at 14:35, on Zulip):

next, "resolve: Do not skip extern prelude during speculative resolution" #55102

pnkfelix (Oct 18 2018 at 14:35, on Zulip):

I don't object to this either.

nikomatsakis (Oct 18 2018 at 14:35, on Zulip):

+1 to backporting, critical bug :)

pnkfelix (Oct 18 2018 at 14:36, on Zulip):

okay, since I don't see anyone voicing an objection to this either, marking as beta-accepted

pnkfelix (Oct 18 2018 at 14:37, on Zulip):

given @Pietro Albini 's note above, it sounds like we may want to prioritize making the beta backports PR

Pietro Albini (Oct 18 2018 at 14:37, on Zulip):

doing it right now :)

pnkfelix (Oct 18 2018 at 14:37, on Zulip):

oh great

pnkfelix (Oct 18 2018 at 14:38, on Zulip):

okay, that's all the beta-nominations

pnkfelix (Oct 18 2018 at 14:38, on Zulip):

(at least, the ones that were not already marked beta-accepted)

pnkfelix (Oct 18 2018 at 14:38, on Zulip):

next up: stable-nominations

pnkfelix (Oct 18 2018 at 14:38, on Zulip):

nada there

pnkfelix (Oct 18 2018 at 14:38, on Zulip):

next: all stable-to-beta regressions: https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta

pnkfelix (Oct 18 2018 at 14:39, on Zulip):

"[1.30 beta] Test suite of the jemalloc-ctl crate is failing" #54478 has a fix that I believe is part of the aforementioned backport

pnkfelix (Oct 18 2018 at 14:39, on Zulip):

next: "[1.30 beta] Compiler hangs when compiling primal crate for armv7-apple-ios" #54627

pnkfelix (Oct 18 2018 at 14:40, on Zulip):

@nagisa had various notes and filed an LLVM bug

nagisa (Oct 18 2018 at 14:40, on Zulip):

I’ve filled an LLVM bug and have given a "viable workaround"

nagisa (Oct 18 2018 at 14:40, on Zulip):

not planning to put in any time into making an LLVM fix any time soon, though.

pnkfelix (Oct 18 2018 at 14:40, on Zulip):

as in, turning debug-assertions off ?

pnkfelix (Oct 18 2018 at 14:40, on Zulip):

(or optimizations off)

nagisa (Oct 18 2018 at 14:40, on Zulip):

yes. Stuff will still fail if an overflowing operation is used explicitly, though.

pnkfelix (Oct 18 2018 at 14:41, on Zulip):

Sounds like we just cannot fix this. Okay.

nikomatsakis (Oct 18 2018 at 14:42, on Zulip):

seems obscure enough that the workaround suffices for now

nikomatsakis (Oct 18 2018 at 14:42, on Zulip):

thanks @nagisa, nice job

Pietro Albini (Oct 18 2018 at 14:42, on Zulip):

also I don't think ios is a tier 1 platform

nagisa (Oct 18 2018 at 14:43, on Zulip):

This affects all 32-bit ARM targets to the best of my knowledge.

pnkfelix (Oct 18 2018 at 14:43, on Zulip):

I left a comment. I don't know if there's any relevant labels to change. Probably not.

pnkfelix (Oct 18 2018 at 14:43, on Zulip):

Next up: "Regression from stable: pointer to usize conversion no longer compiles" #54709

nagisa (Oct 18 2018 at 14:43, on Zulip):

FCP to close in progress.

nikomatsakis (Oct 18 2018 at 14:43, on Zulip):

(and looks non-controversial)

oli (Oct 18 2018 at 14:43, on Zulip):

accidental stabilization being fixed

pnkfelix (Oct 18 2018 at 14:44, on Zulip):

yep

pnkfelix (Oct 18 2018 at 14:44, on Zulip):

okay lets move along then

pnkfelix (Oct 18 2018 at 14:45, on Zulip):

that was the last stable-to-beta regression

pnkfelix (Oct 18 2018 at 14:45, on Zulip):

next: stable-to-nightly regressions: https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly

pnkfelix (Oct 18 2018 at 14:45, on Zulip):

only one, "Rustc panics on nightly with crate interpolate" #54654

pnkfelix (Oct 18 2018 at 14:45, on Zulip):

d'oh, assigned to me

pnkfelix (Oct 18 2018 at 14:45, on Zulip):

I've had no time

pnkfelix (Oct 18 2018 at 14:46, on Zulip):

anyone else want to work-steal it?

pnkfelix (Oct 18 2018 at 14:46, on Zulip):

(if so, just assign yourself and unassign me.) For now, I'll just leave myself assigned.

pnkfelix (Oct 18 2018 at 14:46, on Zulip):

Still need to even figure out if this should be P-high or what...

pnkfelix (Oct 18 2018 at 14:47, on Zulip):

next up: Waiting for our team

oli (Oct 18 2018 at 14:47, on Zulip):

I put it into my queue

pnkfelix (Oct 18 2018 at 14:47, on Zulip):

from the bottom: "Correct alignment of atomic types and (re)add Atomic{I,U}128" #53514

pnkfelix (Oct 18 2018 at 14:48, on Zulip):

@nagisa 's summary comment is here (thanks @nagisa !!)

nagisa (Oct 18 2018 at 14:48, on Zulip):

There is some controversy on minor points of said summary comment

nagisa (Oct 18 2018 at 14:49, on Zulip):

I myself am very partial to making #[repr(transparent, align(x))] possible.

nikomatsakis (Oct 18 2018 at 14:49, on Zulip):

I was just reading your comment @nagisa... very thorough, nice.

eddyb (Oct 18 2018 at 14:49, on Zulip):

so the alignment would apply in-memory but the by-value ABI would be the same as that of the inner type?

pnkfelix (Oct 18 2018 at 14:49, on Zulip):

I myself am very partial to making #[repr(transparent, align(x))] possible.

so we currently cannot express this?

nagisa (Oct 18 2018 at 14:50, on Zulip):

@eddyb I expect it to work the same as the C's typedef mytype inner __attribute__((align(x)) (with whatever the order in C is the right one)

nagisa (Oct 18 2018 at 14:52, on Zulip):

To my knowledge we cannot. I should probably write up an RFC to allow it.

pnkfelix (Oct 18 2018 at 14:52, on Zulip):

I myself am very partial to making #[repr(transparent, align(x))] possible.

or did this mean "we can express it, but it does not currently suffice as a solution. You want it to suffice as a solution" ?

nagisa (Oct 18 2018 at 14:52, on Zulip):

Nah, it fails during compilation with error[E0692]: transparent struct cannot have other repr hints

pnkfelix (Oct 18 2018 at 14:52, on Zulip):

okay I see. @rkruppe s comments make a little more sense to me now

pnkfelix (Oct 18 2018 at 14:53, on Zulip):

So it seems like @rkruppe is aruging that ... #[repr(C)] should suffice here...? Is that true?

nagisa (Oct 18 2018 at 14:54, on Zulip):

#[repr(C, align(X))] should, I think

pnkfelix (Oct 18 2018 at 14:54, on Zulip):

or okay, @RalfJ says #[repr(C, align(X))]

pnkfelix (Oct 18 2018 at 14:54, on Zulip):

what's the drawback of using that instead of going all the way to #[repr(transparent, align(X))] ?

nagisa (Oct 18 2018 at 14:54, on Zulip):

unless there’s some sort of way that repr(C) could end up not laying out its first field at offset 0.

nikomatsakis (Oct 18 2018 at 14:55, on Zulip):

(woah, GCC supports .. typedef uint8_t more_aligned_uint8_t __attribute__ ((aligned (2)));? sort of "structural alignment types"? wacky.)

nagisa (Oct 18 2018 at 14:56, on Zulip):

I’m up for trying repr(C, align(X)) with intent of having a fix soon

eddyb (Oct 18 2018 at 14:56, on Zulip):

@nikomatsakis I kinda wanted #[repr(align(64))] [u8; 64] for a while :P

pnkfelix (Oct 18 2018 at 14:56, on Zulip):

Okay can we maybe try to move forward that way (with #[repr(C, align(X))])? I guess we are worried about breakage from removing the recently added #[repr(transparent)] ??

nagisa (Oct 18 2018 at 14:56, on Zulip):

but I cannot with clear conscience claim that it will work in all cases because I’m not sure if repr(C) will lay out the first field at offset 0

eddyb (Oct 18 2018 at 14:57, on Zulip):

type u32x4 = #[repr(simd)] [u32; 4]; etc.

pnkfelix (Oct 18 2018 at 14:57, on Zulip):

I see

eddyb (Oct 18 2018 at 14:57, on Zulip):

repr(C) always lays the first field at offset 0

nagisa (Oct 18 2018 at 14:57, on Zulip):

then it should be fine.

eddyb (Oct 18 2018 at 14:57, on Zulip):

it might even be guaranteed by the C standard, but at least all ABIs we support do it

pnkfelix (Oct 18 2018 at 14:58, on Zulip):

@nagisa can you take point on moving forward with this then? Which may mean just asking ollie to adopt this variation?

nagisa (Oct 18 2018 at 14:58, on Zulip):

Yeah sure.

pnkfelix (Oct 18 2018 at 14:58, on Zulip):

Great!

nikomatsakis (Oct 18 2018 at 14:58, on Zulip):

I have to say I found @rkruppe's arguments persuasive

nikomatsakis (Oct 18 2018 at 14:58, on Zulip):

but I guess we can discuss on thread

eddyb (Oct 18 2018 at 14:58, on Zulip):

removing #[repr(transparent)] could technically be breakage if anyone is passing those types by value in FFI but that's about it

eddyb (Oct 18 2018 at 14:58, on Zulip):

(and using a non-struct type on the other side)

eddyb (Oct 18 2018 at 14:59, on Zulip):

that's sort of the guarantee we provide by slapping it onto a Rust type. for memory-only layout guarantees, use #[repr(C)] instead

pnkfelix (Oct 18 2018 at 14:59, on Zulip):

I'm going to remove the blocked-on label at this point

pnkfelix (Oct 18 2018 at 15:00, on Zulip):

next: "Report const eval error inside the query" #53821

pnkfelix (Oct 18 2018 at 15:00, on Zulip):

its in FCP

pnkfelix (Oct 18 2018 at 15:00, on Zulip):

I'm going to remove the waiting-on-team label from this too

nikomatsakis (Oct 18 2018 at 15:00, on Zulip):

(I'm going to have to drop out, will catch up on the backlog)

pnkfelix (Oct 18 2018 at 15:01, on Zulip):

last waiting-on-team issue is "Support for the program data address space option of LLVM's Target Datalayout" #54993

eddyb (Oct 18 2018 at 15:01, on Zulip):

oh wow, a weird address space target that's not a GPU

pnkfelix (Oct 18 2018 at 15:01, on Zulip):

but since @nikomatsakis just dropped off, I think we should just wait until next week to discuss this. (Or discuss it on threaD)

eddyb (Oct 18 2018 at 15:02, on Zulip):

this is genuinely refreshing (cc @rkruppe )

pnkfelix (Oct 18 2018 at 15:02, on Zulip):

Okay as usual we are out of time before we can address the I-nominated issues

pnkfelix (Oct 18 2018 at 15:02, on Zulip):

/me wonders if maybe we should somewhat permute the agenda each week to avoid this regular recurrence)

pnkfelix (Oct 18 2018 at 15:03, on Zulip):

Thanks everyone for coming!

nagisa (Oct 18 2018 at 15:04, on Zulip):

@eddyb you could take every ARM MCU and call it something with multiple address spaces

nagisa (Oct 18 2018 at 15:05, on Zulip):

those just happen to be mapped into a global address space for reasons.

nagisa (Oct 18 2018 at 15:05, on Zulip):

heck, not even.

eddyb (Oct 18 2018 at 15:05, on Zulip):

yeah but that's not the same thing as what's exposed to LLVM

nagisa (Oct 18 2018 at 15:05, on Zulip):

the ARM MCU I work on has… 3 address spaces… 2 of which replace the "code memory" when a certain switch is flipped.

nagisa (Oct 18 2018 at 15:07, on Zulip):

so yeaaaaah…

Taylor Cramer (Oct 18 2018 at 15:24, on Zulip):

@nikomatsakis @pnkfelix hey, sorry I wasn't around-- I can investigate "Weird filesystem hierarchy with nested modules" #55094

nikomatsakis (Oct 18 2018 at 17:43, on Zulip):

@Taylor Cramer that'd be awesome

Last update: Nov 22 2019 at 04:30UTC