64-bit OS X support #96
Comments
|
I'm not sure what the bug here is? Is it just that we don't support 64-bit yet? |
|
I honestly don't remember; closing. |
keeperofdakeys
pushed a commit
to keeperofdakeys/rust
that referenced
this issue
Dec 12, 2017
SysV shared memory APIs
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
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 1, 2021
Reduce wasm test suite
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
handle precompiled compiler more properly Fixes the build cycle problem reported on [#t-infra/bootstrap > Cycle on &rust-lang#96;aarch64-apple&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Cycle.20on.20.60aarch64-apple.60/with/504231609).
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
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jun 9, 2025
Remap compiler vs non-compiler sources differently (bootstrap side) See [#t-compiler/help > Span pointing to wrong file location (&rust-lang#96;rustc-dev&rust-lang#96; component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083). The path remapping and unremapping for compiler sources (distributed via `rustc-dev` dist component) is broken because bootstrap currently remaps all sources unconditionally (if remapping is enabled) to the `/rustc/{hash}` form. However, the `rustc-dev` dist component (compiler sources) and `rust-src` dist component (library sources) unpacks differently: - `rust-src` unpacks sources to a path like `$sysroot/lib/rustlib/src/rust`, whereas - `rustc-dev` unpacks sources to a path like `$sysroot/lib/rustlib/rustc-src/rust`[^note], meaning that the compiler need to unremap them differently. But the same remapping means that the compiler has no way to distinguish between compiler and non-compiler (esp. standard library) sources. To remedy this, this PR adopts the approach of: - remapping compiler sources (corresponding to `rustc-dev` dist component) with `/rustc-dev/{hash}` (this is `RemapScheme::Compiler`), and - remapping non-compiler sources (corresponding to `rust-src` dist component or other non-compiler sources) with `/rustc/{hash}` (this is `RemapScheme::NonCompiler`). A different remapping allows the compiler to reverse the remapping differently. This PR implements the bootstrap side. A follow-up compiler-side change is needed to implement the unremapping change to address the reported issue completely. This PR introduces another env var `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` that is made available to the compiler when building compiler sources to know what the remap scheme for `rustc-dev` (`RemapScheme::Compiler`) is. Compiler sources are built with the compiler remapping scheme. As far as I know, this change should not introduce new regressions, because the compiler source unremapping (through `rustc-dev`) is already broken. [^note]: (Notice the `src` vs `rustc-src` difference.)
rust-timer
added a commit
that referenced
this issue
Jun 9, 2025
Rollup merge of #141751 - jieyouxu:remap, r=Kobzol Remap compiler vs non-compiler sources differently (bootstrap side) See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083). The path remapping and unremapping for compiler sources (distributed via `rustc-dev` dist component) is broken because bootstrap currently remaps all sources unconditionally (if remapping is enabled) to the `/rustc/{hash}` form. However, the `rustc-dev` dist component (compiler sources) and `rust-src` dist component (library sources) unpacks differently: - `rust-src` unpacks sources to a path like `$sysroot/lib/rustlib/src/rust`, whereas - `rustc-dev` unpacks sources to a path like `$sysroot/lib/rustlib/rustc-src/rust`[^note], meaning that the compiler need to unremap them differently. But the same remapping means that the compiler has no way to distinguish between compiler and non-compiler (esp. standard library) sources. To remedy this, this PR adopts the approach of: - remapping compiler sources (corresponding to `rustc-dev` dist component) with `/rustc-dev/{hash}` (this is `RemapScheme::Compiler`), and - remapping non-compiler sources (corresponding to `rust-src` dist component or other non-compiler sources) with `/rustc/{hash}` (this is `RemapScheme::NonCompiler`). A different remapping allows the compiler to reverse the remapping differently. This PR implements the bootstrap side. A follow-up compiler-side change is needed to implement the unremapping change to address the reported issue completely. This PR introduces another env var `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` that is made available to the compiler when building compiler sources to know what the remap scheme for `rustc-dev` (`RemapScheme::Compiler`) is. Compiler sources are built with the compiler remapping scheme. As far as I know, this change should not introduce new regressions, because the compiler source unremapping (through `rustc-dev`) is already broken. [^note]: (Notice the `src` vs `rustc-src` difference.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: