| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
And avoid duplicating logic for visiting `Item`s with different kinds (regular, associated, foreign).
|
|
Minor AST cleanups
r? ``@estebank``
|
|
This clarifies something that has puzzled me for some time.
|
|
This makes it clearer what is actually used outside of this crate.
|
|
It's a highly misleading name, because it's completely different to
`MetaItem::name_value_literal`. Specifically, it doesn't match
`MetaItemKind::NameValue` (e.g. `#[foo = 3]`), it matches
`MetaItemKind::List` (e.g. `#[foo(3)]`).
|
|
`MetaItem::value_str` is good enough. And this makes
`MetaItem::value_str` more like `MetaItem::meta_item_list` and
`name_value_literal`.
|
|
It's unreachable, because AST JSON printing support was removed some
time ago.
|
|
|
|
Simplify `static_assert_size`s.
We want to run them on all 64-bit platforms.
r? `@ghost`
|
|
We want to run them on all 64-bit platforms.
|
|
|
|
|
|
|
|
|
|
r=Nadrieril
Match ergonomics 2024: Implement eat-one-layer
r? `@Nadrieril`
cc #123076
`@rustbot` label A-edition-2024 A-patterns
|
|
Implement syntax for `impl Trait` to specify its captures explicitly (`feature(precise_capturing)`)
Implements `impl use<'a, 'b, T, U> Sized` syntax that allows users to explicitly list the captured parameters for an opaque, rather than inferring it from the opaque's bounds (or capturing *all* lifetimes under 2024-edition capture rules). This allows us to exclude some implicit captures, so this syntax may be used as a migration strategy for changes due to #117587.
We represent this list of captured params as `PreciseCapturingArg` in AST and HIR, resolving them between `rustc_resolve` and `resolve_bound_vars`. Later on, we validate that the opaques only capture the parameters in this list.
We artificially limit the feature to *require* mentioning all type and const parameters, since we don't currently have support for non-lifetime bivariant generics. This can be relaxed in the future.
We also may need to limit this to require naming *all* lifetime parameters for RPITIT, since GATs have no variance. I have to investigate this. This can also be relaxed in the future.
r? `@oli-obk`
Tracking issue:
- https://github.com/rust-lang/rust/issues/123432
|
|
|
|
|
|
Cleanup: Rename `ModSep` to `PathSep`
`::` is usually referred to as the *path separator* (citation needed).
The existing name `ModSep` for *module separator* is a bit misleading since it in fact separates the segments of arbitrary path segments, not only ones resolving to modules. Let me just give a shout-out to associated items (`T::Assoc`, `<Ty as Trait>::function`) and enum variants (`Option::None`).
Motivation: Reduce friction for new contributors, prevent potential confusion.
cc `@petrochenkov`
r? nnethercote or compiler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix diagnostic for qualifier in extern block
Closes: https://github.com/rust-lang/rust/issues/123306
|
|
Closes: https://github.com/rust-lang/rust/issues/123306
|
|
Check `x86_64` size assertions on `aarch64`, too
(Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Checking.20size.20assertions.20on.20aarch64.3F)
Currently the compiler has around 30 sets of `static_assert_size!` for various size-critical data structures (e.g. various IR nodes), guarded by `#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]`.
(Presumably this cfg avoids having to maintain separate size values for 32-bit targets and unusual 64-bit targets. Apparently it may have been necessary before the i128/u128 alignment changes, too.)
This is slightly incovenient for people on aarch64 workstations (e.g. Macs), because the assertions normally aren't checked until we push to a PR. So this PR adds `aarch64` to the `#[cfg(..)]` guarding all of those assertions in the compiler.
---
Implemented with a simple find/replace. Verified by manually inspecting each `static_assert_size!` in `compiler/`, and checking that either the replacement succeeded, or adding aarch64 wouldn't have been appropriate.
|
|
r=petrochenkov
More postfix match fixes
These affect diagnostics only, as far as I can tell. I'm too lazy to come up with UI tests, but I could be convinced otherwise.
Specifically, I think changing the precedence computation actually doesn't change anything, but tweaking `contains_exterior_struct_lit` does mean that some diagnostics will begin parenthesizing `S {}.match {}`.
|
|
`P<T>` has implemented `DerefMut` since #54277. While this was lamented
at the time [1], rustc now relies on it extensively via the many
implementors of MutVisitor [2].
Updates the docs to reflect that `P<T>` is fundamentally mutable, and a
few other cleanups to make them nicer to browse.
[1]: https://github.com/rust-lang/rust/pull/54277#discussion_r257181754
[2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors
|
|
This makes it easier for contributors on aarch64 workstations (e.g. Macs) to
notice when these assertions have been violated.
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #121619 (Experimental feature postfix match)
- #122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`)
- #122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit)
- #122542 (coverage: Clean up marker statements that aren't needed later)
- #122800 (Add `NonNull::<[T]>::is_empty`.)
- #122820 (Stop using `<DefId as Ord>` in various diagnostic situations)
- #122847 (Suggest `RUST_MIN_STACK` workaround on overflow)
- #122855 (Fix Itanium mangling usizes)
- #122863 (add more ice tests )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Experimental feature postfix match
This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). [Liaison is](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Postfix.20Match.20Liaison/near/423301844) ```@scottmcm``` with the lang team's [experimental feature gate process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement.
It is entirely implemented in the parser, so it should be relatively easy to remove if needed.
This PR is split in to 5 commits to ease review.
1. The implementation of the feature & gating.
2. Add a MatchKind field, fix uses, fix pretty.
3. Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix.
4. Add new MatchSource to HIR for Clippy & other HIR consumers
|
|
Several (doc) comments were super outdated or didn't provide enough context.
Some doc comments shoved everything in a single paragraph without respecting
the fact that the first paragraph should be a single sentence because rustdoc
treats these as item descriptions / synopses on module pages.
|
|
Implement macro-based deref!() syntax for deref patterns
Stop using `box PAT` syntax for deref patterns, and instead use a perma-unstable macro.
Blocked on #122222
r? `@Nadrieril`
|
|
Stop using `box PAT` syntax for deref patterns, as it's misleading and
also causes their semantics being tangled up.
|
|
It uses very old language that is more confusing today than helpful,
including references to `SubstNt` that no longer exists. The comment
above `TokenStream` is better, and suffices for a basic understanding of
these types.
|
|
|
|
This makes it consistent with `is_whole_expr` and `is_whole_block`.
|
|
Bump to 1.78 bootstrap compiler
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
|
|
various clippy fixes
We need to keep the order of the given clippy lint rules before passing them.
Since clap doesn't offer any useful interface for this purpose out of the box,
we have to handle it manually.
Additionally, this PR makes `-D` rules work as expected. Previously, lint rules were limited to `-W`. By enabling `-D`, clippy began to complain numerous lines in the tree, all of which have been resolved in this PR as well.
Fixes #121481
cc `@matthiaskrgr`
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
