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.

Sign up for GitHub

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

Jump to bottom

32-bit nightlies are not being tested #17344

Closed
alexcrichton opened this issue Sep 17, 2014 · 7 comments
Closed

32-bit nightlies are not being tested #17344

alexcrichton opened this issue Sep 17, 2014 · 7 comments
Labels
P-medium Medium priority

Comments

@alexcrichton
Copy link
Member

The OSX and Linux nightly builders are not testing the 32-bit nightlies because they're only testing the 64-bit nightlies.

The most recent 32-bit cargo builds instantly segfault, which leads me to believe that there may be codegen bugs?
@brson brson self-assigned this Sep 17, 2014
@brson
Copy link
Contributor

brson commented Sep 17, 2014

Let's fix distcheck to test all hosts.

@brson brson mentioned this issue Sep 17, 2014
Closed
65 tasks
@pnkfelix
Copy link
Member

Under the assumption that we will actually manually test the distribution artifacts by hand before releasing 1.0, Felix agrees fixing this infrastructure issue need not block 1.0

P-high, not 1.0 milestone.

@pnkfelix pnkfelix added P-medium Medium priority O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state and removed I-nominated O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state labels Sep 18, 2014
@brson
Copy link
Contributor

brson commented Sep 19, 2014

@alexcrichton distcheck doesn't even test the packaged bins besides a smoke test, though it's true it only tests the build triple, not all hosts.

@brson
Copy link
Contributor

brson commented Sep 19, 2014

Probably the right way to get coverage here is to make make check test all hosts and all targets before packaging.

@brson brson removed their assignment Apr 9, 2015
@steveklabnik
Copy link
Member

@alexcrichton @brson @edunham is this still true today?

@alexcrichton
Copy link
Member Author

Yes, this is still an issue

@brson
Copy link
Contributor

brson commented Jul 14, 2016

Whatever.

@brson brson closed this as completed Jul 14, 2016
lnicola pushed a commit to lnicola/rust that referenced this issue Jun 23, 2024
@regexident
Resolve rust-lang#17344 by using .get(…) instead of […] in `TypeO…
bd5f276 
…rConstParam::source(…)`

(… and `LifetimeParam::source(…)`)
lnicola pushed a commit to lnicola/rust that referenced this issue Jun 23, 2024
@bors
Auto merge of rust-lang#17348 - regexident:fix-type-or-const-param-so…
6e7eecc 
…urce, r=Veykril

Use `.get(…)` instead of `[…]` in `TypeOrConstParam::source(…)` and `LifetimeParam::source(…)`

Resolves rust-lang#17344.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P-medium Medium priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @alexcrichton @brson @pnkfelix