Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
12
contributors
Commits on Aug 1, 2020
-
Document that slice means pointer to a sequence
Also document that slices are twice as large as pointers to Sized types
-
-
Commits on Aug 18, 2020
Commits on Aug 22, 2020
-
-
-
-
-
-
-
-
-
-
Don't make clang use gcc's include-fixed
This was breaking `#include_next <limits.h>`, such that we weren't getting definitions of `PATH_MAX` and `_POSIX_ARG_MAX`.
-
-
-
Apply suggestions from code review
Flatten the INC definition to one line. Co-authored-by: lzutao <taolzu@gmail.com>
-
Match scalar-pair-bool more flexibly for LLVM 11
LLVM 11 started using `phi` and `select` for `fn pair_i32_bool`, which is still valid, but harder to match than the simple instructions we were getting before. We'll just check that the unpacked args are directly referenced in any way, and call it good.
-
-
-
Use smaller def span for functions
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
Commits on Aug 23, 2020
-
Auto merge of #73084 - Aaron1011:feature/new-recursive-expand, r=petr…
…ochenkov Re-land PR #72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro` PR #72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories 1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code. 2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](paritytech/parity-scale-codec#210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see #72622 (comment)). All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at sammhicks/face-generator#1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies. As @petrochenkov mentioned in #72545 (comment), not re-landing PR #72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
-
Auto merge of #73526 - cuviper:rust-llvm11, r=nikic
Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.
-
Auto merge of #75813 - petrochenkov:feature/incr-def-path-table, r=Aa…
…ron1011 Lazy decoding of DefPathTable from crate metadata (non-incremental case) The is the half of #74967 that doesn't touch incremental-related structures. We are still decoding def path hashes eagerly if we are in incremental mode. The incremental part of #74967 feels hacky, but I'm not qualified enough to suggest improvements. I'll reassign it so someone else once this PR lands. @Aaron1011, I wasn't asking you to do this split because I wasn't sure that it's feasible (or simple to do). r? @Aaron1011
-
Auto merge of #75465 - Aaron1011:feature/short-fn-def-span, r=estebank
Use smaller def span for functions Currently, the def span of a function encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); } ``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. All of these cases work only with local items, so we don't need to add anything extra to crate metadata. -
Auto merge of #75789 - matthiaskrgr:clippy_compiletest, r=Dylan-DPC
compiletest: fix a couple clippy lint findings
-
Revert changed paragraph about slice definition.
This reverts part of commit e6c83dd. As requested by @steveklabnik .
-
-
Co-authored-by: Josh Stone <cuviper@gmail.com>
-
Auto merge of #74238 - RalfJung:offset_from, r=oli-obk
stabilize ptr_offset_from This stabilizes ptr::offset_from, and closes #41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API. Regarding the open questions in #41079: * Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive. * Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later. Also nominating the lang team because this exposes an intrinsic. The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that, should LLVM ever obtain a `psub` operation to subtract pointers, will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).
-
Auto merge of #75028 - MrModder:master, r=steveklabnik
Document that slice refers to any pointer type to a sequence I was recently confused about the way slices are represented in memory. The necessary information was not available in the std-docs directly, but was a mix of different material from the reference and book. This PR should clear up the definition of slices a bit more in the documentation. Especially the fact that the term slice refers to the pointer/reference type, e.g. `&[T]`, and not `[T]`. It also documents that slice pointers are twice the size of pointers to `Sized` types, as this concept may be unfamiliar to users coming from other languages that do not have the concept of "fat pointers" (especially C/C++). I've documented why this was important to me and my findings in [this blog post](https://codecrash.me/understanding-rust-slices). r? @lcnr
-
Co-authored-by: Ralf Jung <post@ralfj.de>
-
Auto merge of #72449 - ecstatic-morse:const-float-bitcast, r=RalfJung
-
Auto merge of #75656 - tirr-c:match-suggest-semi, r=estebank
There are no files selected for viewing