Skip to content

64-bit OS X support #96

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

Closed
adamv opened this issue Jul 8, 2010 · 2 comments
Closed

64-bit OS X support #96

adamv opened this issue Jul 8, 2010 · 2 comments

Comments

@adamv
Copy link

adamv commented Jul 8, 2010

To determine if OS X is running on a 64-bit box, Homebrew uses:
/usr/sbin/sysctl hw.cpu64bit_capable

We also figure out if we're 10.5 or 10.6 with:
/usr/bin/sw_vers -productVersion

Many of our brews then switch to 64-bit mode if we're on 10.6 (or later) and 64-bit capable, otherwise, on 10.5 or a Core Duo we switch to 32-bit mode.

@msullivan
Copy link
Contributor

I'm not sure what the bug here is? Is it just that we don't support 64-bit yet?

@adamv
Copy link
Author

adamv commented Jul 8, 2011

I honestly don't remember; closing.

@adamv adamv closed this as completed Jul 8, 2011
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
* Enable multiple #[assert_instr] attributes

Looks like all we needed to do was generate new function names!

* Uncomment assertions for `_mm_prefetch`
flip1995 pushed a commit to flip1995/rust that referenced this issue May 15, 2020
…flip1995

Reversed empty ranges

This lint checks range expressions with inverted limits which result in empty ranges. This includes also the ranges used to index slices.

The lint reverse_range_loop was covering iteration of reversed ranges in a for loop, which is a subset of what this new lint covers, so it has been removed. I'm not sure if that's the best choice. It would be doable to check in the new lint that we are not in the arguments of a for loop; I went for removing it because the logic was too similar to keep them separated.

changelog: Added reversed_empty_ranges lint that checks for ranges where the limits have been inverted, resulting in empty ranges. Removed reverse_range_loop which was covering a subset of the new lint.

Closes rust-lang#4192
Closes rust-lang#96
eddyb pushed a commit to eddyb/rust that referenced this issue Jun 30, 2020
bors pushed a commit to rust-lang-ci/rust that referenced this issue Oct 1, 2021
djtech-dev pushed a commit to djtech-dev/rust that referenced this issue Dec 9, 2021
fix misuse of LLVM API found through inkwell tests
jaisnan pushed a commit to jaisnan/rust-dev that referenced this issue Oct 15, 2024
…ed_shl` and `unchecked_shr` (rust-lang#96)

Towards : issue rust-lang#59 

Parent branch :
[c-0011-core-nums-yenyunw-unsafe-ints](https://github.com/rajathkotyal/verify-rust-std/tree/c-0011-core-nums-yenyunw-unsafe-ints
) - Tracking PR rust-lang#91

---------

Co-authored-by: yew005 <[email protected]>
Co-authored-by: MWDZ <[email protected]>
Co-authored-by: Lanfei Ma <[email protected]>
Co-authored-by: Yenyun035 <[email protected]>
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 8, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 14, 2025
…gross35

Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it

tracking issue: rust-lang#138997

Per rust-lang#134213 (comment), we want to make the `#[naked]` attribute an unsafe attribute. Making that change runs into a cyclic dependency with `compiler-builtins` which uses `#[naked]`, where `rustc` needs an updated `compiler-builtins` and vice versa.

So based on rust-lang#139753 and [#t-compiler/help > updating &rust-lang#96;compiler-builtins&rust-lang#96; and &rust-lang#96;rustc&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/updating.20.60compiler-builtins.60.20and.20.60rustc.60), this PR allows, but does not require `#[unsafe(naked)]`, and makes that change for some of the tests to check that both `#[naked]` and `#[unsafe(naked)]` are accepted.

Then we can upgrade and synchronize `compiler-builtins`, and then make `#[naked]` (without `unsafe`) invalid.

r? `@traviscross` (or someone from t-compiler if you're faster and this look allright)
Zalathar added a commit to Zalathar/rust that referenced this issue Apr 15, 2025
…gross35

Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it

tracking issue: rust-lang#138997

Per rust-lang#134213 (comment), we want to make the `#[naked]` attribute an unsafe attribute. Making that change runs into a cyclic dependency with `compiler-builtins` which uses `#[naked]`, where `rustc` needs an updated `compiler-builtins` and vice versa.

So based on rust-lang#139753 and [#t-compiler/help > updating &rust-lang#96;compiler-builtins&rust-lang#96; and &rust-lang#96;rustc&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/updating.20.60compiler-builtins.60.20and.20.60rustc.60), this PR allows, but does not require `#[unsafe(naked)]`, and makes that change for some of the tests to check that both `#[naked]` and `#[unsafe(naked)]` are accepted.

Then we can upgrade and synchronize `compiler-builtins`, and then make `#[naked]` (without `unsafe`) invalid.

r? ``@traviscross`` (or someone from t-compiler if you're faster and this look allright)
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 15, 2025
Rollup merge of rust-lang#139797 - folkertdev:naked-allow-unsafe, r=tgross35

Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it

tracking issue: rust-lang#138997

Per rust-lang#134213 (comment), we want to make the `#[naked]` attribute an unsafe attribute. Making that change runs into a cyclic dependency with `compiler-builtins` which uses `#[naked]`, where `rustc` needs an updated `compiler-builtins` and vice versa.

So based on rust-lang#139753 and [#t-compiler/help > updating &rust-lang#96;compiler-builtins&rust-lang#96; and &rust-lang#96;rustc&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/updating.20.60compiler-builtins.60.20and.20.60rustc.60), this PR allows, but does not require `#[unsafe(naked)]`, and makes that change for some of the tests to check that both `#[naked]` and `#[unsafe(naked)]` are accepted.

Then we can upgrade and synchronize `compiler-builtins`, and then make `#[naked]` (without `unsafe`) invalid.

r? `@traviscross` (or someone from t-compiler if you're faster and this look allright)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 17, 2025
Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test`

### Summary

Add a semantically meaningful directive for ignoring test *auxiliary* files. This is for auxiliary files that *participate* in actual tests but should not be built by `compiletest` (i.e. these files are involved through `mod xxx;` or `include!()` or `#[path = "xxx"]`, etc.).

### Motivation

A specialized directive like `//@ ignore-auxiliary` makes it way easier to audit disabled tests via `//@ ignore-test`.
  - These support files cannot use the canonical `auxiliary/` dir because they participate in module resolution or are included, or their relative paths can be important for test intention otherwise.

Follow-up to:
- rust-lang#139705
- rust-lang#139783
- rust-lang#139740

See also discussions in:

- [#t-compiler > Directive name for non-test aux files?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Directive.20name.20for.20non-test.20aux.20files.3F/with/512773817)
- [#t-compiler > Handling disabled &rust-lang#96;//@ ignore-test&rust-lang#96; tests](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Handling.20disabled.20.60.2F.2F.40.20ignore-test.60.20tests/with/512005974)
- [#t-compiler/meetings > &rust-lang#91;steering&rust-lang#93; 2025-04-11 Dealing with disabled tests](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/511717981)

### Remarks on remaining unconditionally disabled tests under `tests/`

After this PR, against commit 79a272c, only **14** remaining test files are disabled through `//@ ignore-test`:

<details>
<summary>Remaining `//@ ignore-test` files under `tests/`</summary>

```
tests/debuginfo/drop-locations.rs
4://@ ignore-test (broken, see rust-lang#128971)

tests/rustdoc/macro-document-private-duplicate.rs
1://@ ignore-test (fails spuriously, see issue rust-lang#89228)

tests/rustdoc/inline_cross/assoc-const-equality.rs
3://@ ignore-test (FIXME: rust-lang#125092)

tests/ui/match/issue-27021.rs
7://@ ignore-test (rust-lang#54987)

tests/ui/match/issue-26996.rs
7://@ ignore-test (rust-lang#54987)

tests/ui/issues/issue-49298.rs
9://@ ignore-test (rust-lang#54987)

tests/ui/issues/issue-59756.rs
2://@ ignore-test (rustfix needs multiple suggestions)

tests/ui/precondition-checks/write.rs
5://@ ignore-test (unimplemented)

tests/ui/precondition-checks/read.rs
5://@ ignore-test (unimplemented)

tests/ui/precondition-checks/write_bytes.rs
5://@ ignore-test (unimplemented)

tests/ui/explicit-tail-calls/drop-order.rs
2://@ ignore-test: tail calls are not implemented in rustc_codegen_ssa yet, so this causes 🧊

tests/ui/panics/panic-short-backtrace-windows-x86_64.rs
3://@ ignore-test (rust-lang#92000)

tests/ui/json/json-bom-plus-crlf-multifile-aux.rs
3://@ ignore-test Not a test. Used by other tests

tests/ui/traits/next-solver/object-soundness-requires-generalization.rs
2://@ ignore-test (see rust-lang#114196)
```
</details>

Of these, most are either **unimplemented**, or **spurious**, or **known-broken**. The outstanding one is `tests/ui/json/json-bom-plus-crlf-multifile-aux.rs` which I did not want to touch in *this* PR -- that aux file has load-bearing BOM and carriage returns and byte offset matters. I think those test files that require special encoding / BOM probably are better off as `run-make` tests. See rust-lang#139968 for that aux file.

### Review advice

- Best reviewed commit-by-commit.
- The directive name diverged from the most voted `//@ auxiliary` because I think that's easy to confuse with `//@ aux-{crate,dir}`.

r? compiler
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 18, 2025
Rollup merge of rust-lang#139967 - jieyouxu:auxiliary, r=wesleywiser

Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test`

### Summary

Add a semantically meaningful directive for ignoring test *auxiliary* files. This is for auxiliary files that *participate* in actual tests but should not be built by `compiletest` (i.e. these files are involved through `mod xxx;` or `include!()` or `#[path = "xxx"]`, etc.).

### Motivation

A specialized directive like `//@ ignore-auxiliary` makes it way easier to audit disabled tests via `//@ ignore-test`.
  - These support files cannot use the canonical `auxiliary/` dir because they participate in module resolution or are included, or their relative paths can be important for test intention otherwise.

Follow-up to:
- rust-lang#139705
- rust-lang#139783
- rust-lang#139740

See also discussions in:

- [#t-compiler > Directive name for non-test aux files?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Directive.20name.20for.20non-test.20aux.20files.3F/with/512773817)
- [#t-compiler > Handling disabled &rust-lang#96;//@ ignore-test&rust-lang#96; tests](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Handling.20disabled.20.60.2F.2F.40.20ignore-test.60.20tests/with/512005974)
- [#t-compiler/meetings > &rust-lang#91;steering&rust-lang#93; 2025-04-11 Dealing with disabled tests](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/511717981)

### Remarks on remaining unconditionally disabled tests under `tests/`

After this PR, against commit 79a272c, only **14** remaining test files are disabled through `//@ ignore-test`:

<details>
<summary>Remaining `//@ ignore-test` files under `tests/`</summary>

```
tests/debuginfo/drop-locations.rs
4://@ ignore-test (broken, see rust-lang#128971)

tests/rustdoc/macro-document-private-duplicate.rs
1://@ ignore-test (fails spuriously, see issue rust-lang#89228)

tests/rustdoc/inline_cross/assoc-const-equality.rs
3://@ ignore-test (FIXME: rust-lang#125092)

tests/ui/match/issue-27021.rs
7://@ ignore-test (rust-lang#54987)

tests/ui/match/issue-26996.rs
7://@ ignore-test (rust-lang#54987)

tests/ui/issues/issue-49298.rs
9://@ ignore-test (rust-lang#54987)

tests/ui/issues/issue-59756.rs
2://@ ignore-test (rustfix needs multiple suggestions)

tests/ui/precondition-checks/write.rs
5://@ ignore-test (unimplemented)

tests/ui/precondition-checks/read.rs
5://@ ignore-test (unimplemented)

tests/ui/precondition-checks/write_bytes.rs
5://@ ignore-test (unimplemented)

tests/ui/explicit-tail-calls/drop-order.rs
2://@ ignore-test: tail calls are not implemented in rustc_codegen_ssa yet, so this causes 🧊

tests/ui/panics/panic-short-backtrace-windows-x86_64.rs
3://@ ignore-test (rust-lang#92000)

tests/ui/json/json-bom-plus-crlf-multifile-aux.rs
3://@ ignore-test Not a test. Used by other tests

tests/ui/traits/next-solver/object-soundness-requires-generalization.rs
2://@ ignore-test (see rust-lang#114196)
```
</details>

Of these, most are either **unimplemented**, or **spurious**, or **known-broken**. The outstanding one is `tests/ui/json/json-bom-plus-crlf-multifile-aux.rs` which I did not want to touch in *this* PR -- that aux file has load-bearing BOM and carriage returns and byte offset matters. I think those test files that require special encoding / BOM probably are better off as `run-make` tests. See rust-lang#139968 for that aux file.

### Review advice

- Best reviewed commit-by-commit.
- The directive name diverged from the most voted `//@ auxiliary` because I think that's easy to confuse with `//@ aux-{crate,dir}`.

r? compiler
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants