Rollup of 8 pull requests #79273
Merged
Rollup of 8 pull requests #79273
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…t-lang#78777: handle DefKind::ForeignTy variant
They can be derived directly from the `hir::Item`, there's no special logic. - TypeDef - OpaqueTy - Constant - Static - TraitAlias - Enum - Union - Struct
Both flags are mutually exclusive
This makes it clearer that only PassMode::Indirect allows ByVal
It is applied exactly when the return value has an indirect pass mode. Except for InReg on x86 fastcall, arg attrs are now only used for optimization purposes and thus are fine to ignore.
clarify rules for ZST Boxes LLVM's rules around `getelementptr inbounds` with offset 0 are a bit annoying, and as a consequence we have no choice but say that a `Box<()>` pointing to previously allocated memory that has since been freed is UB. Clarify the docs to reflect this. This is based on conversations on the LLVM mailing list. * Here's my initial mail: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html * The first email of the March part of that thread: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html * First email of the April part: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html The conclusion for me at least was that `getelementptr inbounds` with offset 0 is *not* the identity function, but can sometimes return `poison` even when the input is a regular pointer -- specifically, it returns `poison` when this pointer points into something that LLVM "knows has been deallocated", i.e., a former LLVM-managed allocation. It is however the identity function on pointers obtained by casting integers. Note that there [are formal proposals](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf) for LLVM semantics where `getelementptr inbounds` with offset 0 isn't quite the identity function but never returns `poison` (it affects the provenance of the pointer but in a way that doesn't matter if this pointer is never used for memory accesses), and indeed this is likely necessary to consistently describe LLVM semantics. But with the informal LLVM LangRef that we have right now, and with LLVM devs insisting otherwise, it seems unwise to rely on this.
Refactor the abi handling code a bit I am not quite sure if all changes are improvements.
…r=jyn514 Fix links to extern types in rustdoc (fixes rust-lang#78777) r? `@jyn514` Fixes rust-lang#78777. The initial fix we tried was: ```diff diff --git a/src/librustdoc/passes/collect_intra_doc_links.rs b/src/librustdoc/passes/collect_intra_doc_links.rs index 8be9482acff..c4b7086fdb1 100644 --- a/src/librustdoc/passes/collect_intra_doc_links.rs +++ b/src/librustdoc/passes/collect_intra_doc_links.rs `@@` -433,8 +433,9 `@@` impl<'a, 'tcx> LinkCollector<'a, 'tcx> { Res::PrimTy(prim) => Some( self.resolve_primitive_associated_item(prim, ns, module_id, item_name, item_str), ), - Res::Def(DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::TyAlias, did) => { + Res::Def(kind, did) if kind.ns() == Some(Namespace::TypeNS) => { debug!("looking for associated item named {} for item {:?}", item_name, did); + // Checks if item_name belongs to `impl SomeItem` let assoc_item = cx .tcx ``` However, this caused traits to be matched, resulting in a panic when `resolve_associated_trait_item` is called further down in this function. This PR also adds an error message for that panic. Currently it will look something like: ```rust thread 'rustc' panicked at 'Not a type: DefIndex(8624)', compiler/rustc_metadata/src/rmeta/decoder.rs:951:32 ``` I wasn't sure how to get a better debug output than `DefIndex(...)`, and am open to suggestions.
Exhaustively match in variant count instrinsic Fix rust-lang#79137
Direct RUSTC_LOG (tracing/log) output to stderr instead of stdout. Looks like this got missed in the initial implementation, AFAIK the old behavior was to output on stderr. (Hit this while trying to debug `rustc` running inside a build script which was only letting stderr through) r? ``@oli-obk`` cc ``@davidbarsky`` ``@hawkw``
Get rid of some doctree items They can be derived directly from the `hir::Item`, there's no special logic. - TypeDef - OpaqueTy - Constant - Static - TraitAlias - Enum - Union - Struct Part of rust-lang#78082 (the easiest part, I'm still debugging some other changes). r? `@GuillaumeGomez`
Support building clone shims for arrays with generic size Fixes rust-lang#79269.
|
@bors r+ rollup=never p=8 |
|
📌 Commit 68c9caa has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
This was a moderate regression in instruction counts (up to 1.8% on full builds of coercions-debug). I think #79067 might be to blame, since most of the regressions are in codegen. @bjorn3 do you know anything in that PR that could have caused a codegen regression? Maybe LLVM is missing some optimizations? |
|
I think that's a false positive. There's no regression on coercions-check or coercions-opt. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup