-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #79273
Rollup of 8 pull requests #79273
Conversation
…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 |
☀️ 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. |
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup