| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
instead, we can just import the intrinsics from core
|
|
|
|
|
|
The `looks_like_refdef` function was assuming the range was valid, this
just adds a check to ensure that is the case. It also works around a
subtraction underflow due to the same invalid range.
changelog: [`doc_nested_refdefs`]: Fix #14287 by avoiding invalid ranges
|
|
(#13960)
Fixes https://github.com/rust-lang/rust-clippy/issues/13514
changelog: Added [`elidable_lifetime_names`] to `pedantic` (Split off
from [`needless_lifetime`] for suggestions with `'_`)
[#13960](https://github.com/rust-lang/rust-clippy/pull/13960)
changelog: Enhancement: [`needless_lifetime`] No longer lints for
elidable lifetimes `'_`, use [`elidable_lifetime_names`] to lint these.
[#13960](https://github.com/rust-lang/rust-clippy/pull/13960)
|
|
- Remove the `Option` from the result type, as `None` is never returned.
- Document the difference from the `BindingMode` in `PatKind::Binding`.
|
|
|
|
|
|
Spruce up `AttributeKind` docs
- Remove dead link to `rustc_attr` crate.
- Add link to `rustc_attr_parsing` crate.
- Split up first paragraph so it looks better at crate-level summary
r? `@jdonszelmann`
|
|
Return unexpected termination error instead of panicing in `Thread::join`
There is a time window during which the OS can terminate a thread before stdlib can retreive its `Packet`. Currently the `Thread::join` panics with no message in such an event, which makes debugging difficult; fixes #124466.
|
|
Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`
Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a]
Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive.
This conflicts with #137444, but I will rebase whichever lands first.
[^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
|
|
add `IntoBounds::intersect` and `RangeBounds::is_empty`
- ACP: https://github.com/rust-lang/libs-team/issues/539
- Tracking issue for `is_empty`: #137300
- Tracking issue for `IntoBounds`: #136903
|
|
r=spastorino
Make `AssocOp` more like `ExprKind`
This is step 1 of [MCP 831](https://github.com/rust-lang/compiler-team/issues/831).
r? ``@estebank``
|
|
require trait impls to have matching const stabilities as the traits
This resolves https://github.com/rust-lang/project-const-traits/issues/5 by implementing the suggested solution in the given thread
r? ``@RalfJung``
cc ``@rust-lang/project-const-traits``
|
|
Fix UB in ThinVec::flat_map_in_place
`thin_vec.as_ptr()` goes through the `Deref` impl of `ThinVec`, which will not allow access to any memory as we did call `set_len(0)` first.
Found in the process of investigating https://github.com/rust-lang/rust/issues/135870.
|
|
[`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing
Reference for overall changes: https://github.com/rust-lang/rust/pull/136437
Part **4** of **7** of the *`compiletest`-related cleanups* PR series.
### Summary
- Remove `--build-base` compiletest flag, and introduce `--build-{root,test-suite-root}` flags instead. `--build-base` previously actually is test suite specific build directory, not the root `build/` directory.
- Feed the root build directory directly from bootstrap to compiletest via `--build-root` instead of doing multiple layers of parent unwrapping[^parent] based on the test suite specific build directory.
- Remove a redundant `to_path_buf()`.
[^parent]: Please do not unwrap the parents.
r? bootstrap
|
|
|
|
|
|
|
|
fixed wast version was released, remove randomization exemption
|
|
To match `ExprKind::Cast`, and because a semantic name makes more sense
here than a syntactic name.
|
|
It makes `AssocOp` more similar to `ExprKind` and makes things a little
simpler. And the semantic names make more sense here than the syntactic
names.
|
|
It mirrors `ExprKind::Binary`, and contains a `BinOpKind`. This makes
`AssocOp` more like `ExprKind`. Note that the variants removed from
`AssocOp` are all named differently to `BinOpToken`, e.g. `Multiply`
instead of `Mul`, so that's an inconsistency removed.
The commit adds `precedence` and `fixity` methods to `BinOpKind`, and
calls them from the corresponding methods in `AssocOp`. This avoids the
need to create an `AssocOp` from a `BinOpKind` in a bunch of places, and
`AssocOp::from_ast_binop` is removed.
`AssocOp::to_ast_binop` is also no longer needed.
Overall things are shorter and nicer.
|
|
changelog: none
|
|
`AssocOp::AssignOp` contains a `BinOpToken`. `ExprKind::AssignOp`
contains a `BinOpKind`. Given that `AssocOp` is basically a cut-down
version of `ExprKind`, it makes sense to make `AssocOp` more like
`ExprKind`. Especially given that `AssocOp` and `BinOpKind` use semantic
operation names (e.g. `Mul`, `Div`), but `BinOpToken` uses syntactic
names (e.g. `Star`, `Slash`).
This results in more concise code, and removes the need for various
conversions. (Note that the removed functions `hirbinop2assignop` and
`astbinop2assignop` are semantically identical, because `hir::BinOp` is
just a synonum for `ast::BinOp`!)
The only downside to this is that it allows the possibility of some
nonsensical combinations, such as `AssocOp::AssignOp(BinOpKind::Lt)`.
But `ExprKind::AssignOp` already has that problem. The problem can be
fixed for both types in the future with some effort, by introducing an
`AssignOpKind` type.
|
|
|
|
- Remove dead link to `rustc_attr` crate.
- Add link to `rustc_attr_parsing` crate.
- Split up first paragraph so it looks better at crate-level summary
|
|
Rollup of 10 pull requests
Successful merges:
- #134585 (remove `MaybeUninit::uninit_array`)
- #136187 (Use less CString in the examples of CStr.)
- #137201 (Teach structured errors to display short `Ty<'_>`)
- #137620 (Fix `attr` cast for espidf)
- #137631 (Avoid collecting associated types for undefined trait)
- #137635 (Don't suggest constraining unstable associated types)
- #137642 (Rustc dev guide subtree update)
- #137660 (Update gcc submodule)
- #137670 (revert accidental change in get_closest_merge_commit)
- #137671 (Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability
While debugging something else, I got quite annoyed with `-Z unpretty=mir` showing me post-processed MIR instead of the one just after it is built. I ended up asking on Zulip and got pointed to `-Z dump-mir`. While this feature is documented in the rustc dev guide, I think it'd be good if the possibility of making use of it was staring you in the face while you need it.
|
|
revert accidental change in get_closest_merge_commit
This was accidentally merged as part of https://github.com/rust-lang/rust/pull/137594. I need this local diff to be able to debug miri syncs, and then typed `git commit -a` too fast and didn't realize it includes this change... sorry for that.
r? ``@Kobzol``
|
|
Update gcc submodule
To add support for the x87 feature (see https://github.com/rust-lang/rust/pull/137612#issuecomment-2683303111).
r? `@antoyo`
|
|
Rustc dev guide subtree update
r? ``@Kobzol`` ``@jieyouxu``
|
|
Don't suggest constraining unstable associated types
Fixes #137624
This could be made a bit more specific, considering the local crate's stability or nightly status or something, but I think in general we should not be suggesting associated type bounds on unstable associated items.
|
|
Avoid collecting associated types for undefined trait
Fixes #137508
Fixes #137554
|
|
Fix `attr` cast for espidf
https://github.com/rust-lang/rust/pull/136826 broke ESP-IDF builds with: https://github.com/esp-rs/esp-idf-template/actions/runs/13516221587/job/37765336588.
This PR fixes it.
cc: ``@ivmarkov`` ``@xizheyin``
|
|
Teach structured errors to display short `Ty<'_>`
Make it so that in every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.
```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
--> long.rs:7:5
|
6 | fn foo(x: D) { //~ `x` has type `(...
| - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 | x(); //~ ERROR expected function, found `(...
| ^--
| |
| call expression requires function
|
= note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Follow up to and response to the comments on #136898.
r? ``@oli-obk``
|
|
Use less CString in the examples of CStr.
Fixes #83999
|
|
remove `MaybeUninit::uninit_array`
Closes #134584.
Closes #66845.
The future of this unstable method was described in https://github.com/rust-lang/rust/pull/125082#issuecomment-2161242816. Since `inline_const` was stabilized in 1.79 (4 stable releases away) and no one expressed interest for keeping it in https://github.com/rust-lang/rust/issues/96097, I think it can be removed now as it is not a stable method.
|
|
|
|
|
|
There is a `visit_inline_const` visitor method and it is used instead.
|
|
thin_vec.as_ptr() goes through the Deref impl of ThinVec, which will
not allow access to any memory as we did call set_len(0) first.
|
|
Fixes #12674, i.e., adds a lint to flag `Path`s printed with `{:?}`.
Nits are welcome.
changelog: Add `unnecessary_debug_formatting` lint
|
