Rework stability annotation pass by petrochenkov · Pull Request #29083 · rust-lang/rust

petrochenkov · 2015-10-15T21:18:40Z

What this patch does:

Stability annotations are now based on "exported items" supplied by rustc_privacy and not "public items". Exported items are as accessible for external crates as directly public items and should be annotated with stability attributes.
Trait impls require annotations now.
Reexports require annotations now.
Crates themselves didn't require annotations, now they do.
Exported macros are annotated now, but these annotations are not used yet.
Some useless annotations are detected and result in errors
Finally, some small bugs are fixed - deprecation propagates from stable deprecated parents, items in blocks are traversed correctly (fixesStability attributes are required for some inaccessible items #29034) + some code cleanup.

rust-highfive · 2015-10-15T21:18:51Z

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2015-10-16T23:48:55Z

Should be good for a rebase now!

petrochenkov · 2015-10-17T03:11:24Z

Rebased.

petrochenkov · 2015-10-17T03:32:39Z

Oh, wait.
Making unstability inherited only from immediate parents was a bad idea after all. This way annotation of trait impls and their items will require huge work. I'll revert it tomorrow.

petrochenkov · 2015-10-17T12:43:37Z

Disregard the previous message. Everything will have to be annotated anyway when libcore root is stabilized. Better not to wait until that moment.

alexcrichton · 2015-10-20T16:46:53Z

I'm a little wary about using exported items because as you've found it's pretty lossy and requires annotating a little too much, but can you elaborate on how it deals with trait items differently? I'm always a little hazy on the difference between public and exported items, but it may just be a bug that trait items aren't listed as public.

alexcrichton · 2015-10-20T16:49:39Z

This is actually intended to be stable (good that this PR caught the bug!), so could you tag it as stable since 1.0.0?

alexcrichton · 2015-10-20T17:04:41Z

Also starting a crater run to see what the impact is (hopefully small!)

alexcrichton · 2015-10-21T00:27:47Z

Crater reports six regressions, 4 of which are legitimate and 2 of which seem unrelated but also legit?

petrochenkov · 2015-10-22T19:45:24Z

Sorry for the delay.

Crater reports six regressions, 4 of which are legitimate and 2 of which seem unrelated but also legit?

4 legitimately regressed crates are on unstable. Unstable Fn::call and Peekable::is_empty were guarded by feature(core), now they are guarded by their own features - fn_call and iter_peekable. I guess it's an acceptable breakage, but it's possible to annotate them with feature(core) to avoid it.

2 unrelated regressions look... completely unrelated.

petrochenkov · 2015-10-22T20:27:24Z

I'm a little wary about using exported items because as you've found it's pretty lossy and requires annotating a little too much, but can you elaborate on how it deals with trait items differently? I'm always a little hazy on the difference between public and exported items, but it may just be a bug that trait items aren't listed as public.

Trait items, impls and impl items are not public, but exported, so they can be left without annotations and therefore lead to "use of unmarked library feature" errors. We don't see these errors now, because the checking pass doesn't look at impls and impl items currently and all trait items have explicit or inherited stability by luck.

The annotation overhead from using exported set is not so serious. It just looks large here, because everything is gathered in one commit. We have approximately 4000 annotated items and only 12 of them are "spurious". Statistically, almost nothing.

On the other hand, it's certainly possible to extend the public set with exported trait items, impls and impl items. In fact, this was the first thing I did! But then I realized three things - 1) after this adjustment public set becomes suspiciously similar to the exported set, 2) I don't actually understand what the public set is supposed to be. 3) I'm still not sure if non-public exported traits (or their items, more importantly) need stability or not. So, I decided not to disrupt the public set with my extra additions, but to use the exported set instead. (It's interesting, that stability annotation pass was actually the only user of the public set besides rustdoc, everything else uses the exported set).

petrochenkov · 2015-10-23T11:23:03Z

In principle, annotation pass can build its own node set, or use exported set for everything except for traits and public set for traits, but it would be additional cruft for little gain, IMO.

petrochenkov · 2015-10-23T16:18:50Z

I'm currently annotating trait impls and various pieces of internal code keep requiring annotations :(
I have an impression now, that extending the public set does make more sense, but not with all exported impls, but only with impls with public trait and self type. Otherwise methods of these impls can't be explicitly called from external code (modulo privacy bugs).

petrochenkov · 2015-10-23T19:51:02Z

Updated with annotations on trait impls.
Okay, now I'm going to extend the public node set and use it to get rid of the annotations on internal items.

petrochenkov · 2015-10-25T02:53:06Z

Blocked on #29291

bors · 2015-10-25T18:35:33Z

