Rollup merge of #74374 - cuviper:lto-bitcode-1.45, r=Mark-Simulacrum
Add a 1.45 release note on lto vs. embed-bitcode
I added a bullet for Cargo's use of `embed-bitcode`, since that was even noteworthy enough for the Inside Rust blog. Then more importantly, I added a compatibility note for how this may interact poorly with manually enabling LTO.
Rollup merge of #74337 - estebank:ty-parse-recovery, r=varkor
Handle case of incomplete local ty more gracefully
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
Rollup merge of #74294 - msirringhaus:master, r=pietroalbini
Update cross-compilation README
README seemed rather out of date. I hope the information in my PR is now correct (it was more or less assembled by asking in zulip and learning-by-doing).
Rollup merge of #74276 - lcnr:discriminant-kind-what, r=nagisa
improve DiscriminantKind handling
Adds a lang item `discriminant_type` for the associated type `DiscriminantKind::Discriminant`.
Changes the discriminant of generators from `i32` to `u32`, which should not be observable to fix an
oversight where MIR was using `u32` and codegen and typeck used `i32`.
Rollup merge of #74218 - GuillaumeGomez:search-results-bottom-margin, r=Dylan-DPC
Add margin after doc search results
I found it not really on computer that the last result is right at the bottom of the page. I find it better with margin below (especially when you hover the last element!). A screenshot to show the result:
Auto merge of #74113 - lcnr:type-dependent-consts-2, r=eddyb
Support const args in type dependent paths (Take 2)
once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154
-----
```rust
#![feature(const_generics)]
struct A;
impl A {
fn foo<const N: usize>(&self) -> usize { N }
}
struct B;
impl B {
fn foo<const N: usize>(&self) -> usize { 42 }
}
fn main() {
let a = A;
a.foo::<7>();
}
```
When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type.
This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` ->
`type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290)
To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by
calling `type_of(param_def_id)` instead.
We have to somehow remember the `DefId` of the param through all of typeck, which is done using the
struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to
be able to store the const parameter in case it exists.
Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`.
For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`.
This now reuses `fn discriminant_ty` in project, removing
some code duplication. Doing so made me realize that
we previously had a disagreement about the discriminant
type of generators, with MIR using `u32` and codegen and
trait selection using `i32`.
Auto merge of #71272 - jclulow:illumos-x86-ci, r=pietroalbini
build dist for x86_64-unknown-illumos
This change creates a new Docker image, "dist-x86_64-illumos", and sets
things up to build the full set of "dist" packages for illumos hosts, so
that illumos users can use "rustup" to install packages. It also
adjusts the manifest builder to expect complete toolchains for this
platform.
Handle case of incomplete local ty more gracefully
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
Rollup merge of #74340 - davidtwco:issue-73747-improper-ctypes-defns-is-zst-with-params, r=pnkfelix
lint: use `transparent_newtype_field` to avoid ICE
Fixes #73747.
This PR re-uses the `transparent_newtype_field` function instead of manually calling `is_zst` on normalized fields to determine which field in a transparent type is the non-zero-sized field, thus avoiding an ICE.
Rollup merge of #74263 - RalfJung:thread-local, r=Mark-Simulacrum
Slight reorganization of sys/(fast_)thread_local
I was long confused by the `thread_local` and `fast_thread_local` modules in the `sys(_common)` part of libstd. The names make it *sound* like `fast_thread_local` is just a faster version of `thread_local`, but really these are totally different APIs: one provides thread-local "keys", which are non-addressable pointer-sized pieces of local storage with an associated destructor; the other (the "fast" one) provides just a destructor.
So I propose we rename `fast_thread_local` to `thread_local_dtor`, and `thread_local` to `thread_local_key`. That's what this PR does.
Rollup merge of #74252 - shepmaster:bootstrap-rust-destdir, r=Mark-Simulacrum
Don't allow `DESTDIR` to influence LLVM builds
When running a command like `DESTDIR=foo x.py install` in a completely
clean build directory, this will cause LLVM to be installed into
`DESTDIR`, which then causes the build to fail later when it attempts
to *use* those LLVM files.
David Wood [Tue, 14 Jul 2020 18:26:34 +0000 (19:26 +0100)]
lint: use `transparent_newtype_field` to avoid ICE
This commit re-uses the `transparent_newtype_field` function instead of
manually calling `is_zst` on normalized fields to determine which field
in a transparent type is the non-zero-sized field, thus avoiding an ICE.
When encountering a unit or tuple pattern for a struct-like item, suggest
using the correct pattern.
Use `insert_field_names_local` when evaluating variants and store field
names even when the list is empty in order to produce accurate
structured suggestions.
Auto merge of #74330 - Manishearth:rollup-mrc09pb, r=Manishearth
Rollup of 15 pull requests
Successful merges:
- #71237 (Add Ayu theme to rustdoc)
- #73720 (Clean up E0704 error explanation)
- #73866 (Obviate #[allow(improper_ctypes_definitions)])
- #73965 (typeck: check for infer before type impls trait)
- #73986 (add (unchecked) indexing methods to raw (and NonNull) slices)
- #74173 (Detect tuple struct incorrectly used as struct pat)
- #74220 (Refactor Windows `parse_prefix`)
- #74227 (Remove an unwrap in layout computation)
- #74239 (Update llvm-project to latest origin/rustc/10.0-2020-05-05 commit )
- #74257 (don't mark linux kernel module targets as a unix environment)
- #74270 (typeck: report placeholder type error w/out span)
- #74296 (Clarify the description for rfind)
- #74310 (Use `ArrayVec` in `SparseBitSet`.)
- #74316 (Remove unnecessary type hints from Wake internals)
- #74324 (Update Clippy)
Rollup merge of #74324 - flip1995:clippyup, r=Manishearth
Update Clippy
~~I'm not sure, if we can/should land this before beta is branched.~~ (Nvm, beta is already branched) The last Clippy update was 3 weeks ago: #73660
This includes, besides other minor things:
- New lints
- One lint deprecation
- One lint was moved to pedantic
- Some FP fixes
- I think an ICE fix?
cc @Mark-Simulacrum
r? @Manishearth
---
We probably should also think of some process when and how often we should sync Clippy to the rust repo, so that we don't end up with those huge updates. Maybe every 2 weeks? Or even every week? cc @rust-lang/clippy
Rollup merge of #74316 - yoshuawuyts:no-wake-type-hints, r=Mark-Simulacrum
Remove unnecessary type hints from Wake internals
While working on https://github.com/rust-lang/rust/pull/74304 I noticed we were writing out the type signature twice in some internal `Wake` impl methods; this streamlines that. Thanks!
Rollup merge of #74270 - davidtwco:issue-74086-more-placeholder-type-error, r=estebank
typeck: report placeholder type error w/out span
Fixes #74086.
This PR fixes a regression introduced in rust-lang/rust#70369 which meant that an error was not being emitted for invalid placeholder types when there wasn't a span available.
projects / rust.git / log