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

Rollup of 20 pull requests #22439

Closed
wants to merge 62 commits into from
Closed

Conversation

iblech and others added 30 commits February 6, 2015 23:14
Without such a clarification, people who know and love closures (for instance
programmers with a Haskell background) might fear that types would have to
be declared in closures and that therefore using closures would be much more
unwieldy.
The `Arguments::new_v1_formatted` function was accidentally left out when this
module was stabilized.
This brings it in line with its namesake in `std::io`.

[breaking-change]
Some newcomers might look for a "flatMap" method on Option. Include the
reference so that searching the page would find "and_then".
When matching against strings/slices, we call the comparison function
for strings, which takes two string slices by value. The slices are
passed in memory, and currently we just pass in a pointer to the
original slice. That can cause misoptimizations because we emit a call
to llvm.lifetime.end for all by-value arguments at the end of a
function, which in this case marks the original slice as dead.

So we need to properly create copies of the slices to pass them to the
comparison function.

Fixes rust-lang#22008
The other cases: `concat_idents!`, `log_syntax!`, and `trace_macros!`,
(these macros, with `asm!`, are handled (eagerly) in feature_gate.rs).
Requested by Niko in rust-lang#22200 (and is good to have anyway)
 - We shouldn't be using `check_name` here at all
 - `contains_name(ref_slice(foo), bar)` is redundant, `contains_name` just iterates over its first arg and calls `check_name`
 - match would be better than a bunch of ifs
This redux of CONTRIBUTING.md adds in more information, including
subsuming both compliment-bugreport.md and Note-development-policy
in the wiki.

I only glanced at the broad TOC of Note-development-policy, and did
not use the text as the basis for the re-write. This will then address
the last outstanding part of rust-lang#5831.
The test "signal_reported_right" send a signal `1` to `/bin/sh`, and check
the status code to check if the signal is reported right.

Under OpenBSD, the signal `1` (`SIGHUP`) is catched by `/bin/sh`,
resulting the test failed.

Use the uncatchable signal `9` (`SIGKILL`) for test.
This commit mostly replaces some of the uses of os::args with env::args.
…eklabnik

This is a more introductory document, suitable for Part II. The arcane details move to an "Advanced macros" chapter in Part III.

Conflicts:
	src/doc/trpl/macros.md
@Manishearth Manishearth changed the title Rollup of 21 pull requests Rollup of 20 pull requests Feb 17, 2015
@dotdash
Copy link
Contributor

dotdash commented Feb 17, 2015

@bors r=pnkfelix a672498

@bors
Copy link
Contributor

bors commented Feb 17, 2015

⌛ Testing commit a672498 with merge 5e92d33...

@bors
Copy link
Contributor

bors commented Feb 17, 2015

💔 Test failed - auto-win-32-nopt-t

@nagisa
Copy link
Member

nagisa commented Feb 17, 2015

@Manishearth this patch should fix the other windows failure:

From b1f8e58045ec798abcd0d36d93d59f60b0595e52 Mon Sep 17 00:00:00 2001
From: Simonas Kazlauskas <git@kazlauskas.me>
Date: Tue, 17 Feb 2015 15:50:18 +0200
Subject: [PATCH] use ops::Range instead of iter::Range

---
 src/libstd/sys/windows/os.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/libstd/sys/windows/os.rs b/src/libstd/sys/windows/os.rs
index 6aa1ac0..502d70d 100644
--- a/src/libstd/sys/windows/os.rs
+++ b/src/libstd/sys/windows/os.rs
@@ -18,7 +18,7 @@ use os::windows::*;
 use error::Error as StdError;
 use ffi::{OsString, OsStr, AsOsStr};
 use fmt;
-use iter::Range;
+use ops::Range;
 use libc::types::os::arch::extra::LPWCH;
 use libc::{self, c_int, c_void};
 use mem;
@@ -319,7 +319,7 @@ pub fn args() -> Args {
         let lpCmdLine = c::GetCommandLineW();
         let szArgList = c::CommandLineToArgvW(lpCmdLine, &mut nArgs);

-        Args { cur: szArgList, range: range(0, nArgs as isize) }
+        Args { cur: szArgList, range: 0..(nArgs as isize) }
     }
 }

-- 
2.3.0

You can also merge it from the PR if you want, but you should keep in mind I didn’t test it on windows either.

@pnkfelix
Copy link
Member

(i am looking into whether I can recover a useful rollup PR from this work without too much effort)

@pnkfelix
Copy link
Member

@bors r=10f51fc

@bors
Copy link
Contributor

bors commented Feb 17, 2015

🙀 You have the wrong number! Please try again with 10f51fc.

@pnkfelix
Copy link
Member

@bors 10f51fc

@pnkfelix
Copy link
Member

@bors r+ 10f51fc

@bors
Copy link
Contributor

bors commented Feb 17, 2015

⌛ Testing commit 10f51fc with merge 076a920...

@bors
Copy link
Contributor

bors commented Feb 17, 2015

💔 Test failed - auto-mac-64-nopt-t

@eddyb
Copy link
Member

eddyb commented Feb 17, 2015

@bors r+ 096b105

@bors
Copy link
Contributor

bors commented Feb 17, 2015

⌛ Testing commit 096b105 with merge b2c68cd...

@bors
Copy link
Contributor

bors commented Feb 17, 2015

💔 Test failed - auto-mac-64-nopt-t

@alexcrichton
Copy link
Member

I'll take this over, starting anew with lots more PRs as well.

@pnkfelix
Copy link
Member

see #22475 (which seems to have ended with a manual merge, what a saga!

@Manishearth
Copy link
Member Author

Yeah, I've been watching that one, thanks :)

@Manishearth Manishearth deleted the rollup branch February 18, 2015 12:54
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.