| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This also makes it test the "structural" ruleset, in preparation for
additional tests where the rulesets disagree.
|
|
This only includes previously existing tests (with a couple duplicates
removed). I plan on adding more comprarisons where the rules differ
once I've updated the pattern typing rules. I also haven't touched the
tests for new rules in old editions; I'll see how best to handle that
once those rules are updated as well.
|
|
|
|
The goal of this cleanup is to make it more apparent which feature gates
correspond to which typing rules, and which typing rules correspond to
what code. My intent is for calls to the "which typing rules do we
have?" functions to be replaced by comments (and edition checks, as
appropriate), but as long as we're experimenting with multiple rulesets,
this seemed to me to be the easiest to document and read. There's still
some nontrivial control flow, but I've added comments to try and make it
clearer.
There's some logic that looks like it could be de-duplicated across
different ways of matching against inherited references; however, the
duplication is intentional. Once we choose which rulesets we want, we
can make this more clever, but until then, my priorities are clarity and
ease of modification/extension. That said, I think the diagnostics could
use some work; factoring out commonalities there (and separating them
from the typing logic) would be ideal. I've opted not to include that
here both since it'd make this refactor less obvious and since it
affects test output.
Also, this doesn't get quite as fine-grained as Typing Rust Patterns, so
there's some instances where certain rules are conflated. I'd prefer to
minimize dead/untested codepaths for rulesets we're not interested in,
so as a compromise I've added comments wherever some aspect of the
typing rules is assumed from another. I'm not totally happy with it, but
I think it's at least better than plain checks against the feature gates
and edition.
|
|
If Rules 3 or 5 are adopted in any edition, we'll need to track the
`MutblCap` in all editions for macro hygiene purposes. Previously, the
check for whether to track it was conflated with the checks for whether
to apply Rules 3 and 5, so to make it a bit clearer, this always tracks
the `MutblCap`. If needed, we could check if Rules 3 or 5 are present in
any edition before tracking the `MutblCap`, but since it's not that much
more expensive to always track it, I've figured that's simplest.
My main concern with removing the checks is that it may not be clear
that the `MutblCap` is tracked for those specific purposes. To try and
mitigate this, I've made its doc comment a bit more precise regarding
the extent of how and why it's used.
This leaves the condition untouched on the `cap_to_weakly_not` call
needed for Rule 5, since it's only needed for that and it can affect
diagnostics.
|
|
As far as I can tell, the assignment removed here will never do
anything. `pat_info.max_ref_mutbl` starts at `MutblCap::Mut` for the
top-level pattern and is only changed if feature gates are enabled that
would result in the statement not being executed. Regardless of what new
pattern typing rules are adopted, I don't imagine we want to
conditionally reset `max_ref_mutbl` based on edition either, since it'd
have consequences for subpatterns in other editions.
|
|
This aims to reduce the complexity needed in the boolean logic for telling which
rules we're using to type patterns. If we still want the functionality this
removes, we can re-add it later, after some cleanup to pattern typing.
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
Rollup of 6 pull requests
Successful merges:
- #133810 (remove unnecessary `eval_verify_bound`)
- #134745 (Normalize each signature input/output in `typeck_with_fallback` with its own span)
- #134989 (Lower Guard Patterns to HIR.)
- #135149 (Use a post-monomorphization typing env when mangling components that come from impls)
- #135171 (rustdoc: use stable paths as preferred canonical paths)
- #135200 (rustfmt: drop nightly-gating of the `--style-edition` flag registration)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=ytmimi,compiler-errors
rustfmt: drop nightly-gating of the `--style-edition` flag registration
Follow-up to [Stabilize `style_edition = "2024"` in-tree #134929](https://github.com/rust-lang/rust/pull/134929).
#134929 un-nightly-gated the *read* of `--style-edition`, but didn't also un-nightly-gate the *registration*/*declaration* of the `--style-edition` flag itself. Reading `--style-edition` on a non-nightly channel (e.g. beta) will thus panic because `--style-edition` is never declared.
This PR also un-nightly-gates the registration. Not sure how to write a regression test for this, because this *requires* the non-nightly / beta channel. Though existing tests do fail (albeit indirectly).
Checking if this fixes the panic against beta in https://github.com/rust-lang/rust/pull/135197.
r? rustfmt
|
|
r=GuillaumeGomez
rustdoc: use stable paths as preferred canonical paths
This accomplishes something like 16a4ad7d7b0d163f7be6803c786c3b83d42913bb, but with the `rustc_allowed_through_unstable_modules` attribute instead of the path length.
Fixes #131676
|
|
Use a post-monomorphization typing env when mangling components that come from impls
When mangling associated methods of impls, we were previously using the wrong param-env. Instead of using a fully monomorphized param-env like we usually do in codegen, we were taking the post-analysis param-env, and treating it as an early binder to *re-substitute* the impl args. I've pointed out the problematic old code in an inline comment.
This would give us param-envs with possibly trivial predicates that would prevent normalization via param-env shadowing.
In the example test linked below, `tests/ui/symbol-names/normalize-in-param-env.rs`, this happens when we mangle the impl `impl<P: Point2> MyFrom<P::S> for P` with the substitution `P = Vec2`. Because the where clause of the impl is `P: Point2`, which elaborates to `[P: Point2, P: Point, <P as Point>::S projects-to <P as Point2>::S2]` and the fact that `impl Point2 for Vec2` normalizes `Vec2::S2` to `Vec2::S`, this causes a cycle.
The proper fix here is to use a fully monomorphized param-env for the case where the impl is properly substituted.
Fixes #135143
While #134081 uncovered this bug for legacy symbol mangling, it was preexisting for v0 symbol mangling. This PR fixes both. The test requires a "hack" because we strip the args of the instance we're printing for legacy symbol mangling except for drop glue, so we box a closure to ensure we generate drop glue.
r? oli-obk
|
|
Lower Guard Patterns to HIR.
Implements lowering of [guard patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see the [tracking issue](#129967)) to HIR.
|
|
Normalize each signature input/output in `typeck_with_fallback` with its own span
Applies the same hack as #106582 but to the args in typeck. Greatly improves normalization error spans from a signature.
|
|
remove unnecessary `eval_verify_bound`
This does not impact any tests. I feel like any cases where this could useful should instead be fixed by a general improvement to `eval_verify_bound` to avoid having to promote this `TypeTest` in the first place :thinking:
r? types cc ``@nikomatsakis``
|
|
minor: Sync from downstream
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135081 (bootstrap: Build jemalloc with support for 64K pages)
- #135174 ([AIX] Port test case run-make/reproducible-build )
- #135177 (llvm: Ignore error value that is always false)
- #135182 (Transmute from NonNull to pointer when elaborating a box deref (MCP807))
- #135187 (apply a workaround fix for the release roadblock)
- #135189 (Remove workaround from pull request template)
- #135193 (don't bless `proc_macro_deps.rs` unless it's necessary)
- #135198 (Avoid naming variables `str`)
- #135199 (Eliminate an unnecessary `Symbol::to_string`; use `as_str`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Eliminate an unnecessary `Symbol::to_string`; use `as_str`
|
|
Avoid naming variables `str`
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
|
|
don't bless `proc_macro_deps.rs` unless it's necessary
Running tidy with `--bless` flag is breaking the build cache as tidy updates mtime of `proc_macro_deps.rs` (https://github.com/rust-lang/rust/pull/134865) unconditionally and that leads cargo to recompile tidy.
This patch fixes that.
|
|
Remove workaround from pull request template
This PR removes the workaround (`\`) from our pull request template as triagebot/rustbot now ignores HTML blocks.
cf. https://github.com/rust-lang/triagebot/pull/1869
cc `@jieyouxu`
r? `@ehuss`
|
|
apply a workaround fix for the release roadblock
This has been a problem since the last two releases.
r? pietroalbini
|
|
Transmute from NonNull to pointer when elaborating a box deref (MCP807)
Since per https://github.com/rust-lang/compiler-team/issues/807 we have to stop projecting into `NonNull`.
cc https://github.com/rust-lang/rust/issues/133652
|
|
llvm: Ignore error value that is always false
See llvm/llvm-project#121851
For LLVM 20+, this function (`renameModuleForThinLTO`) has no return value. For prior versions of LLVM, this never failed, but had a signature which allowed an error value people were handling.
`@rustbot` label: +llvm-main
r? `@nikic`
Wait a moment before approving while the llvm-main infrastructure picks it up.
|
|
[AIX] Port test case run-make/reproducible-build
The test case `run-make/reproducible-build` verifies that two identical invocations of the compiler produce the same output by comparing the linker arguments, resulting binaries, and other artifacts. However, the AIX linker command includes an argument that specifies the file containing exported symbols, with a file path that contains a randomly generated substring to prevent collisions between different linking processes. Additionally, the AIX XCOFF file header includes a 4-byte timestamp. This PR replaces the random substring with a placeholder and nullifies the timestamp field in the XCOFF files for the comparisons.
|
|
bootstrap: Build jemalloc with support for 64K pages
By default, jemalloc is built to only support the same page size as the host machine. Set an env variable so that jemalloc is built with support for page sizes up to 64K regardless of the host machine.
r? `@Kobzol`
Resolves #134563
Potentially resolves #133748 (needs verification)
----
Results from local rustc-perf testing below, within 0.5% on every metric except max-rss.
AArch64:
x86_64:
|
|
Drop unnecessary tracing::warn
|
|
internal: target-triple -> target-tuple + version fetching cleanup
|
|
We already emit an error
|
|
|
|
Fix --target flag argument order in rustc_cfg fetching
|
|
|
|
Remove `rust-analyzer.cargo.sysrootQueryMetadata` config again
|
|
|
|
|
|
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
|
|
|
|
fix: Fix diagnostics not clearing between flychecks
|
|
fix: do not offer completions within macro strings
|
|
Fix JSON project `PackageRoot` buildfile inclusion
|
|
|
|
|
|
|
|
|
|
Running tidy with `--bless` flag is breaking the build cache as tidy updates mtime
of `proc_macro_deps.rs` unconditionally and that leads cargo to recompile tidy.
This patch fixes that.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
minor: Set test-utils dependency version, since it's now published
|
|
|
|
Avoid replacing the definition of `CURRENT_RUSTC_VERSION`
Before this PR, replace-version-placeholder hardcoded the path defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor moved the file defining it without changing the hardcoded path, the tool started replacing the constant itself with the version number.
To avoid this from happening in the future, this changes the definition of the constant to avoid the tool from ever matching it.
r? `@workingjubilee`
|
