- 19 3月, 2019 14 次提交
-
-
由 Mazdak Farrokhzad 提交于
Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs Many docs examples use explicit types instead of the semantically more clear `Self`/`Self::…` aliases. By using the latter it's clear that the value's type depends on either `Self`, or an associated type of `Self`, instead of some constant type. It's also more consistent (and I'd argue correct), as the current docs aren't really consistent in this, as can be seen from the diff. This is a best effort PR, as I was basically going through the docs manually, looking for offending examples. I'm sure I missed a few. Gotta start somewhere.
-
由 Mazdak Farrokhzad 提交于
add self to mailmap
-
由 Mazdak Farrokhzad 提交于
Be more discerning on when to attempt suggesting a comma in a macro invocation Fix #58796.
-
由 Mazdak Farrokhzad 提交于
Fix a tiny error in documentation of std::pin. `new_unmoved` must be `mut` for passing to `std::mem::swap`.
-
由 Mazdak Farrokhzad 提交于
Clarify distinction between floor() and trunc() `floor()` rounds towards `-INF`, `trunc()` rounds towards 0. This PR clarifies this in the examples.
-
由 Mazdak Farrokhzad 提交于
Implement ExactSizeIterator for ToLowercase and ToUppercase
-
由 Mazdak Farrokhzad 提交于
dbg!() without parameters Fixes #57845.
-
由 Mazdak Farrokhzad 提交于
Rollup merge of #57729 - pnkfelix:issue-55748-pat-types-are-constraints-on-bindings-too, r=nikomatsakis extra testing of how NLL handles wildcard type `_` test that wildcard type `_` is not duplicated by `type Foo<X> = (X, X);` and potentially instantiated at different types when used in type ascriptions in let bindings. (NLL's handling of this for the type ascription *expression form* is currently broken, or at least differs from what AST-borrowck does. I'll file a separate bug about that. Its not something critical to address since that expression is guarded by `#![feature(type_ascription)]`.) cc #55748
-
由 Mazdak Farrokhzad 提交于
Add todo!() macro The primary use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro. EDIT: hide unpopular proposal about re-purposing unimplemented <details> However, instead of just replacing `unimplemented!()`, it gives it a more nuanced meaning: a thing which is intentionally left unimplemented and which should not be called at runtime. Usually, you'd like to prevent such cases statically, but sometimes you, for example, have to implement a trait only some methods of which are applicable. There are examples in the wild of code doing this thing, and in this case, the current message of `unimplemented`, "not *yet* implemented" is slightly misleading. With the addition of TODO, you have three nuanced choices for a `!`-returning macro (in addition to a good-old panic we all love): * todo!() * unreachable!() * unimplemented!() Here's a rough guideline what each one means: - `todo`: use it during development, as a "hole" or placeholder. It might be a good idea to add a pre-commit hook which checks that `todo` is not accidentally committed. - `unreachable!()`: use it when your code can statically guarantee that some situation can not happen. If you use a library and hit `unreachable!()` in the library's code, it's definitely a bug in the library. It's OK to have `unreachable!()` in the code base, although, if possible, it's better to replace it with compiler-verified exhaustive checks. - `unimplemented!()`: use it when the type checker forces you to handle some situation, but there's a contract that a callee must not actually call the code. If you use a library and hit `unimplemented!()`, it's probably a bug in your code, though it *could* be a bug in the library (or library docs) as well. It is ok-ish to see an `unimplemented!()` in real code, but it usually signifies a clunky, eyebrow-rising API. </details>
-
由 Konrad Borowski 提交于
This functionality was added in 1.35.0, not 1.34.0.
-
由 bors 提交于
Update clippy Fixes https://github.com/rust-lang/rust/issues/59218 cc @Xanewok
-
由 bors 提交于
Define queries using a proc macro cc @rust-lang/compiler
-
由 Mateusz Mikuła 提交于
-
由 Aleksey Kladov 提交于
The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.
-
- 18 3月, 2019 13 次提交
-
-
由 John Kåre Alsaker 提交于
-
由 Vincent Esche 提交于
-
由 bors 提交于
Remove metadata only codegen backend It is unused and probably broken at the moment.
-
由 bors 提交于
Adds help message in error for invalid `impl for T` syntax Fixes #56031.
-
由 John Kåre Alsaker 提交于
-
由 John Kåre Alsaker 提交于
-
由 John Kåre Alsaker 提交于
-
由 bors 提交于
overhaul intra-doc-link ambiguity warning Fixes #52784. - Makes the warning part of the `intra_doc_link_resolution_failure` lint. - Tightens the span to just the ambiguous link. - Reports ambiguities across all three namespaces. - Uses structured suggestions for disambiguation. - Adds a test for the warnings. r? @QuietMisdreavus
-
由 bors 提交于
Filter ui revision tests Updates UI test output filtering to also filter away test annotations for revisions: Previously filtered: //~ ERROR [XXXX] Now also filters: //[revision]~ ERROR [XXXX] I reckon, if we have the one, we should have the other for consistency, its lack was probably an oversight (the existence of revision testing is not really well documented...)
-
由 bors 提交于
Hide deprecation warnings inside derive expansions Fixes #58822
-
由 bors 提交于
resolve: Account for new importable entities Fixes the ICE encountered in https://github.com/rust-lang/rust/pull/58837 r? @Centril
-
由 Mathias Blikstad 提交于
-
由 Mathias Blikstad 提交于
-
- 17 3月, 2019 13 次提交
-
-
由 bors 提交于
Revert the `LazyConst` PR The introduction of `LazyConst` did not actually achieve the code simplicity improvements that were the main reason it was introduced. Especially in the presence of const generics, the differences between the "levels of evaluatedness" of a constant become less clear. As it can be seen by the changes in this PR, further simplifications were possible by folding `LazyConst` back into `ConstValue`. We have been able to keep all the advantages gained during the `LazyConst` refactoring (like `const_eval` not returning an interned value, thus making all the `match` code simpler and more performant). fixes https://github.com/rust-lang/rust/issues/59209 r? @EddyB @varkor
-
由 Bastian Kauschke 提交于
-
由 Mathias Blikstad 提交于
-
由 Oliver Scherer 提交于
-
由 bors 提交于
Do not accidentally treat multi-segment meta-items as single-segment Fixes https://github.com/rust-lang/rust/issues/55168 and many other regressions from https://github.com/rust-lang/rust/pull/50030 Basically, attributes like `#[any::prefix::foo]` were commonly interpreted as `#[foo]` due to `name()` successfully returning the last segment (this applies to nested things as well `#[attr(any::prefix::foo)]`).
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Remove methods `Attribute::span` and `MetaItem::span` duplicating public fields
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Tweak some error wording
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Oliver Scherer 提交于
-