☔ The latest upstream changes (presumably #29254) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton

The public set is expanded with trait items, impls and their items, foreign items, exported macros, variant fields, i.e. all the missing parts. Now it's a subset of the exported set. This is needed for #29083 because stability annotation pass uses the public set and all things listed above need to be annotated. Rustdoc can now be migrated to the public set as well, I guess. Exported set is now slightly more correct with regard to exported items in blocks - 1) blocks in foreign items are considered and 2) publicity is not inherited from the block's parent - if a function is public it doesn't mean structures defined in its body are public. r? @alexcrichton or maybe someone else

alexcrichton · 2015-11-03T16:49:07Z

@petrochenkov do you want to rebase this now that #29291 has landed?

petrochenkov · 2015-11-17T22:49:10Z

Updated.

alexcrichton · 2015-11-17T23:05:12Z

@bors: r+ 8357584

bors · 2015-11-18T01:40:34Z

⌛ Testing commit 8357584 with merge aa7132f...

bors · 2015-11-18T02:01:59Z

💔 Test failed - auto-win-gnu-32-opt

petrochenkov · 2015-11-18T10:20:46Z

Updated.

alexcrichton · 2015-11-18T17:18:20Z

@bors: r+ e938e8ea2eaf9093bb92abe25f550a48a4288441

bors · 2015-11-18T17:36:53Z

⌛ Testing commit e938e8e with merge 9514f21...

bors · 2015-11-18T18:06:29Z

💔 Test failed - auto-linux-64-x-android-t

petrochenkov · 2015-11-18T18:17:28Z

Updated.

alexcrichton · 2015-11-18T18:19:24Z

@bors: r+

On Wed, Nov 18, 2015 at 10:17 AM, Vadim Petrochenkov <
notifications@github.com> wrote:

Updated.
—
Reply to this email directly or view it on GitHub
#29083 (comment).

bors · 2015-11-18T18:19:26Z

📌 Commit 64b90f8 has been approved by alexcrichton

What this patch does: - Stability annotations are now based on "exported items" supplied by rustc_privacy and not "public items". Exported items are as accessible for external crates as directly public items and should be annotated with stability attributes. - Trait impls require annotations now. - Reexports require annotations now. - Crates themselves didn't require annotations, now they do. - Exported macros are annotated now, but these annotations are not used yet. - Some useless annotations are detected and result in errors - Finally, some small bugs are fixed - deprecation propagates from stable deprecated parents, items in blocks are traversed correctly (fixes#29034) + some code cleanup.

bors · 2015-11-18T19:49:34Z

⌛ Testing commit 64b90f8 with merge 22e31f1...

bors · 2015-11-18T21:33:32Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

@alexcrichton

This wasn't done in #29083 because attributes weren't parsed on fields of tuple variant back then. r? @alexcrichton

rust-highfive assigned alexcrichton Oct 15, 2015

petrochenkov force-pushed the stability3 branch from 7ea140c to 9fc5634Compare October 17, 2015 03:09

alexcrichton reviewed Oct 20, 2015
View reviewed changes

petrochenkov force-pushed the stability3 branch from 9fc5634 to 0e3941fCompare October 23, 2015 15:21

petrochenkov mentioned this pull request Oct 25, 2015
rustc_privacy: Expand public node set, build exported node set more correctly #29291
Merged

alexcrichton added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Nov 2, 2015

petrochenkov force-pushed the stability3 branch from fcd0029 to 8357584Compare November 17, 2015 22:35

petrochenkov force-pushed the stability3 branch from 8357584 to e938e8eCompare November 18, 2015 10:19

Fix buildbot failures
64b90f8

petrochenkov force-pushed the stability3 branch from e938e8e to 64b90f8Compare November 18, 2015 18:17

bors merged commit 64b90f8 into rust-lang:masterNov 18, 2015

This was referenced Nov 18, 2015
std: Add Instant and SystemTime to std::time #29894
Merged
Store items out-of-line in the HIR #29903
Merged

petrochenkov mentioned this pull request Nov 21, 2015
std::rt::backtrace::write() call triggers "use of unmarked library feature" error/warning #22429
Closed

petrochenkov deleted the stability3 branch November 22, 2015 11:40

petrochenkov mentioned this pull request Nov 25, 2015
Remove #[staged_api]#30015
Merged

petrochenkov referenced this pull request in petrochenkov/rust Dec 14, 2015
Address the review comments
105bd15

petrochenkov mentioned this pull request Jan 14, 2016
Require stability annotations on fields of tuple variants #30898
Merged

bors added a commit that referenced this pull request Jan 15, 2016
Auto merge of#30898- petrochenkov:tvarfstab, r=alexcrichton
e51661b
This wasn't done in #29083 because attributes weren't parsed on fields of tuple variant back then. r? @alexcrichton

Uh oh!

Uh oh!

Conversation

petrochenkov commented Oct 15, 2015

Uh oh!

rust-highfive commented Oct 15, 2015

Uh oh!

alexcrichton commented Oct 16, 2015

Uh oh!

petrochenkov commented Oct 17, 2015

Uh oh!

petrochenkov commented Oct 17, 2015

Uh oh!

petrochenkov commented Oct 17, 2015

Uh oh!

alexcrichton commented Oct 20, 2015

Uh oh!

alexcrichtonOct 20, 2015

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Oct 20, 2015

Uh oh!

alexcrichton commented Oct 21, 2015

Uh oh!

petrochenkov commented Oct 22, 2015

Uh oh!

petrochenkov commented Oct 22, 2015

Uh oh!

petrochenkov commented Oct 23, 2015

Uh oh!

petrochenkov commented Oct 23, 2015

Uh oh!

petrochenkov commented Oct 23, 2015

Uh oh!

petrochenkov commented Oct 25, 2015

Uh oh!

bors commented Oct 25, 2015

Uh oh!

alexcrichton commented Nov 3, 2015

Uh oh!

petrochenkov commented Nov 17, 2015

Uh oh!

alexcrichton commented Nov 17, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

petrochenkov commented Nov 18, 2015

Uh oh!

alexcrichton commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

petrochenkov commented Nov 18, 2015

Uh oh!

alexcrichton commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

bors commented Nov 18, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants