Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of RFC2867 #76260

Merged
merged 2 commits into from
Oct 9, 2020
Merged

Implementation of RFC2867 #76260

merged 2 commits into from
Oct 9, 2020

Conversation

xd009642
Copy link
Contributor

@xd009642 xd009642 commented Sep 2, 2020

#74727

So I've started work on this, I think my next steps are to make use of the instruction_set value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next 😄

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 2, 2020
@jonas-schievink jonas-schievink added the O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state label Sep 2, 2020
@ketsuban
Copy link
Contributor

ketsuban commented Sep 6, 2020

I think at minimum the following targets will also need has_thumb_interworking set to true.

  • armv5te-unknown-linux-gnueabi
  • armv5te-unknown-linux-musleabi
  • thumbv4t-none-eabi

Someone who knows about platforms supporting ARMv6 and ARMv7 will have to sort through the rest. (@jonas-schievink?)

src/librustc_codegen_llvm/attributes.rs Outdated Show resolved Hide resolved
src/librustc_typeck/collect.rs Outdated Show resolved Hide resolved
src/librustc_typeck/collect.rs Outdated Show resolved Hide resolved
@xd009642
Copy link
Contributor Author

xd009642 commented Sep 7, 2020

Responded to feedback, also aimed to improve some of the error messages in collect.rs

Copy link
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good now! Some tests should be added though (and some manual testing is probably useful too)

src/librustc_typeck/collect.rs Outdated Show resolved Hide resolved
src/librustc_typeck/collect.rs Outdated Show resolved Hide resolved
src/librustc_typeck/collect.rs Outdated Show resolved Hide resolved
@xd009642
Copy link
Contributor Author

xd009642 commented Sep 7, 2020

@jonas-schievink where should I look to for examples of tests in the code base covering similar areas?

@jonas-schievink
Copy link
Contributor

I think for the initial version of this, it's enough to check that the attribute is accepted and rejected correctly. For that, you can write UI tests in src/test/ui/instruction-set. You can check https://rustc-dev-guide.rust-lang.org/tests/adding.html for details.

@jonas-schievink
Copy link
Contributor

Oh, I also suggest rebasing this PR to fix the merge conflicts, then CI can run tests for you.

@bors

This comment has been minimized.

@xd009642
Copy link
Contributor Author

xd009642 commented Sep 9, 2020

@jonas-schievink So I started working on the tests and after seeing CI fail started running the tests locally. I'm just wondering if there's a way to run them for a different architecture? Otherwise I'll just get the architecture doesn't support instruction_set errors. I see there's also some ui tests with ignore-arm etc at the top of the test file - is there any documentation on what comments are available to change when a test is ran or not?

@rust-log-analyzer

This comment has been minimized.

@xd009642
Copy link
Contributor Author

@jonas-schievink I'd like to try and get this sorted by this week if possible but I might need some help with the UI tests to figure out how to get them to just run with the intended architectures.. Also should I add a UI test to just run with intel so I can get the error message for arch doesn't support instruction_set 🤔 (I think yes so I'll probably just start that soon-ish)

@rust-log-analyzer

This comment has been minimized.

@xd009642 xd009642 marked this pull request as ready for review September 14, 2020 21:33
@@ -0,0 +1,11 @@
// only-armv4t-unknown-linux-gnueabi
// only-armv5te-unknown-linux-gnueabi
// only-armv5te-unknown-linux-musleabi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure you can stack only like that?
I recall it did not work and tests like that have been changed to use different conditions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea, I couldn't really find any documentation on how the comments worked and figured it was worth trying before writing the mass of ignore-* I'd need to do to run using just those 3 architectures

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Judging by the comment it won't run this test on any target:

// we should check if any only-<platform> exists and if it exists

@xd009642
Copy link
Contributor Author

So I guess I need to add ignore- for everything not armv4 or armv5 then, unless there's an easier way?

@mati865
Copy link
Contributor

mati865 commented Sep 15, 2020

I don't know how to solve it and have very limited search ability on the mobile.

@xd009642
Copy link
Contributor Author

@mati865 okay thanks for the pointer though, I'll try the ignores at some point later, just trying to get the CI to the point of running those tests first 😬

@@ -0,0 +1,35 @@
// ignore-aarch64
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jonas-schievink @mati865 I don't know if either of you have time to have a look at this. But I can't figure out all the ignores I need to stop this running on architectures other than the arm v4 and v5 targets

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be fine to just run it on one of the Arm architectures

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that would make things easier, I was trying to test on all relevant arm targets

@rust-log-analyzer

This comment has been minimized.

@bors

This comment has been minimized.

@jyn514
Copy link
Member

jyn514 commented Oct 7, 2020

I've just been doing ./x.py test

You can make this take less time with x.py test src/tools/error_index_generator src/test/ui/error-codes. I don't recommend running all 10k tests every time.

@xd009642
Copy link
Contributor Author

xd009642 commented Oct 7, 2020

yeah I tried doing filtering on them like with cargo test but that didn't seem to work. It wasn't so bad when it failed early on 😅.

So the current error_code doctest issue is to do with the architecture it's ran on not supporting arm:a32 or arm::t32. I'll add a cfg_attr to it so it works. But do you want it to encompass all the targets it works on, or just pick one of them? And also should I mention which targets do support it or just leave that off because it's discoverable elsewhere i.e. the tracking issue?

@jyn514
Copy link
Member

jyn514 commented Oct 7, 2020

I'm not the person to ask, but #76260 (comment) sounds like only one target is fine.

should I mention which targets do support it

This seems like the list could grow a lot over time - maybe point to the tracking issue instead?

@xd009642
Copy link
Contributor Author

xd009642 commented Oct 8, 2020

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@jyn514
Copy link
Member

jyn514 commented Oct 8, 2020

r? @jonas-schievink

compiler/rustc_middle/src/middle/codegen_fn_attrs.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Show resolved Hide resolved
@xd009642
Copy link
Contributor Author

xd009642 commented Oct 8, 2020

@jonas-schievink all the feedback should be addressed now 👍

@jonas-schievink
Copy link
Contributor

Awesome! Will approve once CI passes

@jyn514
Copy link
Member

jyn514 commented Oct 8, 2020

@xd009642 do you mind squashing the commit history a little? 52 commits is a lot 😅

@jyn514
Copy link
Member

jyn514 commented Oct 8, 2020

There are instructions at https://rustc-dev-guide.rust-lang.org/git.html#rebasing

@xd009642
Copy link
Contributor Author

xd009642 commented Oct 8, 2020

Yeah I can do that tomorrow morning 👍

@jyn514
Copy link
Member

jyn514 commented Oct 8, 2020

gazes longingly at rust-lang/triagebot#821

@xd009642
Copy link
Contributor Author

xd009642 commented Oct 8, 2020

@jonas-schievink @jyn514 squashed and I fixed the mistake in the stderr post case fix. Just couldn't wait until tomorrow 😄

@jyn514
Copy link
Member

jyn514 commented Oct 8, 2020

@bors r=jonas-schievink

@bors
Copy link
Contributor

bors commented Oct 8, 2020

📌 Commit bdb3f77 has been approved by jonas-schievink

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2020
@bors
Copy link
Contributor

bors commented Oct 9, 2020

⌛ Testing commit bdb3f77 with merge 03ef8a0...

@bors
Copy link
Contributor

bors commented Oct 9, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: jonas-schievink
Pushing 03ef8a0 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.