| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #140142 (Some more graphviz tweaks)
- #140146 (Update `compiler_builtins` to 0.1.156)
- #140147 (Clean: rename `open_braces` to `open_delimiters` in lexer and move `make_unclosed_delims_error` into `diagnostics.rs`.)
- #140160 (Use `is_lang_item` and `as_lang_item` instead of handrolling their logic)
- #140163 (Validate extension in `PathBuf::add_extension`)
- #140173 (Ping Mara when touching format_args!() internals.)
- #140175 (`rc""` more clear error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Tracking issue #139324
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
The host's linker is used to compile build.rs files (e.g. for libc).
When the user configures a custom liker (e.g. mold) in their own
.cargo/config.toml or ~/.cargo/config.toml, that linker will likely not
work when running run-docker.sh. So, we now reset it to `cc`, which
should always be installed in the docker container.
|
|
|
|
|
|
It would be nice to reuse some of the macro structure for internal
functions, like `rem_pio2`. To facilitate this, add a `public` field and
make it available in the macro's API.
|
|
'f16', 'f32', 'f64', and 'f128' into 'const fn' items;
|
|
Validate extension in `PathBuf::add_extension`
The extension is validated in `PathBuf::set_extension`, but not `add_extension`. Fix that. Check for both `/` and `\` path separators on Windows, even when the path is verbatim, since this is logically like `PathBuf::push` which normalizes separators (i.e., keeping the current behavior).
`PathBuf::add_extension` is tracked in #127292.
r? `@ChrisDenton`
|
|
Update `compiler_builtins` to 0.1.156
Includes the following changes:
* Provide `abort` on AVR [1]
[1]: https://github.com/rust-lang/compiler-builtins/pull/830
|
|
Update the musl submodule to c47ad25ea3 ("iconv: harden UTF-8 output
code path against input decoder bugs").
|
|
test_nan: ensure the NAN contant is quiet
Follow-up to https://github.com/rust-lang/rust/pull/139483
r? ``@tgross35``
|
|
Use posix_spawn on cygwin
r? ``@joboet``
Depends on:
- [x] https://github.com/rust-lang/libc/pull/4387
- [x] https://github.com/rust-lang/rust/pull/140081
|
|
The extension is validated in `PathBuf::set_extension`, but not
`add_extension`. Fix that. Check for both / and \ path separators on
Windows, even when the path is verbatim, since this is logically like
`PathBuf::push` which normalizes separators (i.e., keeping the current
behavior).
|
|
|
|
|
|
The published crates fail to build with an edition less than 2024
because they are packaged with `resolver = "3"`, which is a 2024-only
option. Revert back to resolver v2 to drop this requirement.
Fixes: https://github.com/rust-lang/compiler-builtins/issues/883
|
|
|
|
|
|
Includes the following changes:
* Provide `abort` on AVR [1]
[1]: https://github.com/rust-lang/compiler-builtins/pull/830
|
|
Also, update the same pattern of reuse in `sys::args` to match.
|
|
This unintentionally got split when compiler-builtins was moved to a
subdirectory.
|
|
|
|
|
|
|
|
|
|
I missed this in #139868. Its `mod` declaration was removed, but the
contents were not moved.
|
|
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are
publicly exposed via `std::env`, their implementations are each
self-contained. Keep them separate in `std::sys` and make a new module,
`sys::env`, for `Env`.
|
|
`compiler-builtins` uses `public-test-deps`, `libm` uses
`unstable-public-internals`. Consolidate these under the `libm` name.
Once compiler-builtins is no longer published, this feature can probably
be dropped.
Also switch to `dep:` syntax for features that enable dependencies.
|
|
Move this to a script and ensure only `libm-test` gets built to avoid
default feature issues with `compiler-builtins`.
|
|
Update `libc` to 0.2.172
r? ````@joboet````
|
|
Rollup of 11 pull requests
Successful merges:
- #134213 (Stabilize `naked_functions`)
- #139711 (Hermit: Unify `std::env::args` with Unix)
- #139795 (Clarify why SGX code specifies linkage/symbol names for certain statics)
- #140036 (Advent of `tests/ui` (misc cleanups and improvements) [4/N])
- #140047 (remove a couple clones)
- #140052 (Fix error when an intra doc link is trying to resolve an empty associated item)
- #140074 (rustdoc-json: Improve test for auto-trait impls)
- #140076 (jsondocck: Require command is at start of line)
- #140107 (rustc-dev-guide subtree update)
- #140111 (cleanup redundant pattern instances)
- #140118 ({B,C}Str: minor cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
{B,C}Str: minor cleanup
(hopefully) uncontroversial bits extracted from #139994.
|
|
cleanup redundant pattern instances
Just two small code cleanups.
|
|
Clarify why SGX code specifies linkage/symbol names for certain statics
Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests.
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
|
|
Hermit: Unify `std::env::args` with Unix
The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.
The atomic orderings were established in https://github.com/rust-lang/rust/pull/74006 (cc `@euclio)` for Unix and https://github.com/rust-lang/rust/pull/100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match.
Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit.
cc `@mkroening` `@stlankes` for Hermit
|
|
r=tgross35,Amanieu,traviscross
Stabilize `naked_functions`
tracking issue: https://github.com/rust-lang/rust/issues/90957
request for stabilization on tracking issue: https://github.com/rust-lang/rust/issues/90957#issuecomment-2539270352
reference PR: https://github.com/rust-lang/reference/pull/1689
# Request for Stabilization
Two years later, we're ready to try this again. Even though this issue is already marked as having passed FCP, given the amount of time that has passed and the changes in implementation strategy, we should follow the process again.
## Summary
The `naked_functions` feature has two main parts: the `#[naked]` function attribute, and the `naked_asm!` macro.
An example of a naked function:
```rust
const THREE: usize = 3;
#[naked]
pub extern "sysv64" fn add_n(number: usize) -> usize {
// SAFETY: the validity of the used registers
// is guaranteed according to the "sysv64" ABI
unsafe {
core::arch::naked_asm!(
"add rdi, {}",
"mov rax, rdi",
"ret",
const THREE,
)
}
}
```
When the `#[naked]` attribute is applied to a function, the compiler won't emit a [function prologue](https://en.wikipedia.org/wiki/Function_prologue_and_epilogue) or epilogue when generating code for this function. This attribute is analogous to [`__attribute__((naked))`](https://developer.arm.com/documentation/100067/0608/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function.
The body of a naked function must consist of a single `naked_asm!` invocation, a heavily restricted variant of the `asm!` macro: the only legal operands are `const` and `sym`, and the only legal options are `raw` and `att_syntax`. In lieu of specifying operands, the `naked_asm!` within a naked function relies on the function's calling convention to determine the validity of registers.
## Documentation
The Rust Reference: https://github.com/rust-lang/reference/pull/1689
(Previous PR: https://github.com/rust-lang/reference/pull/1153)
## Tests
* [tests/run-make/naked-symbol-visiblity](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) verifies that `pub`, `#[no_mangle]` and `#[linkage = "..."]` work correctly for naked functions
* [tests/codegen/naked-fn](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) has tests for function alignment, use of generics, and validates the exact assembly output on linux, macos, windows and thumb
* [tests/ui/asm/naked-*](https://github.com/rust-lang/rust/tree/master/tests/ui/asm) tests for incompatible attributes, generating errors around incorrect use of `naked_asm!`, etc
## Interaction with other (unstable) features
### [fn_align](https://github.com/rust-lang/rust/issues/82232)
Combining `#[naked]` with `#[repr(align(N))]` works well, and is tested e.g. here
- https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/aligned.rs
- https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/min-function-alignment.rs
It's tested extensively because we do need to explicitly support the `repr(align)` attribute (and make sure we e.g. don't mistake powers of two for number of bytes).
## History
This feature was originally proposed in [RFC 1201](https://github.com/rust-lang/rfcs/pull/1201), filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in [#32410](https://github.com/rust-lang/rust/pull/32410), landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by [RFC 2972](https://github.com/rust-lang/rfcs/pull/2972), filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the `naked` attribute; these lints became hard errors in [#93153](https://github.com/rust-lang/rust/pull/93153) on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the `naked` attribute.
More recently, the `naked_asm!` macro was added to replace the earlier use of a heavily restricted `asm!` invocation. The `naked_asm!` name is clearer in error messages, and provides a place for documenting the specific requirements of inline assembly in naked functions.
The implementation strategy was changed to emitting a global assembly block. In effect, an extern function
```rust
extern "C" fn foo() {
core::arch::naked_asm!("ret")
}
```
is emitted as something similar to
```rust
core::arch::global_asm!(
"foo:",
"ret"
);
extern "C" {
fn foo();
}
```
The codegen approach was chosen over the llvm naked function attribute because:
- the rust compiler can guarantee the behavior (no sneaky additional instructions, no inlining, etc.)
- behavior is the same on all backends (llvm, cranelift, gcc, etc)
Finally, there is now an allow list of compatible attributes on naked functions, so that e.g. `#[inline]` is rejected with an error. The `#[target_feature]` attribute on naked functions was later made separately unstable, because implementing it is complex and we did not want to block naked functions themselves on how target features work on them. See also https://github.com/rust-lang/rust/issues/138568.
relevant PRs for these recent changes
- https://github.com/rust-lang/rust/pull/127853
- https://github.com/rust-lang/rust/pull/128651
- https://github.com/rust-lang/rust/pull/128004
- https://github.com/rust-lang/rust/pull/138570
-
### Various historical notes
#### `noreturn`
[RFC 2972](https://github.com/rust-lang/rfcs/blob/master/text/2972-constrained-naked.md) mentions that naked functions
> must have a body which contains only a single asm!() statement which:
> iii. must contain the noreturn option.
Instead of `asm!`, the current implementation mandates that the body contain a single `naked_asm!` statement. The `naked_asm!` macro is a heavily restricted version of the `asm!` macro, making it easier to talk about and document the rules of assembly in naked functions and give dedicated error messages.
For `naked_asm!`, the behavior of the `asm!`'s `noreturn` option is implicit. The `noreturn` option means that it is UB for control flow to fall through the end of the assembly block. With `asm!`, this option is usually used for blocks that diverge (and thus have no return and can be typed as `!`). With `naked_asm!`, the intent is different: usually naked funtions do return, but they must do so from within the assembly block. The `noreturn` option was used so that the compiler would not itself also insert a `ret` instruction at the very end.
#### padding / `ud2`
A `naked_asm!` block that violates the safety assumption that control flow must not fall through the end of the assembly block is UB. Because no return instruction is emitted, whatever bytes follow the naked function will be executed, resulting in truly undefined behavior. There has been discussion whether rustc should emit an invalid instruction (e.g. `ud2` on x86) after the `naked_asm!` block to at least fail early in the case of an invalid `naked_asm!`. It was however decided that it is more useful to guarantee that `#[naked]` functions NEVER contain any instructions besides those in the `naked_asm!` block.
# unresolved questions
None
r? ``@Amanieu``
I've validated the tests on x86_64 and aarch64
|
|
|
|
docs(LocalKey<T>): clarify that T's Drop shouldn't panic
Clarify that should a TLS destructor panics, the process will abort.
Also, an abort may be obfuscated as the process can be terminated with `SIGSEGV` or [`STATUS_STACK_BUFFER_OVERRUN`](https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655) (i.e., `SIGABRT` is not guaranteed), so explicitly prints that the process was aborted.
Context:
https://users.rust-lang.org/t/status-stack-buffer-overrun-on-windows-without-any-usage-of-unsafe/128417
``@rustbot`` label -T-compiler
|
|
SystemTime doc tweaks
* Change the `UNIX_EPOCH` link in the `SystemTime` docs to point to the associated constant, not the module level constant. The former seems to be the recommended way to access it, since aiui the only reason the module constant exists in the first place is that associated constants weren't stable yet at the time.
* Reword the comment in the `SystemTime` example - "an error occurred!" is a tad misleading; I feel like it implies a system error out of our control while `SystemTimeError` is more of a logic error.
I was originally just gonna do the first thing but I noticed the second and figured I may as well.
I'm also somewhat surprised that there aren't more in-depth module level docs for `std::time`; they don't even mention `SystemTime` at all. I might make another PR for that but mainly just wanted to flag it.
|
|
fix missing word in comment
a very simple fix, rectifying a situation in which a word was accidentally .
|
|
|
|
|
|
compiler-builtins currently wouldn't publish correctly because of a
relative path to `libm` that doesn't get included in the package. Fix
this by simlinking `libm` to within the `compiler-builtins` directory.
Also symlink LICENSE.txt which lets us drop the `include` array in
Cargo.toml. LICENSE.txt and compiler-rt were not being included anyway,
since Cargo silently drops items that are not within the crate
directory.
|
|
|
