Automatically enable cross-crate inlining for small functions
This is basically reviving https://github.com/rust-lang/rust/pull/70550
The `#[inline]` attribute can have a significant impact on code generation or runtime performance (because it enables inlining between CGUs where it would normally not happen) and also on compile-time performance (because it enables MIR inlining). But it has to be added manually, which is awkward.
This PR factors whether a DefId is cross-crate inlinable into a query, and replaces all uses of `CodegenFnAttrs::requests_inline` with this new query. The new query incorporates all the other logic that is used to determine whether a Def should be treated as cross-crate-inlinable, and as a last step inspects the function's optimized_mir to determine if it should be treated as cross-crate-inlinable.
The heuristic implemented here is deliberately conservative; we only infer inlinability for functions whose optimized_mir does not contain any calls or asserts. I plan to study adjusting the cost model later, but for now the compile time implications of this change are so significant that I think this very crude heuristic is well worth landing.
Normalize alloc-id in tests.
AllocIds are globally numbered in a rustc invocation. This makes them very sensitive to changes unrelated to what is being tested. This commit normalizes them by renumbering, in order of appearance in the output.
The renumbering allows to keep the identity, that a simple `allocN` wouldn't. This is useful when we have memory dumps.
cc `@saethlin`
r? `@oli-obk`
Rollup of 5 pull requests
Successful merges:
- #111072 (Add new simpler and more explicit syntax for check-cfg)
- #116717 (Special case iterator chain checks for suggestion)
- #116719 (Add MonoItems and Instance to stable_mir)
- #116787 (Implement an internal lint encouraging use of `Span::eq_ctxt`)
- #116827 (Make `handle_options` public again.)
r? `@ghost`
`@rustbot` modify labels: rollup
Implement an internal lint encouraging use of `Span::eq_ctxt`
Adds a new Rustc internal lint that forbids use of `.ctxt() == .ctxt()` for spans, encouraging use of `.eq_ctxt()` instead (see https://github.com/rust-lang/rust/issues/49509).
Also fixed a few violations of the lint in the Rustc codebase (a fun additional way I could test my code). Edit: MIR opt folks I believe that's why you're CC'ed, just a heads up.
Two things I'm not sure about:
1. The way I chose to detect calls to `Span::ctxt`. I know adding diagnostic items to methods is generally discouraged, but after some searching and experimenting I couldn't find anything else that worked, so I went with it. That said, I'm happy to implement something different if there's a better way out there. (For what it's worth, if there is a better way, it might be worth documenting in the rustc-dev-guide, which I'm happy to take care of)
2. The error message for the lint. Ideally it would probably be good to give some context as to why the suggestion is made (e.g. `rustc::default_hash_types` tells the user that it's because of performance), but I don't have that context so I couldn't put it in the error message. Happy to iterate on the error message based on feedback during review.
r? ``@oli-obk``
Add MonoItems and Instance to stable_mir
Also add a few methods to instantiate instances and get an instance definition. We're still missing support to actually monomorphize the instance body.
This is related to https://github.com/rust-lang/project-stable-mir/issues/36
r? ``@oli-obk``
``@oli-obk`` is that what you were thinking? I incorporated ``@bjorn3`` idea of just adding a Shim instance definition in https://github.com/rust-lang/rust/pull/116465.
Special case iterator chain checks for suggestion
When encountering method call chains of `Iterator`, check for trailing `;` in the body of closures passed into `Iterator::map`, as well as calls to `<T as Clone>::clone` when `T` is a type param and `T: !Clone`.
Fix#9082.
Add new simpler and more explicit syntax for check-cfg
<details>
<summary>
Old proposition (before the MCP)
</summary>
This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form:
- `exhaustive(names, values)`
- `configure(name, "value1", "value2", ... "valueN")`
The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](https://github.com/rust-lang/rust/pull/98080).
Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`.
To fix that the two new forms are made to be explicit and simpler. See the table of correspondence:
- `names()` -> `exhaustive(names)`
- `values()` -> `exhaustive(values)`
- `names(foo)` -> `exhaustive(names)`&`configure(foo)`
- `values(foo)` -> `configure(foo)`
- `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")`
- `values(foo)`&`values(bar)` -> `configure(foo, bar)`
- `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)`
Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change.
The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support.
</details>
This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](https://github.com/rust-lang/compiler-team/issues/636).
## New `cfg` form
It introduces the new [`cfg` form](https://github.com/rust-lang/compiler-team/issues/636) and deprecate the other two:
```
rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'
```
## Default built-in names and values
It also changes the default for the built-in names and values checking.
- Built-in values checking would always be activated as long as a `--check-cfg` argument is present
- Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed
~~**Note: depends on https://github.com/rust-lang/rust/pull/111068 but is reviewable (last two commits)!**~~
Resolve https://github.com/rust-lang/compiler-team/issues/636
r? `@petrochenkov`
Update cargo
17 commits in 6fa6fdc7606cfa664f9bee2fb33ee2ed904f4e88..ff768b45b302efd488178b31b35489e4fabb8799
2023-10-10 23:06:08 +0000 to 2023-10-17 12:51:31 +0000
- Clarify flag behavior in `cargo remove --help` (rust-lang/cargo#12823)
- doc(cargo-login): mention args after `--` in manpage (rust-lang/cargo#12832)
- changelog: add compat notice for `cargo login -- <arg>` (rust-lang/cargo#12830)
- update SPDX License info (rust-lang/cargo#12827)
- Add test for `-V` short argument (rust-lang/cargo#12822)
- add detailed message when target folder path is invalid (rust-lang/cargo#12820)
- chore(deps): update rust crate toml_edit to 0.20.2 (rust-lang/cargo#12761)
- Support `public` dependency configuration with workspace deps (rust-lang/cargo#12817)
- Update rustix to 0.38.18 (rust-lang/cargo#12815)
- contrib docs: add some conveniences (rust-lang/cargo#12812)
- Better suggestion for unsupported `--path` flag (rust-lang/cargo#12811)
- contrib docs: update rfc and roadmap links (rust-lang/cargo#12814)
- contrib doc: remove extraneous word (rust-lang/cargo#12813)
- Update curl-sys to pull in curl 8.4.0 (rust-lang/cargo#12808)
- feat: add package name and version to warning messages (rust-lang/cargo#12799)
- Do not call it "Downgrading" when difference is only build metadata (rust-lang/cargo#12796)
- Add unsupported short flag suggestion for `--target` and `--exclude` flags (rust-lang/cargo#12805)
r? ghost
document when atomic loads are guaranteed read-only
Based on this [discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Can.20.60Atomic*.3A.3Aload.60.20perform.20a.20write).
The values for x86 and x86_64 are complete guesswork on my side, and I have no clue what the values might be for other architectures. I hope we can get the right people to chime in to gather the required information. :)
I'll update Miri to respect these rules once we have more data.
Updated libc and doc for Vita target
Doc changes:
- Updated Vita target readme. The recommended approach to build artifacts for the platform now is [cargo-vita](https://crates.io/crates/cargo-vita) which wraps all the convoluted steps previously described in a yaml for `cargo-make`
- Updated maintainer list for Vita target. (`@ZetaNumbers` `@pheki` please agree to be added to the list, `@amg98` please let us know if you're still planning on actively maintaining target support)
Code changes:
- ~Updated libc for rust-lang/libc#3284 and rust-lang/libc#3366~ (Already merged in #116527)
- In dupfd changed the flag same as for esp target, there is no CLOEXEC on Vita
- Enabled `new_pair` since we've implemented `socketpair` in Vita newlib
docs: add Rust logo to more compiler crates
c6e6ecb1af added it to some of the compiler's crates, but avoided adding it to all of them to reduce bit-rot. This commit adds to more.
r? `@GuillaumeGomez`
Use tidy to enforce alphabetical dependency ordering
I get annoyed when dependencies in `Cargo.toml` files are not in alphabetical order. The [style guide](https://github.com/rust-lang/rust/blob/master/src/doc/style-guide/src/cargo.md) agrees with me.
There are ongoing efforts to provide linting/formatting of `Cargo.toml` files, e.g. https://github.com/rust-lang/rustfmt/pull/5240, https://crates.io/crates/cargo-toml-lint, and https://github.com/TimonPost/cargo-toml-format. But it's far from clear what's the right approach.
So this PR does something very simple: it uses the order checking already present in tidy. This allows incremental application of ordering, starting right now, and avoiding the need for any kind of all-at-once conversion.
If we do end up using some more comprehensive `Cargo.toml` linting/formatting solution in the future, the `tidy-alphabetical` lines will be easy to remove.
r? `@wesleywiser`
Fix a performance regression in obligation deduplication.
Commit 8378487 from #114611 changed the location of an obligation deduplication step in `opt_normalize_projection_type`. This meant that deduplication stopped happening on one path where it was still necessary, causing a couple of drastic performance regressions.
This commit moves the deduplication back to the old location. The good news is that #114611 had four commits and 8378487 was of minimal importance, so the perf benefits from that PR remain.
Fixes#116780, #116797.
r? `@compiler-errors`
Commit 8378487 from #114611 changed the location of an obligation
deduplication step in `opt_normalize_projection_type`. This meant that
deduplication stopped happening on one path where it was still
necessary, causing a couple of drastic performance regressions.
This commit moves the deduplication back to the old location. The good
news is that #114611 had four commits and 8378487 was of minimal
importance, so the perf benefits from that PR remain.
Fixes#116780, #116797.
Rollup of 6 pull requests
Successful merges:
- #116754 (coverage: Several small cleanups in `spans`)
- #116798 (Improve display of parallel jobs in rustdoc-gui tester script)
- #116800 (Fix implied outlives check for GAT in RPITIT)
- #116805 (Make `rustc_onunimplemented` export path agnostic)
- #116808 (Add myself to smir triage)
- #116811 (Preserve unicode escapes in format string literals when pretty-printing AST)
r? `@ghost`
`@rustbot` modify labels: rollup
Preserve unicode escapes in format string literals when pretty-printing AST
Fixes#116799
Thanks to `@Nilstrieb` for the pointer to the correct location, that was really helpful for someone unfamiliar with the codebase.
Make `rustc_onunimplemented` export path agnostic
This makes it so that all the matchers that match against paths use the definition path instead of the export path. This removes all duplication around `std`/`alloc`/`core`.
This is not necessarily optimal because we now depend on internal implementation details like `core::ops::control_flow::ControlFlow`, which is not very nice and probably not acceptable for a stable `on_unimplemented`.
An alternative would be to just string-replace normalize away `alloc`/`core` to `std` as a special case, keeping the export paths but making it so that we're still fully standard library flavor agnostic.
Looking at the diff, I'm starting to think that some simple string replacement would go a long way towards fixing the problem of duplication while keeping export paths...
What do you prefer?
Also `@weiznich` for your thoughts about the stable version.
r? compiler-errors
Fix implied outlives check for GAT in RPITIT
We enforce certain `Self: 'lt` bounds for GATs to save space for more sophisticated implied bounds, but those currently operate on the HIR. Code was easily reworked to operate on def-ids so that we can properly let these suggestions propagate through synthetic associated types like RPITITs and AFITs.
r? `@jackh726` or `@aliemjay`
Fixes#116789
Improve display of parallel jobs in rustdoc-gui tester script
If no `-j` option is not passed to `x.py`, it would display `-1`, which isn't great.
r? `@notriddle`
Ali MJ Al-Nasrawy