bors [Wed, 16 May 2018 17:15:37 +0000 (17:15 +0000)]
Auto merge of #49479 - nox:merge-funcs, r=nagisa
Reenable the MergeFunctions pass
The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc
pass enabled and it hugely reduces code size (for example it shaves off 10% of the
final Servo executable). This patch reenables it.
For those wondering, [here are the docs from LLVM about this pass](http://llvm.org/docs/MergeFunctions.html).
bors [Wed, 16 May 2018 11:18:05 +0000 (11:18 +0000)]
Auto merge of #50473 - petrochenkov:pmapi, r=alexcrichton
Review proc macro API 1.2
cc https://github.com/rust-lang/rust/issues/38356
Summary of applied changes:
- Documentation for proc macro API 1.2 is expanded.
- Renamed APIs: `Term` -> `Ident`, `TokenTree::Term` -> `TokenTree::Ident`, `Op` -> `Punct`, `TokenTree::Op` -> `TokenTree::Punct`, `Op::op` -> `Punct::as_char`.
- Removed APIs: `Ident::as_str`, use `Display` impl for `Ident` instead.
- New APIs (not stabilized in 1.2): `Ident::new_raw` for creating a raw identifier (I'm not sure `new_x` it's a very idiomatic name though).
- Runtime changes:
- `Punct::new` now ensures that the input `char` is a valid punctuation character in Rust.
- `Ident::new` ensures that the input `str` is a valid identifier in Rust.
- Lifetimes in proc macros are now represented as two joint tokens - `Punct('\'', Spacing::Joint)` and `Ident("lifetime_name_without_quote")` similarly to multi-character operators.
- Stabilized APIs: None yet.
A bit of motivation for renaming (although it was already stated in the review comments):
- With my compiler frontend glasses on `Ident` is the single most appropriate name for this thing, *especially* if we are doing input validation on construction. `TokenTree::Ident` effectively wraps `token::Ident` or `ast::Ident + is_raw`, its meaning is "identifier" and it's already named `ident` in declarative macros.
- Regarding `Punct`, the motivation is that `Op` is actively misleading. The thing doesn't mean an operator, it's neither a subset of operators (there is non-operator punctuation in the language), nor superset (operators can be multicharacter while this thing is always a single character). So I named it `Punct` (first proposed in [the original RFC](https://github.com/rust-lang/rfcs/pull/1566), then [by @SimonSapin](https://github.com/rust-lang/rust/issues/38356#issuecomment-276676526)) , together with input validation it's now a subset of ASCII punctuation character category (`u8::is_ascii_punctuation`).
bors [Wed, 16 May 2018 09:03:38 +0000 (09:03 +0000)]
Auto merge of #48557 - matthewjasper:allow-trvial-bounds, r=nikomatsakis
Implement RFC 2056 trivial constraints in where clauses
This is an implementation of the new behaviour for #48214. Tests are mostly updated to show the effects of this. Feature gate hasn't been added yet.
Some things that are worth noting and are maybe not want we want
* `&mut T: Copy` doesn't allow as much as someone might expect because there is often an implicit reborrow.
* ~There isn't a check that a where clause is well-formed any more, so `where Vec<str>: Debug` is now allowed (without a `str: Sized` bound).~
bors [Wed, 16 May 2018 04:00:33 +0000 (04:00 +0000)]
Auto merge of #50750 - est31:master, r=eddyb
Remove ScopeTarget and LoopIdResult
* Remove ScopeTarget in preparation of label-break-value (PR #50045)
* Replace LoopIdResult by Result which is possible now thanks to commit 8ac65af81f5f9cf6c5e2c2306705b50eed77cfb5 " Implement Encodable and Decodable for Result."
bors [Wed, 16 May 2018 01:43:26 +0000 (01:43 +0000)]
Auto merge of #50541 - QuietMisdreavus:rustdoc-errors, r=GuillaumeGomez
rustdoc: replace most (e)println! statements with structured warnings/errors
Turns out, the rustc diagnostic handler doesn't need a whole lot of setup that we weren't already doing. For errors that occur outside a "dealing with source code" context, we can just use the format/color config we were already parsing and make up a `Handler` that we can emit structured warnings/errors from. So i did that. This will make it way easier to test things with `rustdoc-ui` tests, since those require the JSON error output. (In fact, this PR is a yak shave for a different one where i was trying to do just that. `>_>`)
bors [Tue, 15 May 2018 20:18:13 +0000 (20:18 +0000)]
Auto merge of #50767 - oli-obk:rls_clippy, r=kennytm
Don't inject clippy into the rls anymore
r? @kennytm
sorry about breaking nightlies.
The issue is that the `[patch.crates-io]` doesn't work if the versions differ. So every time we update clippy, we can only update it to the verison that rls is depending on.
I'm disabling the injection of clippy into rls for now. I'm not sure how to do this properly. We could
* add a version check, so rls only builds clippy if its dependency clippy is the same as the submodule clippy
* do something crazy like auto-patching the Cargo.toml of the rls tool repo to just use a path dependency on clippy
* build crates-io clippy instead of submodule clippy and gate clippy injection on that
* that's somewhat automatic, and is essentially what is necessary right now, but done manually
* make clippy 0.1.* instead of 0.0.* and update patch versions for nightly updates and minor version updates for `clippy_lints` api changes.
* not sure how semver-great this is
Anthony Ramine [Thu, 29 Mar 2018 07:41:41 +0000 (09:41 +0200)]
Reenable the MergeFunctions pass
The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc
pass enabled and it hugely reduces code size (for example it shaves off 10% of the
final Servo executable). This patch reenables it.
est31 [Fri, 11 May 2018 13:00:09 +0000 (15:00 +0200)]
Remove hir::ScopeTarget
When we want to implement label-break-value,
we can't really decide whether to emit ScopeTarget::Loop or
ScopeTarget::Block in the code that is supposed to create it.
So we get rid of it and reconstruct the information when
needed.
This leads to a lot of simplifications, as most code doesn't actually need to know about the specific lifetime/type data; rather, it's concerned with properties like name, index and def_id.
Guillaume Gomez [Tue, 15 May 2018 12:27:05 +0000 (14:27 +0200)]
Rollup merge of #50733 - katrinleinweber:patch-secure-DOI, r=kennytm
Hyperlink DOI against preferred resolver
Hello :-) The DOI foundation recommends [this new, secure resolver](https://www.doi.org/doi_handbook/3_Resolution.html#3.8). Accordingly, this PR updates a DOI link.
Guillaume Gomez [Tue, 15 May 2018 12:27:02 +0000 (14:27 +0200)]
Rollup merge of #50712 - leodasvacas:improve-eager-resolution-error-message, r=estebank
Improve eager type resolution error message
This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression.
Also a "note: type must be known at this point" is added where in the past we emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising.
Fixes #50692 (or at least does the best we can for the moment)
Guillaume Gomez [Tue, 15 May 2018 12:26:54 +0000 (14:26 +0200)]
Rollup merge of #49767 - ecstatic-morse:ptr-docs, r=steveklabnik
Rewrite docs for `std::ptr`
This PR attempts to resolve #29371.
This is a fairly major rewrite of the `std::ptr` docs, and deserves a fair bit of scrutiny. It adds links to the GNU libc docs for various instrinsics, adds internal links to types and functions referenced in the docs, adds new, more complex examples for many functions, and introduces a common template for discussing unsafety of functions in `std::ptr`.
All functions in `std::ptr` (with the exception of `ptr::eq`) are unsafe because they either read from or write to a raw pointer. The "Safety" section now informs that the function is unsafe because it dereferences a raw pointer and requires that any pointer to be read by the function points to "a valid vaue of type `T`".
Additionally, each function imposes some subset of the following conditions on its arguments.
* The pointer points to valid memory.
* The pointer points to initialized memory.
* The pointer is properly aligned.
These requirements are discussed in the "Undefined Behavior" section along with the consequences of using functions that perform bitwise copies without requiring `T: Copy`. I don't love my new descriptions of the consequences of making such copies. Perhaps the old ones were good enough?
Some issues which still need to be addressed before this is merged:
- [ ] The new docs assert that `drop_in_place` is equivalent to calling `read` and discarding the value. Is this correct?
- [ ] Do `write_bytes` and `swap_nonoverlapping` require properly aligned pointers?
- [ ] The new example for `drop_in_place` is a lackluster.
- [ ] Should these docs rigorously define what `valid` memory is? Or should is that the job of the reference? Should we link to the reference?
- [ ] Is it correct to require that pointers that will be read from refer to "valid values of type `T`"?
- [x] I can't imagine ever using `{read,write}_volatile` with non-`Copy` types. Should I just link to {read,write} and say that the same issues with non-`Copy` types apply?
- [x] `write_volatile` doesn't link back to `read_volatile`.
- [ ] Update docs for the unstable [`swap_nonoverlapping`](https://github.com/rust-lang/rust/issues/42818)
- [ ] Update docs for the unstable [unsafe pointer methods RFC](https://github.com/rust-lang/rfcs/pull/1966)
bors [Tue, 15 May 2018 03:14:46 +0000 (03:14 +0000)]
Auto merge of #50011 - varkor:partialord-opt-ii, r=Manishearth
Ensure derive(PartialOrd) is no longer accidentally exponential
Previously, two comparison operations would be generated for each field, each of which could delegate to another derived PartialOrd. Now we use ordering and optional chaining to ensure each pair of fields is only compared once, addressing https://github.com/rust-lang/rust/issues/49650#issuecomment-379467572.
Closes #49505.
r? @Manishearth (sorry for changing it again so soon!)
bors [Mon, 14 May 2018 20:46:09 +0000 (20:46 +0000)]
Auto merge of #50693 - dlrobertson:fix_50493, r=petrochenkov
typeck: Save the index of private fields
Save the index of all fields regardless of their visibility. Problems
could occur later when attempting to index fields in error recovery if
they are not inserted.
projects / rust.git / log