| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Strip frontmatter in fewer places
* Stop stripping frontmatter in `proc_macro::Literal::from_str` (RUST-146132)
* Stop stripping frontmatter in expr-ctxt (but not item-ctxt!) `include`s (RUST-145945)
* Stop stripping shebang (!) in `proc_macro::Literal::from_str`
* Not a breaking change because it did compare spans already to ensure there wasn't extra whitespace or comments (`Literal::from_str("#!\n0")` already yields `Err(_)` thankfully!)
* Stop stripping frontmatter+shebang inside some rustdoc code where it doesn't make any observable difference (see self review comments)
* (Stop stripping frontmatter+shebang inside internal test code)
Fixes https://github.com/rust-lang/rust/issues/145945.
Fixes https://github.com/rust-lang/rust/issues/146132.
r? fee1-dead
|
|
|
|
|
|
|
|
cleanup and cache proof tree building
There's some cruft left over from when we had deep proof trees. We never encounter overflow when evaluating proof trees. Even if the recursion limit is `0`, we still only hit the overflow limit when evaluating nested goals of the root. The root goal simply inherits the `root_depth` of the `SearchGraph`.
Split `evaluate_root_goal_for_proof_tree` from the rest of the trait solver. This enables us to simplify the implementation of `evaluate_goal_raw` and the `ProofTreeBuilder` as we no longer need to manually track the state of the builder and can instead use separate types for that. It does require making a few internal methods into associated functions taking a `delegate` and a `span` instead of the `EvalCtxt` itself.
I've also split `SearchGraph::evaluate_goal` and `SearchGraph::evaluate_root_goal_for_proof_tree` for the same reason. Both functions don't actually share too much code, so by splitting them each version gets significantly easier to read.
Add a `query evaluate_root_goal_for_proof_tree_raw` to cache proof tree building. This requires arena allocating `inspect::Probe`. I've added a new type alias `I::ProbeRef` for this. We may need to adapt this for rust-analyzer? It would definitely be easy to remove the `Copy` bound here :thinking:
|
|
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
|
|
|
|
|
|
|
|
|
|
Rollup of 28 pull requests
Successful merges:
- rust-lang/rust#132087 (Fix overly restrictive lifetime in `core::panic::Location::file` return type)
- rust-lang/rust#137396 (Recover `param: Ty = EXPR`)
- rust-lang/rust#137457 (Fix host code appearing in Wasm binaries)
- rust-lang/rust#142185 (Convert moves of references to copies in ReferencePropagation)
- rust-lang/rust#144648 (Implementation: `#[feature(nonpoison_rwlock)]`)
- rust-lang/rust#144897 (print raw lifetime idents with r#)
- rust-lang/rust#145218 ([Debuginfo] improve enum value formatting in LLDB for better readability)
- rust-lang/rust#145380 (Add codegen-llvm regression tests)
- rust-lang/rust#145573 (Add an experimental unsafe(force_target_feature) attribute.)
- rust-lang/rust#145597 (resolve: Remove `ScopeSet::Late`)
- rust-lang/rust#145633 (Fix some typos in LocalKey documentation)
- rust-lang/rust#145641 (On E0277, point at type that doesn't implement bound)
- rust-lang/rust#145669 (rustdoc-search: GUI tests check for `//` in URL)
- rust-lang/rust#145695 (Introduce ProjectionElem::try_map.)
- rust-lang/rust#145710 (Fix the ABI parameter inconsistency issue in debug.rs for LoongArch64)
- rust-lang/rust#145726 (Experiment: Reborrow trait)
- rust-lang/rust#145731 (Make raw pointers work in type-based search)
- rust-lang/rust#145736 (triagebot: Update style team reviewers)
- rust-lang/rust#145738 (Uplift rustc_mir_transform::coverage::counters::union_find to rustc_data_structures.)
- rust-lang/rust#145742 (rustdoc js: Even more typechecking improvments )
- rust-lang/rust#145743 (doc: fix some typos in comment)
- rust-lang/rust#145745 (tests: Ignore basic-stepping.rs on LoongArch)
- rust-lang/rust#145747 (Refactor lint buffering to avoid requiring a giant enum)
- rust-lang/rust#145751 (fix(lexer): Allow '-' in the frontmatter infostring continue set)
- rust-lang/rust#145761 (Add aarch64_be-unknown-hermit target)
- rust-lang/rust#145762 (convert strings to symbols in attr diagnostics)
- rust-lang/rust#145763 (Ship LLVM tools for the correct target when cross-compiling)
- rust-lang/rust#145765 (Revert suggestions for missing methods in tuples)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
|
|
|
|
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
|
|
|
|
Add `-Zindirect-branch-cs-prefix`
Cc: ``@azhogin`` ``@Darksonn``
This goes on top of https://github.com/rust-lang/rust/pull/135927, i.e. please skip the first commit here. Please feel free to inherit it there.
In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.
There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.
Tracking issue: https://github.com/rust-lang/rust/issues/116852.
MCP: https://github.com/rust-lang/compiler-team/issues/868.
|
|
|
|
Fix adjacent code
Fix duplicate warning; merge test into `tests/ui-fulldeps/internal-lints`
Use `rustc_middle::ty::FnSig::inputs`
Address two review comments
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109006991
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109058588
Use `Instance::try_resolve`
Import `rustc_middle::ty::Ty` as `Ty` rather than `MiddleTy`
Simplify predicate handling
Add more `#[allow(rustc::potential_query_instability)]` following rebase
Remove two `#[allow(rustc::potential_query_instability)]` following rebase
Address review comment
Update compiler/rustc_lint/src/internal.rs
Co-authored-by: lcnr <rust@lcnr.de>
|
|
|
|
remove `P`
Previous work: rust-lang/rust#141603
MCP: https://github.com/rust-lang/compiler-team/issues/878
cc `@nnethercote`
|
|
|
|
Fix some bad formatting in `-Zmacro-stats` output.
r? `@petrochenkov`
|
|
I also double-checked that everything looks good on some real-world
crates.
|
|
|
|
This flag turned out to be less useful than anticipated, and interferes with
work towards expansion support.
|
|
Perform check_private_in_public by module.
Based on https://github.com/rust-lang/rust/pull/116316
|
|
It's not used in `rustc_middle`, and `rustc_resolve` is a better place
for it.
|
|
|
|
|
|
gpu offload host code generation
r? ghost
This will generate most of the host side code to use llvm's offload feature.
The first PR will only handle automatic mem-transfers to and from the device.
So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch.
Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening.
A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU.
A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues.
I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work.
This work will also be compatible with std::autodiff, so one can differentiate GPU kernels.
Tracking:
- https://github.com/rust-lang/rust/issues/131513
|
|
code generation
|
|
|
|
|
|
This saves about 30s.
|
|
|
|
Avoid depending on forever-red DepNode when encoding metadata.
Split from https://github.com/rust-lang/rust/pull/114669 for perf
r? `@petrochenkov`
|
|
|
|
Handle build scripts better in `-Zmacro-stats` output.
Currently all build scripts are listed as `build_script_build` in the stats header. This commit uses `CARGO_PKG_NAME` to improve that.
I tried it on Bevy, it works well, giving output like this on the build script:
```
MACRO EXPANSION STATS: serde build script
```
and this on the crate itself:
```
MACRO EXPANSION STATS: serde
```
r? `@Kobzol`
|
|
Currently all build scripts are listed as `build_script_build` in the
stats header. This commit uses `CARGO_PKG_NAME` to improve that.
I tried it on Bevy, it works well, giving output like this on the build
script:
```
MACRO EXPANSION STATS: serde build script
```
and this on the crate itself:
```
MACRO EXPANSION STATS: serde
```
|
|
By allowing long names to overlap with the "Uses" field when it has
spare space. This avoids unnecessary line breaks in the output.
|
|
Tweak `-Zmacro-stats` measurement.
It currently reports net size, i.e. size(output) - size(input). After some use I think this is sub-optimal, and it's better to just report size(output). Because for derive macros the input size is always 1, and for attribute macros it's almost always 1.
r? ```@petrochenkov```
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142645 (Also emit suggestions for usages in the `non_upper_case_globals` lint)
- rust-lang/rust#142657 (mbe: Clean up code with non-optional `NonterminalKind`)
- rust-lang/rust#142799 (rustc_session: Add a structure for keeping both explicit and default sysroots)
- rust-lang/rust#142805 (Emit a single error when importing a path with `_`)
- rust-lang/rust#142882 (Lazy init diagnostics-only local_names in borrowck)
- rust-lang/rust#142883 (Add impl_trait_in_bindings tests from rust-lang/rust#61773)
- rust-lang/rust#142943 (Don't include current rustc version string in feature removed help)
- rust-lang/rust#142965 ([RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform)
- rust-lang/rust#142972 (Add a missing mailmap entry)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Stats output tweaks
Some improvements to `-Zinput-stats` and `-Zmeta-stat` inspired by the new `-Zmacro-stats`.
r? `@lqd`
|
|
Also avoid creating and cloning sysroot unnecessarily.
|
|
To make it match `-Zmacro-stats`, and work better if you have enabled it
for multiple crates.
- Print each crate's name.
- Print a `===` banner at the start and end for separation.
|
|
Taking inspiration from `-Zmacro-stats`:
- Use "{prefix}" consistently.
- Use names for column widths.
- Write output in a single `eprint!` call, in an attempt to minimize
interleaving of output from different rustc processes.
- Use `repeat` for the long `---` banners.
|
|
It currently reports net size, i.e. size(output) - size(input). After
some use I think this is sub-optimal, and it's better to just report
size(output). Because for derive macros the input size is always 1, and
for attribute macros it's almost always 1.
|
|
Add codegen timing section
And since we now start and end the sections also using separate functions, also add some light checking if we're generating the sections correctly.
I'm integrating `--timings` into Cargo, and I realized that the codegen timings would be quite useful for that. Frontend can be computed simply as `[start of compilation, start of codegen]` for now.
r? `@nnethercote`
|
|
|
|
Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`
This PR moves [`rustc_rayon_core`](https://github.com/rust-lang/rustc-rayon/tree/5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations.
**Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements.
r? oli-obk
|
