| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update E0005 to use a label
Fixes #35192 as Part of #35233
r? @jonathandturner
|
|
update E0409 to new error format
fixes #35699 as part of #35233.
r? @jonathandturner
|
|
Updated E0394 & E0422 to new format
Fixes #35692 and #35700, as part of #35233.
r? @jonathandturner
|
|
Use UI test to test spans, instead of forced line break
There must be lots more, but these are what I could easily find.
|
|
RUST_NEW_ERROR_FORMAT is no more
So stop setting the environment variable.
|
|
Implement `Debug` for `std::vec::IntoIter`.
Display all the remaining items of the iterator, similar to the `Debug`
implementation for `core::slice::Iter`:
https://github.com/rust-lang/rust/blob/f0bab98695f0a4877daabad9a5b0ba3e66121392/src/libcore/slice.rs#L930-L937
Using the `as_slice` method that was added in:
https://github.com/rust-lang/rust/pull/35447
|
|
r=GuillaumeGomez
accumulate into vector and assert, instead of printing
I'm only making this change in one place so that people can express
their preferences for this stylistic change. If/when this change is
approved I'll go ahead and translate the rest of the `std::ops`
examples.
|
|
expound on limitations of Rust's trait-based operator overloading
Part of #29330
|
|
update E0375 to new format
fixes #35635 as part of #35233.
r? @jonathandturner
|
|
Fix spacing in code of closures.md
The spacing seems inconsistent with existing style conventions.
|
|
Update E0322 to new format
Fixes #35323. Part of #35233.
r? @GuillaumeGomez
|
|
Update E0392 to new error format
Fixes #35631. Part of #35233
r? @jonathandturner or @GuillaumeGomez
|
|
Update error E0365 to new format
Fixes #35633 as part of #35233.
r? @jonathandturner
|
|
Improve `No stdlib` and related Documentation
This renames all lang item function names to the ones used in `libstd` and `libpanic_unwind`. It also explains the `eh_unwind_resume` lang item in the `libcore` documentation, where it was missing. A third function is also needed on certain compilation targets, so this was also added to the `No stdlib` documentation.
|
|
Update E0207 label to report parameter type
Fixes #35642.
r? @jonathandturner (Is this okay? I tagged you since it's a simple error fix similar to the other update ones.)
|
|
Add doc example for `std::ffi::CString::from_vec_unchecked`.
None
|
|
run rustfmt on libsyntax_ext folder
|
|
r=steveklabnik
provide additional justification for array interface design
Explain why Rust does not implement traits for large arrays.
Explain why most methods are implemented on slices rather than arrays.
Note: I'm dipping my toes in the water with a tiny PR. Especially looking for feedback on wording and style. Points of concern: appropriate level of top-level explanation; foreshadowing (is it appropriate to imply that we expect Rust's type system to eventually support size-generic arrays?); using `Foo` and `Bar` as type variables instead of e.g. `T` and `S`.
@peschkaj
|
|
r=steveklabnik
Add note to docs for &str that example is to demo internals only
r? @steveklabnik
This adds a note below the &str representation example explaining that the example provided should not be used under normal circumstances..
Would it make sense to point people in the direction of the method(s) they should use instead? I left it out in the interest of not complicating the documentation, but, there's definitely an argument to be made for adding a bit of guidance in there.
|
|
Clarify type declaration language in Associated Types docs
A small fix for the Associated Types docs
r? @steveklabnik
|
|
Update compiler error 0030 to use new error format.
Part of #35233,
Addresses #35204
r? @jonathandturner
|
|
A disclaimer about keywords.
Some people cite this list as "zomg Rust has so many keywords," so make
it clear that these aren't all used by the language today.
|
|
Remove the ParamSpace separation from formal and actual generics in rustc.
This is the first step towards enabling the typesystem implemented by `rustc` to be extended
(with generic modules, HKT associated types, generics over constants, etc.).
The current implementation splits all formal (`ty::Generics`) and actual (`Substs`) lifetime and type parameters (and even `where` clauses) into 3 "parameter spaces":
* `TypeSpace` for `enum`, `struct`, `trait` and `impl`
* `SelfSpace` for `Self` in a `trait`
* `FnSpace` for functions and methods
For example, in `<X as Trait<A, B>>::method::<T, U>`, the `Substs` are `[[A, B], [X], [T, U]]`.
The representation uses a single `Vec` with 2 indices where it's split into the 3 "parameter spaces".
Such a simplistic approach doesn't scale beyond the Rust 1.0 typesystem, and its existence was mainly motivated by keeping code manipulating generic parameters correct, across all possible situations.
Summary of changes:
* `ty::Generics` are uniformly stored and can be queried with `tcx.lookup_generics(def_id)`
* the `typeck::collect` changes for this resulted in a function to lazily compute the `ty::Generics` for a local node, given only its `DefId` - this can be further generalized to other kinds of type information
* `ty::Generics` and `ty::GenericPredicates` now contain only their own parameters (or `where` clauses, respectively), and refer to their "parent", forming a linked list
* right now most items have one level of nesting, only associated items and variants having two
* in the future, if `<X as mod1<A>::mod2<B>::mod3::Trait<C>>::Assoc<Y>` is supported, it would be represented by item with the path `mod1::mod2::mod3::Trait::Assoc`, and 4 levels of generics: `mod1` with `[A]`, `mod2` with `[B]`, `Trait` with `[X, C]` and `Assoc` with `[Y]`
* `Substs` gets two new APIs for working with arbitrary items:
* `Substs::for_item(def_id, mk_region, mk_type)` will construct `Substs` expected by the definition `def_id`, calling `mk_region` for lifetime parameters and `mk_type` for type parameters, and it's guaranteed to *always* return `Substs` compatible with `def_id`
* `substs.rebase_onto(from_base_def_id, to_base_substs)` can be used if `substs` is for an item nested within `from_base_def_id` (e.g. an associated item), to replace the "outer parameters" with `to_base_substs` - for example, you can translate a method's `Substs` between a `trait` and an `impl` (in both directions) if you have the `DefId` of one and `Substs` for the other
* trait objects, without a `Self` in their `Substs`, use *solely* `ExistentialTraitRef` now, letting `TraitRef` assume it *always* has a `Self` present
* both `TraitRef` and `ExistentialTraitRef` get methods which do operations on their `Substs` which are valid only for traits (or trait objects, respectively)
* `Substs` loses its "parameter spaces" distinction, with effectively no code creating `Substs` in an ad-hoc manner, or inspecting them, without knowing what shape they have already
Future plans:
* combine both lifetimes and types in a single `Vec<Kind<'tcx>>` where `Kind` would be a tagged pointer that can be `Ty<'tcx>`, `&'tcx ty::Region` or, in the future, potentially-polymorphic constants
* this would require some performance investigation, if it implies a lot of dynamic checks
* introduce an abstraction for `(T, Substs)`, where the `Substs` are even more hidden away from code
manipulating it; a precedent for this is `Instance` in trans, which has `T = DefId`; @nikomatsakis also referred to this, as "lazy substitution", when `T = Ty`
* rewrite type pretty-printing to fully take advantage of this to inject actual in the exact places of formal generic parameters in any paths
* extend the set of type-level information (e.g. beyond `ty::Generics`) that can be lazily queried during `typeck` and introduce a way to do those queries from code that can't refer to `typeck` directly
* this is almost unrelated but is necessary for DAG-shaped recursion between constant evaluation and type-level information, i.e. for implementing generics over constants
r? @nikomatsakis
cc @rust-lang/compiler
cc @nrc Could get any perf numbers ahead of merging this?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement `AsRef<[T]>` for `std::slice::Iter`.
`AsRef` is designed for conversions that are "cheap" (as per
the API docs). It is the case that retrieving the underlying
data of `std::slice::Iter` is cheap. In my opinion, there's no
ambiguity about what slice data will be returned, otherwise,
I would be more cautious about implementing `AsRef`.
|
|
Kicking off libproc_macro
This PR introduces `libproc_macro`, which is currently quite bare-bones (just a few macro construction tools and an initial `quote!` macro).
This PR also introduces a few test cases for it, and an additional `shim` file (at `src/libsyntax/ext/proc_macro_shim.rs` to allow a facsimile usage of Macros 2.0 *today*!
|
|
|
|
|
|
Made vec_deque::Drain, hash_map::Drain, and hash_set::Drain covariant
Fixed the rest of the Drain iterators.
|
|
|
|
|
|
|
|
|
|
exclude `#![no_builtins]` crates from LTO
this prevents intrinsics like `memcpy` from being mis-optimized to
infinite recursive calls when LTO is used.
fixes #31544
closes #35540
---
r? @alexcrichton
cc @Amanieu
|
|
|
|
`AsRef` is designed for conversions that are "cheap" (as per
the API docs). It is the case that retrieving the underlying
data of `std::slice::Iter` is cheap. In my opinion, there's no
ambiguity about what slice data will be returned, otherwise,
I would be more cautious about implementing `AsRef`.
|
|
Fix incorrect unused import warnings on `cfg_attr`ed `path` attributes
Fixes #35584.
r? @eddyb
|
|
|
|
|
