Somehow these files aren't properly formatted. By default `x fmt` and `x
tidy` only check files that have changed against master, so if an
ill-formatted file somehow slips in it can stay that way as long as it
doesn't get modified(?)
I found these when I ran `x fmt` explicitly on every `.rs` file in the
repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
Rollup of 6 pull requests
Successful merges:
- #125263 (rust-lld: fallback to rustc's sysroot if there's no path to the linker in the target sysroot)
- #125345 (rustc_codegen_llvm: add support for writing summary bitcode)
- #125362 (Actually use TAIT instead of emulating it)
- #125412 (Don't suggest adding the unexpected cfgs to the build-script it-self)
- #125445 (Migrate `run-make/rustdoc-with-short-out-dir-option` to `rmake.rs`)
- #125452 (Cleanup check-cfg handling in core and std)
r? `@ghost`
`@rustbot` modify labels: rollup
LLVM component names are not immediately obvious (they usually omit any
suffixes on the target arch name), and if they're incorrect, the test
will silently never run.
from std::unix::thread::set_name, pthread_setname_np is a weak symbol
(not always had been available). Other than that, similar to
linux only having twice of its buffer limit.
The `restriction` group contains many lints which are not about
necessarily “bad” things, but style choices — perhaps even style choices
which contradict conventional Rust style — or are otherwise very
situational. This results in silly wording like “Why is this bad?
It isn't, but ...”, which I’ve seen confuse a newcomer at least once.
To improve this situation, this commit replaces the “Why is this bad?”
section heading with “Why restrict this?”, for most, but not all,
restriction lints. I left alone the ones whose placement in the
restriction group is more incidental.
In order to make this make sense, I had to remove the “It isn't, but”
texts from the contents of the sections. Sometimes further changes
were needed, or there were obvious fixes to make, and I went ahead
and made those changes without attempting to split them into another
commit, even though many of them are not strictly necessary for the
“Why restrict this?” project.
Cleanup check-cfg handling in core and std
Follow-up to https://github.com/rust-lang/rust/pull/125296 where we:
- expect any feature cfg in std, due to `#[path]` imports
- move some check-cfg args inside the `build.rs` as per Cargo recommendation
- and replace the fake Cargo feature `"restricted-std"` by the custom cfg `restricted_std`
Fixes https://github.com/rust-lang/rust/pull/125296#issuecomment-2127009301
r? `@bjorn3` (maybe, feel free to re-roll)
Don't suggest adding the unexpected cfgs to the build-script it-self
This PR adds a check to avoid suggesting to add the unexpected cfgs inside the build-script when building the build-script it-self, as it won't have any effect, since build-scripts applies to their descended target.
Fixes#125368
rustc_codegen_llvm: add support for writing summary bitcode
Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area.
I talked some to `@teresajohnson` about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world.
Per `@dtolnay,` you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written.
rust-lld: fallback to rustc's sysroot if there's no path to the linker in the target sysroot
As seen in #125246, some sysroots don't expect to contain `rust-lld` and want to keep it that way, so we fallback to the default rustc sysroot if there is no path to the linker in any of the sysroot tools search paths. This is how we locate codegen-backends' dylibs already.
People also have requested an error if none of these search paths contain the self-contained linker directory, so there's also an error in that case.
r? `@petrochenkov` cc `@ehuss` `@RalfJung`
I'm not sure where we check for `rust-lld`'s existence on the targets where we use it by default, and if we just ignore it when missing or emit a warning (as I assume we don't emit an error), so I just checked for the existence of `gcc-ld`, where `cc` will look for the lld-wrapper binaries.
<sub>*Feel free to point out better ways to do this, it's the middle of the night here.*</sub>
Fixes#125246
Remove more `#[macro_use] extern crate tracing`
Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. Continuing the work from #124511 and #124914.
r? `@jackh726`
Rollup of 7 pull requests
Successful merges:
- #122382 (Detect unused structs which implement private traits)
- #124389 (Add a warning to proc_macro::Delimiter::None that rustc currently does not respect it.)
- #125224 (Migrate `run-make/issue-53964` to `rmake`)
- #125227 (Migrate `run-make/issue-30063` to `rmake`)
- #125336 (Add dedicated definition for intrinsics)
- #125401 (Migrate `run-make/rustdoc-scrape-examples-macros` to `rmake.rs`)
- #125454 (Improve the doc of query associated_item)
r? `@ghost`
`@rustbot` modify labels: rollup
If we don't do this, some versions of LLVM (at least 17, experimentally)
will double-emit some error messages, which is how I noticed this. Given
that it seems to be costing some extra work, let's only request the
summary bitcode production if we'll actually bother writing it down,
otherwise skip it.
Allow sysroots to only consist of the source root dir
Fixes https://github.com/rust-lang/rust-analyzer/issues/17159
This PR encodes the `None` case of an optional sysroot into `Sysroot` itself. This simplifies a lot of things and allows us to have sysroots that consist of nothing, only standard library sources, everything but the standard library sources or everything. This makes things a lot more flexible. Additionally, this removes the workspace status bar info again, as it turns out that that can be too much information for the status bar to handle (this is better rendered somewhere else, like in the status view).
Improve the doc of query associated_item
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
This query also maps from a impl item to the impl item "descriptor". So it's a bit confused, I skipped it cause it doesn't say it contains impl items.
```rust
fn associated_item(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ty::AssocItem {
let id = tcx.local_def_id_to_hir_id(def_id);
let parent_def_id = tcx.hir().get_parent_item(id);
let parent_item = tcx.hir().expect_item(parent_def_id.def_id);
match parent_item.kind {
hir::ItemKind::Impl(impl_) => {
if let Some(impl_item_ref) = impl_.items.iter().find(|i| i.id.owner_id.def_id == def_id)
{
let assoc_item = associated_item_from_impl_item_ref(impl_item_ref);
debug_assert_eq!(assoc_item.def_id.expect_local(), def_id);
return assoc_item;
}
}
hir::ItemKind::Trait(.., trait_item_refs) => {
if let Some(trait_item_ref) =
trait_item_refs.iter().find(|i| i.id.owner_id.def_id == def_id)
{
let assoc_item = associated_item_from_trait_item_ref(trait_item_ref);
debug_assert_eq!(assoc_item.def_id.expect_local(), def_id);
return assoc_item;
}
}
_ => {}
}
span_bug!(
parent_item.span,
"unexpected parent of trait or impl item or item not found: {:?}",
parent_item.kind
)
}
```
Migrate `run-make/issue-53964` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This is extremely similar to #125146. Could it be interesting to merge the two in some way? This one seems to do the same thing as the #125146, but with an added check that a useless lint is not shown.
Add a warning to proc_macro::Delimiter::None that rustc currently does not respect it.
It does not provide the behaviour it is indicated to provide when used in a proc_macro context.
This seems to be a bug, (https://github.com/rust-lang/rust/issues/67062), but it is a long standing one, and hard to discover.
This pull request adds a warning to inform users of this issue, with a link to the relevant issue, and a version number of the last known affected rustc version.
Rephrase and expand `empty_enum` documentation.
* Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”.
* Discuss why one would use `!`, a newtype struct, or keep the enum.
* Add links to relevant documentation.
Before writing this change, I asked the community via [IRLO](https://internals.rust-lang.org/t/idiomatic-definition-of-uninhabited-never-newtypes/20877) and [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Never.20type.20wrappers.20.2F.20defining.20uninhabited.20newtypes) for feedback. The broad consensus seemed to me to be that in a world where both `never_type` and `min_exhaustive_patterns` are stable and therefore available for general use, we _might_ want to `!` or newtypes of it — but it's certainly not “conventional” _yet._ Therefore, I've removed “conventional” and added a discussion of the pros and cons of different choices.
changelog: [`empty_enum`]: expanded documentation
Urgau