Auto merge of #26473 - Eljay:missing_docs, r=alexcrichton
Fixes #24249
I've tagged all items that were missing docs to allow them to compile for now, the ones in core/num should probably be documented at least.
This is also a breaking change for any crates using `#[deny(missing_docs)]` that have undocumented constants, not sure there is any way to avoid this without making it a separate lint?
Auto merge of #26694 - eddyb:method-nan, r=arielb1
`MethodCallee` now has no information about the method, other than its `DefId`.
The previous bits of information can be recovered as follows:
```rust
let method_item = tcx.impl_or_trait_item(callee.def_id);
let container = method_item.container();
```
The method is inherent if `container` is a `ty::ImplContainer`:
* the `impl` the method comes from is `container.id()`
The method is a trait method if `container` is a `ty::TraitContainer:
* the `trait` the method is part of is `container.id()`
* a `ty::TraitRef` can be constructed by putting together:
* `container.id()` as the `trait` ID
* `callee.substs.clone().method_to_trait()` as the `trait` substs (including `Self`)
* the above `trait_ref` is a valid `T: Trait<A, B, C>` predicate
* selecting `trait_ref` could result in one of the following:
* `traits::VtableImpl(data)`: static dispatch to `data.impl_def_id`
* `traits::VtableObject(data)`: dynamic dispatch, with the vtable index:
`traits::get_vtable_index_of_object_method(tcx, data, callee.def_id)`
* other variants of `traits::Vtable`: various other `impl` sources
Documentation claims it panics on out of bounds -- it regards out of
bounds as just not a char boundary.
core::str module is aware of how it works and uses it appropriately.
Maybe we should rename it to `is_valid_index`, `is_slicable_index`, or
something similar.
Auto merge of #26370 - nikomatsakis:better-object-defaults-warn, r=nikomatsakis
This is an implementation of RFC rust-lang/rfcs#1156. It includes the code to implement the new rules, but that code is currently disabled. It also includes code to issue warnings when the change will cause breakage. These warnings try hard to be targeted but are also somewhat approximate. They could, with some effort, be made *more* targeted by adjusting the code in ty_relate that propagates the "will change" flag to consider the specific operation. Might be worth doing.
r? @pnkfelix (I think you understand region inference best)
Niko Matsakis [Wed, 17 Jun 2015 14:08:26 +0000 (10:08 -0400)]
After inferring regions, scan for any bounds that are due to a lifetime
bound that is likely to change. In that case, it will change to 'static,
so then scan down the graph to see whether there are any hard
constraints that would prevent 'static from being a valid value
here. Report a warning.
Niko Matsakis [Wed, 17 Jun 2015 13:11:34 +0000 (09:11 -0400)]
Add a boolean flag to ExistentialBounds tracking whether the
region-bound is expected to change in Rust 1.3, but don't use it for
anything in this commit. Note that this is not a "significant" part of
the type (it's not part of the formal model) so we have to normalize
this away or trans starts to get confused because two equal types wind
up with distinct LLVM types.
Auto merge of #26610 - aturon:fix_make_unique, r=alexcrichton
This commit resolves the race condition in the `get_mut` and
`make_unique` functions, which arose through interaction with weak
pointers. The basic strategy is to "lock" the weak pointer count when
trying to establish uniqueness, by reusing the field as a simple
spinlock. The overhead for normal use of `Arc` is expected to be minimal
-- it will be *none* when only strong pointers are used, and only
requires a move from atomic increment to CAS for usage of weak pointers.
The commit also removes the `unsafe` and deprecated status of these functions.
Aaron Turon [Fri, 26 Jun 2015 21:32:34 +0000 (14:32 -0700)]
Fix race condition in Arc's get_mut and make_unqiue
This commit resolves the race condition in the `get_mut` and
`make_unique` functions, which arose through interaction with weak
pointers. The basic strategy is to "lock" the weak pointer count when
trying to establish uniqueness, by reusing the field as a simple
spinlock. The overhead for normal use of `Arc` is expected to be minimal
-- it will be *none* when only strong pointers are used, and only
requires a move from atomic increment to CAS for usage of weak pointers.
The commit also removes the `unsafe` and deprecated status of these
functions.
Along the way, the commit also improves several memory orderings, and
adds commentary about why various orderings suffice.
Auto merge of #26738 - dotdash:trans_args, r=luqmana
The current split between create_datums_for_fn_args, copy_args_to_allocas and
store_arg involves a detour via rvalue datums which cause additional work in
form of insertvalue/extractvalue pairs for fat pointer arguments, and an extra
alloca and memcpy for tupled args in rust-call functions.
By merging those three functions into just one that actually covers the whole
process of creating the final argument datums, we can skip all that. Also,
this allows to easily merge in the handling of rust-call functions, allowing to
make create_datum_for_fn_args_under_call_abi obsolete.
cc #26600 -- The insertvalue instructions kicked us off of fast-isel.
Directly construct lvalue datums for function arguments
The current split between create_datums_for_fn_args,
copy_args_to_allocas and store_arg involves a detour via rvalue datums
which cause additional work in form of insertvalue/extractvalue pairs
for fat pointer arguments, and an extra alloca and memcpy for tupled
args in rust-call functions.
By merging those three functions into just one that actually covers the
whole process of creating the final argument datums, we can skip all
that. Also, this allows to easily merge in the handling of rust-call
functions, allowing to make create_datum_for_fn_args_under_call_abi
obsolete.
cc #26600 -- The insertvalue instructions kicked us off of fast-isel.
Skip the pointless tupling/untupling of argument types in trans_closure
The tupling only happens for actual closures, same for the untupling.
The only code that actually sees the tupled types is some debugging
output for which it is actually rather confusing to have the types
tupled, because neither the function signature in Rust nor the
function signature for LLVM has them tupled.
Auto merge of #26718 - nham:test-8640, r=alexcrichton
This doesn't add a test for the main problem in #8640 since it seems that
was already fixed (including a test) in PR https://github.com/rust-lang/rust/pull/19522. This just adds a test
for a program mentioned in the comments that used to erroneously compile.
Auto merge of #26677 - jroesch:fulfillment-context-refactor, r=nrc
This patch implements the next chunk of flattening out the type checking context. In a series of patches I moved around the necessary state and logic in order to delete the `Typer` and `ClosureTyper` traits. My next goal is to clean the interfaces and start to move the normalization code behind them.
r? @nrc I hope my PR is coherent, doing this too late at night ;)
Auto merge of #26658 - alexcrichton:windows-net-no-inherit, r=aturon
This was added after Windows 7 SP1, so it's not always available. Instead use
the `SetHandleInformation` function to flag a socket as not inheritable. This is
not atomic with respect to creating new processes, but it mirrors what Unix does
with respect to possibly using the atomic option in the future.
projects / rust.git / log