Since 1.75 std provides an interface to set access and modified times on files.
This change replaces the external dependency previously used for these operations
with the corresponding std functions.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Stabilize const unchecked conversion from u32 to char
Closes https://github.com/rust-lang/rust/issues/89259.
The functions in this PR were left out of the initial set of `feature(const_char_convert)` stabilizations in https://github.com/rust-lang/rust/pull/102470, but have since been unblocked by https://github.com/rust-lang/rust/pull/118979.
If `unsafe { from_u32_unchecked(u) }` is called in const with a value for which `from_u32(u)` returns None, we get the following compile error.
```rust
fn main() {
let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
}
```
```console
error[E0080]: it is undefined behavior to use this value
--> src/main.rs:2:19
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered 0x0000d800, but expected a valid unicode scalar value (in `0..=0x10FFFF` but not in `0xD800..=0xDFFF`)
|
= note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
= note: the raw bytes of the constant (size: 4, align: 4) {
00 d8 00 00 │ ....
}
note: erroneous constant encountered
--> src/main.rs:2:13
|
2 | let _ = const { unsafe { char::from_u32_unchecked(0xd800) } };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
We don't need to ensure std (and rustc) for testing run-make-support's
unit tests. Using stage 0 compiler is already enough and speeds up
`x test run-make-support` invocations on a clean build.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
std::unix::fs: removing, now useless, layers predating macOs 10.10.
fdopendir, openat and unlinkat are available since yosemite but we support sierra as minimum.
Bootstrap command refactoring: improve debuggability (step 5)
Continuation of https://github.com/rust-lang/rust/pull/127321.
This PR improves the debuggability of command execution, by improving the output logged when a command fails (it now includes the exact location where the command was created and where it was executed), and also by adding a "drop bomb", which will panic if a command was created, but not executed (which is probably a bug).
Here is how the output of a failed command looks like:
```
Command "git" "foo" "[bar]" (failure_mode=Exit, stdout_mode=Capture, stderr_mode=Capture) did not execute successfully.
Expected success, got exit status: 1
Created at: src/core/build_steps/compile.rs:1699:9
Executed at: src/core/build_steps/compile.rs:1699:58
STDOUT ----
STDERR ----
git: 'foo' is not a git command. See 'git --help'.
```
And this is what is printed if you forget to execute a command:
```
thread 'main' panicked at /projects/personal/rust/rust/src/tools/build_helper/src/drop_bomb/mod.rs:42:13:
command constructed at `src/core/build_steps/compile.rs:1699:9` was dropped without being executed: `git`
```
Best reviewed commit by commit.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
It currently doesn't work at all. This commit changes it to a simpler
imperative style that produces a valid `tokens` vec.
(An aside: I find `Iterator::scan` to be a pretty wretched function,
that produces code which is very hard to understand. Probably why this
is just one of two uses of it in the entire compiler.)
That method is currently badly broken, and the test output reflects
this. The obtained tokens list is always empty, except in the case where
we go two `bump`s past the final token, whereupon it will produce as
many `Eof` tokens as asked for.
Improved slice documentation
Improve slice documentation to include assert_eq checks for all the cases where there were existing examples. I think it makes things more clear when the documentation explicitly checks against values and shows the reader what it does.
I also started a rust internals discussion about it here: https://internals.rust-lang.org/t/improve-slice-documentaion/21168
Fix incorrect NDEBUG handling in LLVM bindings
We currently compile our LLVM bindings using `-DNDEBUG` if debuginfo for LLVM is disabled. However, `NDEBUG` doesn't have any relation to debuginfo, it controls whether assertions are enabled.
Split the LLVM_NDEBUG environment variable into two, so that assertions and debuginfo are controlled independently.
After this change, `LLVMRustDIBuilderInsertDeclareAtEnd` triggers an assertion failure on LLVM 19 due to an incorrect cast. Fix it by removing the unused return value entirely.
r? `@cuviper`
fix interleaved output in the default panic hook when multiple threads panic simultaneously
previously, we only held a lock for printing the backtrace itself. since all threads were printing to the same file descriptor, that meant random output in the default panic hook from one thread would be interleaved with the backtrace from another. now, we hold the lock for the full duration of the hook, and the output is ordered.
---
i noticed some odd things while working on this you may or may not already be aware of.
- libbacktrace is included as a submodule instead of a normal rustc crate, and as a result uses `cfg(backtrace_in_std)` instead of a more normal `cfg(feature = "rustc-dep-of-std")`. probably this is left over from before rust used a cargo-based build system?
- the default panic handler uses `trace_unsynchronized`, etc, in `sys::backtrace::print`. as a result, the lock only applies to concurrent *panic handlers*, not concurrent *threads*. in other words, if another, non-panicking, thread tried to print a backtrace at the same time as the panic handler, we may have UB, especially on windows.
- we have the option of changing backtrace to enable locking when `backtrace_in_std` is set so we can reuse their lock instead of trying to add our own.
Guard against calling `libc::exit` multiple times on Linux.
Mitigates (but does not fix) #126600 by ensuring only one thread which calls Rust `exit` actually calls `libc::exit`, and all other callers of Rust `exit` block.
Rollup of 11 pull requests
Successful merges:
- #126502 (Ignore allocation bytes in some mir-opt tests)
- #126922 (add lint for inline asm labels that look like binary)
- #127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate)
- #127310 (Fix import suggestion ice)
- #127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake)
- #127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake)
- #127535 (Fire unsafe_code lint on unsafe extern blocks)
- #127619 (Suggest using precise capturing for hidden type that captures region)
- #127631 (Remove `fully_normalize`)
- #127632 (Implement `precise_capturing` support for rustdoc)
- #127660 (Rename the internal `const_strlen` to just `strlen`)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename the internal `const_strlen` to just `strlen`
Since the libs and lang teams completed an FCP to allow for const `strlen` ([1]), currently implemented with `const_eval_select`, there is no longer any reason to avoid this specific function or use it only in const.
Rename it to reflect this status change.
[1]: https://github.com/rust-lang/rust/issues/113219#issuecomment-2016939401
Implement `precise_capturing` support for rustdoc
Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax.
Tests kinda suck. They're really hard to write 😰
r? `@fmease` or re-roll if you're too busy!
also cc `@aDotInTheVoid` for the json side
Tracking:
* https://github.com/rust-lang/rust/issues/127228#issuecomment-2201443216 (not fully fixed for cross-crate-inlined opaques)
* https://github.com/rust-lang/rust/issues/123432
Suggest using precise capturing for hidden type that captures region
Adjusts the "add `+ '_`" suggestion for opaques to instead suggest adding or reusing the `+ use<>` in the opaque.
r? oli-obk or please re-roll if you're busy!
Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: armhf-gnu
// try-job: test-various // already tried
try-job: x86_64-msvc
try-job: aarch64-apple
Fix import suggestion ice
Fixes#127302#127302 only crash in edition 2015
#120074 can only reproduced in edition 2021
so I added revisions in test file.
Added the `xop` target-feature and the `xop_target_feature` feature gate
This is an effort towards #127208. This adds the `xop` target feature gated by `xop_target_feature`.
add lint for inline asm labels that look like binary
fixes#94426
Due to a bug/feature in LLVM, labels composed of only the digits `0` and `1` can sometimes be confused with binary literals, even if a binary literal would not be valid in that position.
This PR adds detection for such labels and also as a drive-by change, adds a note to cases such as `asm!(include_str!("file"))` that the label that it found came from an expansion of a macro, it wasn't found in the source code.
I expect this PR to upset some people that were using labels `0:` or `1:` without issue because they never hit the case where LLVM got it wrong, but adding a heuristic to the lint to prevent this is not feasible - it would involve writing a whole assembly parser for every target that we have assembly support for.
[zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-20/near/445870628)
r? ``@estebank``
Ignore allocation bytes in some mir-opt tests
This adds `rustc -Zdump-mir-exclude-alloc-bytes` to skip writing allocation bytes in MIR dumps, and applies it to tests that were failing on s390x due to its big-endian byte order.
Fixes#126261
Ensure floats are returned losslessly by the Rust ABI on 32-bit x86
Solves #115567 for the (default) `"Rust"` ABI. When compiling for 32-bit x86, this PR changes the `"Rust"` ABI to return floats indirectly instead of in x87 registers (with the exception of single `f32`s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the `"C"` ABI as that ABI requires x87 register usage and therefore will need a different solution.
The return value changed from an Instruction to a DbgRecord in
LLVM 19. As we don't actually use the result, drop the return
value entirely to support both.
We currently compile our LLVM bindings using `-DNDEBUG` if
debuginfo for LLVM is disabled. However, `NDEBUG` doesn't have
any relation to debuginfo, it controls whether assertions are
enabled.
Rename the environment variable to `LLVM_ASSERTIONS` and drive
it using the `llvm_assertions` option. Also drop the explicit
`debug(false)` call, as cc already sets this up using the
cargo `DEBUG` environment variable.
