| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
ignore head usages from ignored candidates
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns.
The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result.
We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability.
It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
|
|
Rollup of 21 pull requests
Successful merges:
- rust-lang/rust#118087 (Add Ref/RefMut try_map method)
- rust-lang/rust#122661 (Change the desugaring of `assert!` for better error output)
- rust-lang/rust#142640 (Implement autodiff using intrinsics)
- rust-lang/rust#143075 (compiler: Allow `extern "interrupt" fn() -> !`)
- rust-lang/rust#144865 (Fix tail calls to `#[track_caller]` functions)
- rust-lang/rust#144944 (E0793: Clarify that it applies to unions as well)
- rust-lang/rust#144947 (Fix description of unsigned `checked_exact_div`)
- rust-lang/rust#145004 (Couple of minor cleanups)
- rust-lang/rust#145005 (strip prefix of temporary file names when it exceeds filesystem name length limit)
- rust-lang/rust#145012 (Tail call diagnostics to include lifetime info)
- rust-lang/rust#145065 (resolve: Introduce `RibKind::Block`)
- rust-lang/rust#145120 (llvm: Accept new LLVM lifetime format)
- rust-lang/rust#145189 (Weekly `cargo update`)
- rust-lang/rust#145235 (Minor `[const]` tweaks)
- rust-lang/rust#145275 (fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute)
- rust-lang/rust#145322 (Resolve the prelude import in `build_reduced_graph`)
- rust-lang/rust#145331 (Make std use the edition 2024 prelude)
- rust-lang/rust#145369 (Do not ICE on private type in field of unresolved struct)
- rust-lang/rust#145378 (Add `FnContext` in parser for diagnostic)
- rust-lang/rust#145389 ([rustdoc] Revert "rustdoc search: prefer stable items in search results")
- rust-lang/rust#145392 (coverage: Remove intermediate data structures from mapping creation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[rustdoc] Revert "rustdoc search: prefer stable items in search results"
Reverts https://github.com/rust-lang/rust/pull/141658 and reverts https://github.com/rust-lang/rust/pull/145349.
Reopens https://github.com/rust-lang/rust/issues/138067.
r? ```@fmease```
|
|
Add `FnContext` in parser for diagnostic
Fixes rust-lang/rust#144968
Inspired by https://github.com/rust-lang/rust/issues/144968#issuecomment-3156094581, I implemented `FnContext` to indicate whether a function should have a self parameter, for example, whether the function is a trait method, whether it is in an impl block. And I removed the outdated note.
I made two commits to show the difference.
cc ``@estebank`` ``@djc``
r? compiler
|
|
Do not ICE on private type in field of unresolved struct
Fix rust-lang/rust#145367.
|
|
r=petrochenkov
Resolve the prelude import in `build_reduced_graph`
This pr tries to resolve the prelude import at the `build_reduced_graph` stage.
Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493.
r? petrochenkov
|
|
r=alexcrichton
fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute
Resolves rust-lang/rust#140174
r? ```@alexcrichton```
try-job: `test-various*`
|
|
llvm: Accept new LLVM lifetime format
In llvm/llvm-project#150248 LLVM removed the size parameter from the lifetime format. Tolerate not having that size parameter.
|
|
resolve: Introduce `RibKind::Block`
to avoid confusing module items, blocks with items, and blocks without items.
Addresses https://github.com/rust-lang/rust/pull/143141#discussion_r2254893953 and https://github.com/rust-lang/rust/pull/143141#discussion_r2258004452.
A couple of related cleanups are also added on top.
|
|
Tail call diagnostics to include lifetime info
Fixes https://github.com/rust-lang/rust/issues/144957
r? ```@WaffleLapkin``` ```@compiler-errors```
|
|
strip prefix of temporary file names when it exceeds filesystem name length limit
When doing lto, rustc generates filenames that are concatenating many information.
In the case of this testcase, it is concatenating crate name and rust file name, plus some hash, and the extension. In some other cases it will concatenate even more information reducing the maximum effective crate name to about 110 chars on linux filesystems where filename max length is 255
This commit is ensuring that the temporary file names are limited in size, while still reasonably ensuring the unicity (with hashing of the stripped part)
Fix: rust-lang/rust#49914
|
|
Fix tail calls to `#[track_caller]` functions
We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.
The only way to achieve this that I can see is:
- we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented)
- tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)
Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)
Additionally I added a lint, although I don't think it's strictly necessary.
Alternative to rust-lang/rust#144762 (and thus closes rust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
|
|
r=davidtwco
compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixes rust-lang/rust#143072
|
|
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
|
|
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
|
|
Patterns: represent constants as valtrees
Const patterns are always valtrees now. Let's represent that in the types. We use `ty::Value` for this since it nicely packages value and type, and has some convenient methods.
Cc `@Nadrieril` `@BoxyUwU`
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#137872 (Include whitespace in "remove |" suggestion and make it hidden)
- rust-lang/rust#144631 (Fix test intrinsic-raw_eq-const-bad for big-endian)
- rust-lang/rust#145233 (cfg_select: Support unbraced expressions)
- rust-lang/rust#145261 (Improve tracing in bootstrap)
- rust-lang/rust#145324 (Rename and document `ONLY_HOSTS` in bootstrap)
- rust-lang/rust#145353 (bootstrap: Fix jemalloc 64K page support for aarch64 tools)
- rust-lang/rust#145379 (bootstrap: Support passing `--timings` to cargo)
- rust-lang/rust#145397 (Rust documentation, use `rustc-dev-guide` :3)
- rust-lang/rust#145398 (Use `default_field_values` in `Resolver`)
- rust-lang/rust#145401 (cleanup: Remove useless `[T].iter().last()`)
- rust-lang/rust#145403 (Adjust error message grammar to be less awkward)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Adjust error message grammar to be less awkward
r? ``@estebank``
|
|
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
|
|
r=compiler-errors
Fix test intrinsic-raw_eq-const-bad for big-endian
The test fails on s390x and presumably other big-endian systems, due to print of raw values. To fix the tests remove the raw output values in the error note with normalize-stderr.
|
|
Include whitespace in "remove |" suggestion and make it hidden
Tweak error rendering of patterns with an extra `|` on either end.
Built on #137409. Only last commit is relevant.
? ``@compiler-errors``
|
|
Rework target checking for built-in attributes
This is a refactoring of target checking for built-in attributes.
This PR has the following goals:
- Only refactor the 80% of the attributes that are simple to target check. More complicated ones like `#[repr]` will be in a future PR. Tho I have written the code in such a way that this will be possible to add in the future.
- No breaking changes.
- This part of the codebase is not very well tested though, we can do a crater run if we want to be sure.
- I've spotted quite a few weird situations (like I don't think an impl block should be deprecated?). We can propose fixing these to in a future PR
Fixes https://github.com/rust-lang/rust/issues/143780
Fixes https://github.com/rust-lang/rust/issues/138510
I've split it in commits and left a description on some of the commits to help review.
r? `@jdonszelmann`
|
|
|
|
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
scope" help
|
|
|
|
Stabilize `sse4a` and `tbm` target features
This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839).
# Public API
The 2 `x86` target features `sse4a` and `tbm`
Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0
Reference PR:
- https://github.com/rust-lang/reference/pull/1949
cc `@rust-lang/lang`
`@rustbot` label I-lang-nominated
r? lang
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
This reverts commit 1140e90074b0cbcfdea8535e4b51877e2838227e.
|
|
resolve: Miscellaneous cleanups
See individual commits.
All noticed when reviewing recent PRs to name resolution.
|
|
Suppress wrapper suggestion when expected and actual ty are the same adt and the variant is unresolved
Fixes rust-lang/rust#145294
I initially tried the desired suggestion in this issue, but since that suggestion occurs in the expected type, it is inappropriate to suggest for expected expressions (see other suggest methods in the same file). I believe that suppressing the incorrect suggestion is the more appropriate choice here.
I opted for a slightly more general approach: when the expected type and actual type are the same ADT (e.g., both are Result in this example), we assume that code tend to compare the internal generic parameters(i.e. `Option<&str>` vs `Option<String>`, instead of `E = _` vs `Result<Option<String>>>`). When `E` is an unresolved infer type in the expected type (`_` in this example), we should not wrapp the actual type.
Two commits show the difference.
r? compiler
|
|
Port the `#[linkage]` attribute to the new attribute system
r? `@jdonszelmann`
|
|
Add regression test for a former ICE involving helper attributes containing interpolated tokens
Add regression test for rust-lang/rust#140612 from rust-lang/rust#140601 or rather rust-lang/rust#140859 that only added it to `stable` not `master`.
Supersedes https://github.com/rust-lang/rust/pull/140584.
r? `@jdonszelmann` or anyone
|
|
r=fmease,GuillaumeGomez
rustdoc: Allow multiple references to a single footnote
Multiple references to a single footnote is a part of GitHub Flavored Markdown syntax (although not explicitly documented as well as regular footnotes, it is implemented in GitHub's fork of CommonMark) and not prohibited by rustdoc.
cf. <https://github.com/github/cmark-gfm/blob/587a12bb54d95ac37241377e6ddc93ea0e45439b/test/extensions.txt#L762-L780>
However, using it makes multiple `sup` elements with the same `id` attribute, which is invalid per the HTML specification.
Still, not only this is a valid GitHub Flavored Markdown syntax, this is helpful on certain cases and actually tested (accidentally) in `tests/rustdoc/footnote-reference-in-footnote-def.rs`.
This commit keeps track of the number of references per footnote and gives unique ID to each reference.
It also emits *all* back links from a footnote to its references as "↩" (return symbol) plus a numeric list in superscript.
As a known limitation, it assumes that all references to a footnote are rendered (this is not always true if a dangling footnote has one or more references but considered a reasonable compromise).
Also note that, this commit is designed so that no HTML changes will occur unless multiple references to a single footnote is actually used.
|
|
|
|
|
|
|
|
|
|
|
|
Remove one FIXME, addressing it does not reduce the hacky-ness much, and the logic is going to be removed anyway together with the `legacy_derive_helpers` deprecation lint.
|
|
Multiple references to a single footnote is a part of GitHub Flavored
Markdown syntax (although not explicitly documented as well as regular
footnotes, it is implemented in GitHub's fork of CommonMark) and not
prohibited by rustdoc.
cf. <https://github.com/github/cmark-gfm/blob/587a12bb54d95ac37241377e6ddc93ea0e45439b/test/extensions.txt#L762-L780>
However, using it makes multiple "sup" elements with the same "id"
attribute, which is invalid per the HTML specification.
Still, not only this is a valid GitHub Flavored Markdown syntax, this is
helpful on certain cases and actually tested (accidentally) in
tests/rustdoc/footnote-reference-in-footnote-def.rs.
This commit keeps track of the number of references per footnote and gives
unique ID to each reference. It also emits *all* back links from a footnote
to its references as "↩" (return symbol) plus a numeric list in superscript.
As a known limitation, it assumes that all references to a footnote are
rendered (this is not always true if a dangling footnote has one or more
references but considered a reasonable compromise).
Also note that, this commit is designed so that no HTML changes will occur
unless multiple references to a single footnote is actually used.
|
|
interpolated tokens
Co-authored-by: Jana Dönszelmann <jana@donsz.nl>
|
|
resolve: Split extern prelude into two scopes
One scope for `extern crate` items and another for `--extern` options, with the former shadowing the latter.
If in a single scope some things can overwrite other things, especially with ad hoc restrictions like `MacroExpandedExternCrateCannotShadowExternArguments`, then it's not really a single scope.
So this PR splits `Scope::ExternPrelude` into two cleaner scopes.
This is similar to how https://github.com/rust-lang/rust/pull/144131 splits module scope into two scopes for globs and non-globs, but simpler.
|
