| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add special error for this case and help message `please recompile this crate using --crate-type lib`, also list found candidates.
See issue #14416
r? @alexcrichton
|
|
closes #21630
Overloaded indexing (`&[mut] foo[bar]`) only works when `<Self as Index>::Output` is the same as `<Self as IndexMut>::Output` (see issue above). To restrict implementations of `IndexMut` that doesn't work, this PR makes `IndexMut` a supertrait over `Index`, i.e. `trait IndexMut<I>: Index<I>`, just like in the `trait DerefMut: Deref` case.
This breaks all downstream implementations of `IndexMut`, in most cases this simply means removing the `type Output = ..` bit, which is now redundant, from `IndexMut` implementations:
``` diff
impl Index<Foo> for Bar {
type Output = Baz;
..
}
impl IndexMut<Foo> for Bar {
- type Output = Baz;
..
}
```
[breaking-change]
---
r? @nikomatsakis
|
|
closes #21630
|
|
It's in order to make the code more homogeneous.
|
|
Fixes run build error
Fix test failure
Fix tests' errors
|
|
If you were still using `MaybeOwnedVector`, update your code to use `CowVec`.
[breaking-change]
---
We already removed `MaybeOwned` (the string equivalent) long time ago and with a much shorter deprecation period. It's time to let go.
|
|
|
|
r=pnkfelix
We were already building a hashset to check for duplicates, but we assumed that the initial vector had no duplicates. Fixes #21965.
r? @pnkfelix
|
|
Also added test for it.
Fixes #21928
|
|
....
The 'stable_features' lint helps people progress from unstable to
stable Rust by telling them when they no longer need a `feature`
attribute because upstream Rust has declared it stable.
This compares to the existing 'unstable_features' lint, which is used
to implement feature staging, and triggers on *any* use
of `#[feature]`.
|
|
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
r? @alexcrichton
|
|
Just spelling corrections.
|
|
r=huonw
Ported regions-mock-tcx to use TypedArena rather than Arena since it holds cyclic structure (which the Arena API updated for the Drop-Check-Rule cannot handle).
Plus, the use of `arena::Arena` here really is not justified; the allocated values are all the same type anyway.
|
|
Creating two identical static expressions involving casts of pointers to arrays
caused an assertion failure in librustc_trans.
cc @eddyb
|
|
Implement step 1 of rust-lang/rfcs#702
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
|
|
|
|
Creating two identical static expressions involving casts of pointers to arrays
caused an assertion failure in librustc_trans.
|
|
cyclic structure (which the Arena API updated for dropck cannot handle).
|
|
This restructures tidy.py to walk the tree itself,
and improves performance considerably by not loading entire
files into buffers for licenseck.
Splits build rules into 'tidy', 'tidy-basic', 'tidy-binaries',
'tidy-errors', 'tidy-features'.
|
|
|
|
this overeager code that was pruning out ambig where-clause matches in trait selection. cc #21974.
|
|
|
|
|
|
Update tests to change all `&expr[]` to `&expr[..]` to make sure pretty printing
passes.
|
|
Fixes #21965.
|
|
Also added test for it.
Fixes #21928
|
|
The 'stable_features' lint helps people progress from unstable to
stable Rust by telling them when they no longer need a `feature`
attribute because upstream Rust has declared it stable.
This compares to the existing 'unstable_features', which is used
to implement feature staging, and triggers on *any* use
of `#[feature]`.
|
|
Just spelling corrections.
|
|
|
|
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
|
|
Closes #8706.
|
|
Use [`rand`](https://crates.io/crates/rand) and [`derive_rand`](https://crates.io/crates/derive_rand) from crates.io.
[breaking-change]
|
|
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
|
|
Currently, if a `#![staged_api]` crate contains an exported item without a stability marker (or inherited stability),
the item is useless.
This change introduces a check to ensure that all exported items have a defined stability.
it also introduces the `unmarked_api` feature, which lets users import unmarked features. While this PR should in theory forbid these from existing,
in practice we can't be so sure; so this lets users bypass this check instead of having to wait for the library and/or compiler to be fixed (since otherwise this is a hard error).
r? @aturon
|
|
This *almost* completes the job for #16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done.
As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.)
This commit does not *quite* fix #16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends.
r? @eddyb as he reviewed the prior patch in this direction
|
|
Implements [RFC 474](https://github.com/rust-lang/rfcs/pull/474); see
that RFC for details/motivation for this change.
This initial commit does not include additional normalization or
platform-specific path extensions. These will be done in follow up
commits or PRs.
|
|
Use the crates.io crate `rand` (version 0.1 should be a drop in
replacement for `std::rand`) and `rand_macros` (`#[derive_Rand]` should
be a drop-in replacement).
[breaking-change]
|
|
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.
[breaking-change]
|
|
|
|
|
|
closure kind, thereby detecting what happens if there are
mismatches. Simply removing the `:` annotations caused most of these
tests to pass or produce other errors, because the inference would
convert the closure into a more appropriate kind. (The ability to
override the inference by using the expected type is an important
backdoor partly for this reason.)
|
|
possible. There is some amount of duplication as a result (similar to
select) -- I am not happy about this but not sure how to fix it
without deeper rewrites.
|
|
a trait obligation. Partial fix for #16440 -- closure return types are
not handled yet.
|
|
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes #21420.
|
|
Closes #8706.
|
|
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes #21420.
|
|
|
|
syntax like `use foo::bar::;` and `use foo:: as bar;` should be rejected, see issue #21629
|
|
Conflicts:
src/librustc/metadata/filesearch.rs
src/librustc_back/target/mod.rs
src/libstd/os.rs
src/libstd/sys/windows/os.rs
src/libsyntax/ext/tt/macro_parser.rs
src/libsyntax/print/pprust.rs
src/test/compile-fail/issue-2149.rs
|
|
For "symmetric" binary operators, meaning the types of two sides must be
equal, if the type of LHS doesn't know yet but RHS does, use that as an
hint to infer LHS' type.
Closes #21634
|
