Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inform user where to give a type annotation after a call to collect #47982

Closed
wants to merge 297 commits into from

Conversation

csmoe
Copy link
Member

@csmoe csmoe commented Feb 3, 2018

should resolve #47777

mark-i-m and others added 30 commits January 30, 2018 12:30
In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in rust-lang#47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.

We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.

It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.

This is concerning rust-lang#47775.
We use binaryen's linker to produce a wasm file (via s2wasm). The wasm writer has capabilities to export source maps.

The produced source map contains references to the original file, that might require additional source map file processing to include / package original files with it.
is_unsafe_place only filters out statics in the rhs, not the lhs. Since
it's possible to reach that 'Place::Static', we handle statics the same
way as we do locals.

Fixes rust-lang#47789
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads.  The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below
that address, if so reporting it as a stack overflow.

Now `unix` targets report a `Range<usize>` representing the guard
memory, so it can cover arbitrary guard sizes.  Non-`unix` targets which
always return `None` for guards now do so with `Option<!>`, so they
don't pay any overhead.

For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack.  However, there's no simple way for us to
know where the guard page actually lies, so now we declare it as the
whole range of `stackaddr ± guardsize`, and any fault therein will be
called a stack overflow.  This fixes rust-lang#47863.
Currently ', " and \ are escaped as \', \" and \\ respectively. This
leads to confusing messages such as `error: unknown start of token: \\`
when encountering a single backslash.

Fix by emitting printable ASCII characters directly. This will still
escape \r, \n, \t and Unicode characters.

Fixes rust-lang#47902
The `exchange_free` lang item is gone in favour of `box_free` [1].

Some warnings are also fixed by this commit.

[1]: rust-lang@ca115dd
Otherwise we get random TySelfs there, which means operations on
RETURN_PLACE end up breaking down badly.
Clearing out the infcx's region constraints after processing each type
ends up interacting badly with normalizing associated types. This commit
keeps all region constraints intact until the end of
TypeLivenessGenerator.add_drop_live_constraint, ensuring that normalized
types are able to re-use existing inference variables.

Fixes rust-lang#47589
alexcrichton and others added 16 commits February 10, 2018 07:03
Introduced in rust-lang#47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
…k-Simulacrum

Update the dlmalloc submodule

A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
…chton

fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}}

via codespell
…kennytm

Explain unusual debugging code in librustc

Introduced in rust-lang#47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
…oc, r=frewsxcv

Document the behaviour of infinite iterators on potentially-computable methods

It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
…tsakis

 rustc_mir: insert a dummy access to places being matched on, when building MIR.

Fixes rust-lang#47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.

r? @nikomatsakis
Emit data::Impl in save-analysis

As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis.

A number of questions are outstanding:

- [x] A few `???` around row 356. We need to discuss what goes here, if anything.
- [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~
- [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~
- [x] Need a new rls-data with an `id` field in `Impl` struct.
- [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
Fix oversized loads on x86_64 SysV FFI calls

The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.

Refs rust-lang#45543
…akis

Implement `?` macro repetition

See rust-lang/rfcs#2298 (with disposition merge)
This should save a lot of space on musl test cases (whose standard library
are linked statically).
This isn't a perfect heuristic, but since the amount of run-fail tests
is far lower than run-pass tests for now, it should be sufficient to
ensure that we don't run into CI limits. This makes it possible to run
the test binary manually (e.g., under gdb/lldb) if it failed to attempt
to find out why.
…-Simulacrum

Compiletest: delete the compiled program once its test is done.

Reduces CI disk usage which prevents rust-lang#48118 from succeeding.
Add `-Zteach` documentation

Add extra inline documentation to E0019, E0016, E0013, E0396, E0017,
E0018, E0010, E0022, E0030, E0029, E0033, E0026 and E0027.

Follow up to rust-lang#47652.
@pietroalbini
Copy link
Member

Hi @csmoe, and thanks for the PR! We haven't heard from you in a while, could you address #47982 (comment)? Thanks!

@csmoe csmoe closed this Feb 13, 2018
@csmoe csmoe deleted the give_type_annotation_after_collect branch February 13, 2018 10:51
Manishearth added a commit to Manishearth/rust that referenced this pull request Feb 19, 2018
…tebank

inform user where to give a type annotation

should resolve rust-lang#47777
previous pull request rust-lang#47982 was closed because of a mistaken rebase.
r? @estebank
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Feb 21, 2018
…tebank

inform user where to give a type annotation

should resolve rust-lang#47777
previous pull request rust-lang#47982 was closed because of a mistaken rebase.
r? @estebank
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

inform user where to give a type annotation after a call to collect