| Age | Commit message (Collapse) | Author | Lines |
|---|
|
clippy-subtree-update
|
|
clippy-subtree-update
|
|
types
|
|
Update books
## rust-lang/nomicon
1 commits in 0c10c30cc54736c5c194ce98c50e2de84eeb6e79..c76a20f0d987145dcedf05c5c073ce8d91f2e82a
2025-04-15 20:54:57 UTC to 2025-04-15 20:54:57 UTC
- Say that dereferencing a pointer to a ZST is no longer undefined (rust-lang/nomicon#467)
## rust-lang/reference
7 commits in 3340922df189bddcbaad17dc3927d51a76bcd5ed..3bf3402aea982b876eb56c87da17b0685c6461d5
2025-04-18 13:44:45 UTC to 2025-04-17 17:27:01 UTC
- Use `cfg(false)` instead of `cfg(FALSE)` (rust-lang/reference#1763)
- Add `cfg(true)` and `cfg(false)` to conditional compilation (RFC 3695) (rust-lang/reference#1762)
- Refactor rendering with `RenderCtx` (rust-lang/reference#1796)
- attributes/codegen: update aarch64 features (rust-lang/reference#1791)
- Simplify GenericParams grammar (rust-lang/reference#1795)
- Add rule identifiers for the ABI chapter (rust-lang/reference#1793)
- Remove broken footnote links from grammar summary (rust-lang/reference#1794)
|
|
handle function alignment in miri
tracking issue: https://github.com/rust-lang/rust/issues/82232
Fixes https://github.com/rust-lang/miri/issues/4282
The `#[repr(align(N))]` attribute on functions was ignored when using miri. For such a function, its address should be a multiple of `N`.
There is some further discussion in the thread [#t-compiler/const-eval > function address alignment](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/function.20address.20alignment) on how `dyn Fn` should be handled. The behavior there appears to be consistent between miri and nightly, though both may be incorrect. In any case, that can be resolved separately.
|
|
feat: Better support `offset_of!()`
|
|
Database`
|
|
This one does need fixpoint.
|
|
|
|
This impacts our manual `salsa::Id` wrappers. I refactored them a bit to improve safety.
|
|
|
|
|
|
feat: Add two new diagnostics: one for mismatch in generic arguments count, and another for mismatch in their kind
|
|
|
|
It's cute, isn't it?
|
|
another for mismatch in their kind
Also known as E0747 and E0107.
And by the way, rewrite how we lower generic arguments and deduplicate it between paths and method calls. The new version is taken almost straight from rustc.
This commit also changes the binders of `generic_defaults()`, to only include the binders of the arguments up to (and not including) the current argument. This make it easier to handle it in the rewritten lowering of generic args. It's also how rustc does it.
|
|
Fix ide-assists raw_string suffix fail
|
|
minor: Fix outdated comment in hir-ty/generics.rs
|
|
|
|
Update chalk
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #139981 (Don't compute name of associated item if it's an RPITIT)
- #140077 (Construct OutputType using macro and print [=FILENAME] help info)
- #140081 (Update `libc` to 0.2.172)
- #140094 (Improve diagnostics for pointer arithmetic += and -= (fixes #137391))
- #140128 (Use correct annotation for CSS pseudo elements)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use correct annotation for CSS pseudo elements
The list of CSS pseudo elements is pretty short so it was easy to go through. Even though the `:` is accepted, it's incorrect.
For a description of CSS pseudo elements: https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements
r? ``@notriddle``
|
|
Remove `token::{Open,Close}Delim`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
r? `@petrochenkov`
|
|
|
|
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
|
|
|
|
rustc-dev-guide subtree update
r? ``@ghost``
|
|
jsondocck: Require command is at start of line
In one place we use `///``@``` instead of `//``@`.`` The test-runner allowed it, but it probably shouldn't. Ran into by ``@lolbinarycat`` in https://github.com/rust-lang/rust/pull/132748#issuecomment-2816469322:
```
error: unknown disambiguator `?(`
##[error] --> /checkout/tests/rustdoc-json/fns/return_type_alias.rs:3:25
|
3 | ///@ set foo = "$.index[?(``@.name=='Foo')].id"``
| ^^
|
```
Maybe it's also worth erroring on this like we added in #137103
r? ``@GuillaumeGomez``
|
|
Fix error when an intra doc link is trying to resolve an empty associated item
Fixes https://github.com/rust-lang/rust/issues/140026.
Assigning ```@nnethercote``` since they're the one who wrote the initial change.
I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty.
r? ```@nnethercote```
|
|
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
|
|
|
|
Use `output_base_dir` for `mir_dump_dir`
It just occurred to me that the problem might be due to multiple revisions using the same dump directory (and therefore deleting the other revision's dir). This fixes that by simply using the normal per-test output directory, which is revision safe.
|
|
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
|
|
|
|
`HygieneId` fits into `Binding`'s padding.
|
|
internal: Make predefined symbols `const` instead of `static`
|
|
Add semicolon to use
|
|
allow using `null` to unset an environment variable
|
|
feat: Parse generic consts
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 11 packages to latest compatible versions
Updating bstr v1.11.3 -> v1.12.0
Updating clap v4.5.35 -> v4.5.36
Updating clap_builder v4.5.35 -> v4.5.36
Updating crossbeam-channel v0.5.14 -> v0.5.15
Updating jiff v0.2.5 -> v0.2.6
Updating jiff-static v0.2.5 -> v0.2.6
Updating jsonpath-rust v1.0.0 -> v1.0.1
Updating linux-raw-sys v0.9.3 -> v0.9.4
Updating miniz_oxide v0.8.7 -> v0.8.8
Updating self_cell v1.1.0 -> v1.2.0
Updating winnow v0.7.4 -> v0.7.6
note: pass `--verbose` to see 38 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating miniz_oxide v0.8.7 -> v0.8.8
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 9 packages to latest compatible versions
Updating bstr v1.11.3 -> v1.12.0
Updating cc v1.2.18 -> v1.2.19
Updating clap v4.5.35 -> v4.5.36
Updating clap_builder v4.5.35 -> v4.5.36
Updating jiff v0.2.5 -> v0.2.6
Updating jiff-static v0.2.5 -> v0.2.6
Updating linux-raw-sys v0.9.3 -> v0.9.4
Updating miniz_oxide v0.8.7 -> v0.8.8
Updating winnow v0.7.4 -> v0.7.6
```
|
|
feat: parse `super let`
|
|
minor: simplify and enhance notable traits rendering
|
|
feat: Allow unsetting env vars in `server.extraEnv` config
|
|
|
|
|
|
|
