profile
viewpoint
Mark Rousskov Mark-Simulacrum Rust core and infra team member; Release team lead.

integer32llc/rust-playground 507

The Rust Playground

Mark-Simulacrum/bisect-rust 20

Bisects rust-lang/rust by pull request, downloading the built artifacts

Mark-Simulacrum/attractifier 3

Attractifier generates attractive JavaScript code from ugly JavaScript code.

Mark-Simulacrum/advent-of-code 1

Advent of Code solutions in Rust

Centril/crater-cat-errors 0

A quick hackily made program to aggregate all the errors in a crater run and which crates have them

Mark-Simulacrum/adjective-adjective-animal 0

Suitably random and reasonably unique human readable (and fairly adorable) ids, ala GiphyCat

Mark-Simulacrum/advent-of-code-2015 0

Each day of the 2015 Advent of Code. http://adventofcode.com/

Mark-Simulacrum/amd-bits 0

AMD loader built on top of bit-loader

pull request commentrust-lang/rust

revert #75443 update mir validator

#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions, but I hope that this is a purely theoretical concern.

Can you say more about this? Maybe a code example if possible? I think if we are to land a breaking change I'd prefer to have pre-prepared a note to include in the release notes, at least.

lcnr

comment created time in 3 hours

pull request commentrust-lang/rust

incr-comp: hash and serialize span end line/column

Full builds are basically unaffected, and wall times do not see major impacts either. I think this is fine from a performance perspective: performance is important, but this is a correctness fix, and that can sometimes (of course) carry performance hazards with it.

That said, it looks like this carries a bunch of commits after the first one which (at first glance) look unrelated, perhaps they need to be rebased into a separate PR?

tgnottingham

comment created time in 5 hours

issue commentrust-lang/rust

Tracking issue for #[cfg(target_has_atomic = ...)]

We discussed this in the T-lang meeting today, and though no specific objections to stabilization were discussed, I did have the concern that this feels like it either:

  • does the wrong thing in practice (i.e., does not match libcore's atomic types existing)
  • does precisely the same thing as cfg(accessible) would, in which case this is not particularly useful and seems like not something we should stabilize.

We did not reach any firm conclusions, but my feeling was that we were interested in putting time into cfg accessible rather than into this issue in particular.

That said, if I was wrong in the assumption that this is a 1:1 with cfg(accessible), then we should discuss further.

Removing nomination for now.

alexcrichton

comment created time in 5 hours

pull request commentrust-lang/rust

Update RELEASES.md for 1.48.0

https://github.com/rust-lang/rust/issues/78143 is almost certain to be closed as won't fix, so should be included in compat notes here.

XAMPPRocky

comment created time in 5 hours

issue commentrust-lang/rust

New "warning incompatible with previous forbid in same scope" error

I will try to work out an implementation to better get a sense of what would fall out of the impl naturally without too much contortion. We'll then try to FCP that proposal.

(If this ends up taking too long, we will likely just revert #77534 on beta or so; I am not too worried, as it is not yet a beta regression).

Nemo157

comment created time in 5 hours

issue commentrust-lang/rust

rust build of 1.47.0: rustdoc fails when cross-building for NetBSD/sparc64

Are you self-bootstrapping the cross build (setting rustc/cargo 1.47 as well)? I guess that's the only difference I can think of that would obviously cause things like this.

It's also possible this is just always broken, rust-lang/rust doesn't cross-compile documentation I think for most platforms so we don't really test it.

he32

comment created time in 6 hours

pull request commentrust-lang/rust

Don't leak return value after panic in drop

Since this adds code, I suspect it's always going to be a regression. I would ignore the incremental benchmarks here, which brings us down to roughly 5% regression on real world codebases. I think given this is a soundness fix (at least arguably) and certainly unintuitive behavior, we should land this (modulo review of the diff itself, which I have not done).

matthewjasper

comment created time in 7 hours

pull request commentrust-lang/rust

Avoid panic_bounds_check in fmt::write.

Hm, I think there's a only-hosts comment you can put to achieve the same thing.

m-ou-se

comment created time in 8 hours

issue commentrust-lang/rfcs

Include the errored file path (when available) in std::io::Error instances

I think I've personally been slowly more convinced over time that this is probably the right thing to do if we can pull it off on benchmarks and such (seems not implausible, given existing allocations etc) -- I think the right next step is to kick off some discussion on internals.rust-lang.org and get a read on how libs team feels about this (#t-libs on Zulip is probably best for that). See also https://github.com/rust-lang/rfcs/pull/2979, which tries to codify some of these processes :)

mqudsi

comment created time in 8 hours

pull request commentrust-lang/rust

Avoid panic_bounds_check in fmt::write.

Ah, hm. Well -- at least currently, the llvm-8 builder does not have debug asserts enabled. I think this test can also be a regular (non-fulldeps) run-make test. Maybe we want to explicitly mark that builder as disabling debug assertions, editing the comment in https://github.com/rust-lang/rust/blob/b6ac411f45d38d867ce9f689bbd5c3e7456d0f65/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L61-L65? Obviously not full coverage, but for this I don't think we really need it.

For codegen and run-make tests (i.e., not full deps tests) it should also be relatively quick to build a non-debug-assert enabled std in rustbuild just for them, though that's really not supported right now so we'd need some fairly annoying option threading to make that happen.

I'd personally also be fine disabling std debug asserts on the nopt builders or something like that -- that would give us more coverage as well...

m-ou-se

comment created time in 8 hours

pull request commentrust-lang/rust

Add cg_clif as optional codegen backend

@bors r+ rollup=never p=5

bjorn3

comment created time in 8 hours

pull request commentrust-lang/rust-central-station

Backfill MAJOR.MINOR Rustup channel manifests with a script this time

I think @kinnison had indicated as such initially? It seems like that'll need a rustup release.

cc @XAMPPRocky as well since I think this might need to get dropped from relnotes for now in that case, I sort of doubt we'll have a rustup release in the next 3ish weeks

carols10cents

comment created time in 9 hours

pull request commentrust-lang/rust

BTreeMap: ban BoxedNode from Root

Also, I'm now thinking it would be better to stop using the Root alias at the node level and move it up to the map level.

Hm, I'm not sure I quite follow, but I think this feels wrong -- roots are useful when e.g. splitting out a subtree which will later be joined in a different place. I'm not sure that the code will care too much about this distinction though.

ssomers

comment created time in 9 hours

pull request commentrust-lang/rust

BTreeMap: move generic support functions out of navigate.rs

@bors r+ rollup=never

ssomers

comment created time in 9 hours

pull request commentrust-lang/rust

BTreeMap: revert a part of #78015 and test what it broke

Can you clarify exactly what leaks and where? I'm not sure I'm quite following -- it might be a bug with drop elaboration or something like that if I am, in which case we shouldn't fix it here.

ssomers

comment created time in 9 hours

issue commentrust-lang/rust

New "warning incompatible with previous forbid in same scope" error

Always true:

  • Behavior of attributes is order-dependent, last attribute wins. Duplicate (e.g., #![deny(unused)] ... #![deny(unused)] attributes are not an error.
  • cap-lints always overrides any level set, including forbid.
  • It is an error to attempt to lower the level from forbid when in nested scopes (e.g., CLI says forbid, code says deny at top level). At the same scope this is not an error. Note that for modules, the outer and inner scopes can be in different files (#[attr] mod foo; and foo.rs has #![attr]).

New behavior, introduced by https://github.com/rust-lang/rust/pull/77534:

Forbid (essentially) takes immediate effect, rather than being overridden by other attributes at the same level. This is unique behavior specifically to forbid; no other lint receives the same treatment.

I would propose the following (the implementation should be worked out, of course, but this seems feasible -- I would not FCP until we have a PR, just that if people have objections to this raising them now seems good):

  • Warn (unused attribute) on skipped/ignored attributes at the same level.
    • This is not an error for backwards compatibility, primarily.
    • One downside is that this is basically not possible to silence in a targeted fashion (you have to disable it for a whole tree, but that's probably not too important -- in practice this is true of all attribute lints).
  • Locally overriding forbid (i.e., at different or the same level) is a forbid-by-default lint. This means you can't disable it except with cap-lints.
    • This also matches just the behavior of forbid itself which seems quite reasonable.
    • This is backwards compatible in dependencies, though not locally. I think the breakage for forbid followed by an allow/deny whatever at the same level is likely to be minimal, and desirable. If we choose not to do this it would hopefully be caught by the first bullet here, but I suspect that one will not be as easy to implement.
Nemo157

comment created time in 9 hours

pull request commentrust-lang/rust

Add some regression tests

Oh, looks like CI is failing here:

tidy error: /checkout/src/test/ui/issues/issue-75763.rs:7: trailing whitespace

@bors r-

(r=me with that fixed though)

camelid

comment created time in 9 hours

pull request commentrust-lang/rust

Add some regression tests

I think closing #75673 is likely fine -- the broader issue of whether invalid UTF-8 in const generic &str should be caught during transmutes is something to settle before stabilization of str in consts. (It is unclear to me that we indeed must prohibit such a thing, as indicated on said issue). cc @lcnr just in case though

@bors r+

camelid

comment created time in 9 hours

issue commentrust-lang/rust

regression: could not fully normalize type

cc https://github.com/rust-lang/rust/issues/54114, which may be the same underlying bug (but pre-existing?)

Mark-Simulacrum

comment created time in 9 hours

issue commentrust-lang/rust

regression: could not fully normalize type

I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE.

Mark-Simulacrum

comment created time in 10 hours

pull request commentrust-lang/rust

specialize some collection and iterator operations to run in-place

@the8472 fwiw, on future PRs, especially if rebasing it would be great to squash out commits that are fixups (e.g., tidy fixes) and such to have a cleaner git history.

the8472

comment created time in 10 hours

issue closedrust-lang/rust

Avoid re-downloading multiple identical LLVMs from CI

Any LLVM submodule update landing means that we can switch rust-dev downloads added by #76349 to look for the LLVM submodule update rather than latest bors commit. That'll avoid spuriously redownloading essentially identical tarballs whenever someone rebases.

This is technically a QoL issue so does not block that PR, but is a rather major improvement since rebasing is quite common and the download is relatively hefty at ~20 MB.

closed time in 10 hours

Mark-Simulacrum

issue commentrust-lang/rust

Avoid re-downloading multiple identical LLVMs from CI

I believe this has since been fixed, so closing.

Mark-Simulacrum

comment created time in 10 hours

pull request commentrust-lang/rust

add system-llvm-libunwind config option

@bors r+

Keruspe

comment created time in 10 hours

pull request commentrust-lang/rust

[do not merge] get build artifact for freebsd

@bors try

lzutao

comment created time in 10 hours

push eventrust-lang/thanks

Deploy from CI

commit sha a122614d37d199c9ec03eb65a20e782de0ac8b9d

Deploy f44933b615ecd6778838f92f5e389525a446f286 to gh-pages

view details

push time in 11 hours

push eventrust-lang/rust-forge

Pietro Albini

commit sha c6f6c11f87e17058d0fe4cb32058260a0479df21

infra: add docs on the bors setup

view details

Mark Rousskov

commit sha 8d142c12c312cb8cbd900420f3153ecf0cfebefb

Merge pull request #462 from rust-lang/bors Add docs on the new bors setup

view details

push time in 13 hours

PR merged rust-lang/rust-forge

Add docs on the new bors setup
+74 -0

1 comment

2 changed files

pietroalbini

pr closed time in 13 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

libc: 0.2.79 -> 0.2.80

I generally ask that such PRs also bump the libc dep in a Cargo.toml somewhere in the workspace, so we don't accidentally regress in a future PR when rebasing across this change (I've done it before myself, and only noticed when looking at the diff, which for larger Cargo.lock changes is a bit untenable). r=me with that done.

nagisa

comment created time in a day

pull request commentrust-lang/rust

Optimise align_offset for stride=1 further

This time around wall times are down roughly 50%. So either this PR considerably increases the amount of noise we see (seems highly unlikely) or something has landed in the meantime that shifts things around to this being a net improvement now. Regardless cycles and instructions seem neutral or down, and since llvm-mca points at throughput increases, I think we should merge this.

@bors r+

nagisa

comment created time in a day

pull request commentrust-lang/rust

Update RELEASES.md for 1.48.0

I would also like to see the increased mem::uninitialized runtime checking change featured in the compatibility notes -- https://github.com/rust-lang/rust/pull/71274 -- potentially quite a few users are likely to encounter the asserts added by that PR (which is fine, their code is currently UB so I'd rather they get asserts rather than silent miscompiles), we should add a pointer to the notes for them.

XAMPPRocky

comment created time in a day

pull request commentrust-lang/rust

Updated the list of white-listed target features for x86

cc @rust-lang/project-portable-simd (perhaps?)

I'm going to r? @KodrAus here though in the hopes that you're more familiar or can direct this to an appropriate reviewer

DevJPM

comment created time in a day

pull request commentrust-lang/rust

BTreeMap: move generic support functions out of navigate.rs

r=me though on the change itself (I think I approved a similar commit elsewhere, IIRC a bit smaller but I might be misremembering)

ssomers

comment created time in a day

pull request commentrust-lang/rust

BTreeMap: move generic support functions out of navigate.rs

Oh, hm, I did not see this before that other PR. If you want to ping me on Zulip to just say "please review in this order" or whatever, that's fine by me -- otherwise I usually go in oldest first order in my waiting-on-review queue.

ssomers

comment created time in a day

pull request commentrust-lang/rust

[do not merge] get build artifact for freebsd

Please drop the non-freebsd job from the try builder in the future. The CI changes otherwise look reasonable here, but I cannot try this PR because of the conflict.

lzutao

comment created time in a day

pull request commentrust-lang/rust

Support enable/disable sanitizers/profiler per target

Please also squash commits. I'll want to do another read through I think, but I suspect this is good to go modulo the nit.

12101111

comment created time in a day

Pull request review commentrust-lang/rust

Support enable/disable sanitizers/profiler per target

 impl Build {         if self.config.backtrace {             features.push_str(" backtrace");         }-        if self.config.profiler {+        if self.config.sanitizers_enabled(target) {

This is presumably meant to be profiler_enabled?

12101111

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

Qualify `panic!` with `$crate::` in `core` macros

I'm going to r? @m-ou-se here, I'm not sure what the right path is -- would need to think about it -- but you seem to have a better handle on it than I :)

camelid

comment created time in a day

pull request commentrust-lang/rust

Use check-pass in single-use-lifetime ui tests

FWIW "Additionally tidies touched test files." is probably a bad idea in the future -- it adds blame noise for future lookers (though not so important in tests), at the very least, and also makes reviewers need to pay even more attention to slight details. In this case though there's not too many files that I minded doing so, so no worries.

@bors r+ rollup

oliviacrain

comment created time in a day

pull request commentrust-lang/rust

Add test for bad NLL higher-ranked subtype

@bors r+ rollup

Based on Niko's last comment on #57642, it sounds like the second case might not be something we actually want to reject, but since it matches non-NLL behavior I think we should test for it and we can adjust the test consciously in the future if necessary.

Aaron1011

comment created time in a day

pull request commentrust-lang/rust

Add codegen test for #45964

@bors r+

bugadani

comment created time in a day

pull request commentrust-lang/rust

WIP: Compile rustc crates with the initial-exec TLS model

Hm, so when you ask "Ideally, we'd apply this to every crate that isn't a proc macro or compiled into a dynamically linkable version of std. How can we most easily capture that set here?" -- do you mean to do that as an end-user visible change (rather than just to crates compiled by rustbuild? It seems to me that rustc shouldn't really be special here in some sense. That's probably not quite true because we have the somewhat odd case of compiling to dylibs that aren't intended to be dlopen'd (rather just linked directly), but I'm not sure that's important.

I think the best thing is probably to start out with just a change to how we compile rustc which should be somewhat easier to land and see impacts of though. To do so we probably want to set the -Z flag via rustflags if possible, something like this diff. This will set it for pretty much everything except std workspace and crates that don't get rustflags (e.g., proc macros and other build deps). Note that this includes e.g. cargo and clippy too, but I think that's the right thing?

diff --git a/src/bootstrap/builder.rs b/src/bootstrap/builder.rs
index 707c1ff3efa..0f6a74b01ce 100644
--- a/src/bootstrap/builder.rs
+++ b/src/bootstrap/builder.rs
@@ -1114,6 +1114,10 @@ impl<'a> Builder<'a> {
             }
         }
 
+        if mode != Mode::Std {
+            rustflags.arg("-Ztls-model=initial-exec");
+        }
+
         if self.config.incremental {
             cargo.env("CARGO_INCREMENTAL", "1");
         } else {
joshtriplett

comment created time in a day

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha b83b6012223a60fe372dc79e4218a1cc691d6096

Automatic stats update

view details

push time in a day

Pull request review commentrust-lang/rust

Allow creating a list of files shipped in a release

 impl Target {         }     } -    fn tarball_variant(base: &Path, ext: &str) -> Option<PathBuf> {+    fn tarball_variant(builder: &mut Builder, base: &Path, ext: &str) -> Option<PathBuf> {         let mut path = base.to_path_buf();         path.set_extension(ext);-        if path.is_file() { Some(path) } else { None }+        if path.is_file() {+            builder.shipped_files.insert(+                path.file_name()+                    .expect("missing filename")+                    .to_str()+                    .expect("non-utf8-8 filename")

nit: double 8-8 here.

pietroalbini

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

PR closed rust-lang/rust

Type hint bootstrap.py A-rustbuild S-waiting-on-review

I've looked for errors in bootstrap.py by adding type hints and running mypy over it. Untyped python code often tends to have some hidden problems. I haven't found any bugs, only some quality problems in that the RustBuild class is a bit of a god class and it's hard to follow what's initialized when and where.

It may be worth it to keep the type annotations as they also act as documentation. A couple of variables have rather surprising types. I could also add mypy to CI, but I'd understand if you don't want to raise the requirements for Python specific tooling.

+95 -64

3 comments

2 changed files

Emerentius

pr closed time in a day

pull request commentrust-lang/rust

Type hint bootstrap.py

I'm going to go ahead and close this because I don't think we'd want to merge this right now. I'm not sure that we'd ever want to do this without CI checking, and I think it's just too high a burden to do so in general for the relatively short Python script we have.

Emerentius

comment created time in a day

pull request commentrust-lang/rust

Avoid panic_bounds_check in fmt::write.

It should be possible to disable the test if debug asserts are enabled (I forget the syntax or whether it's supported though). I can search for that during my next review pass if you set this to waiting on reviewer.

m-ou-se

comment created time in a day

pull request commentrust-lang/rust

Tweak `if let` suggestion to be more liberal with suggestion and to not ICE

@bors r+

Thanks!

estebank

comment created time in a day

pull request commentrust-lang/rust

Optimise align_offset for stride=1 further

I agree that a 50% wall time regression is likely to be mostly noise - unfortunately we don't really have a good way yet of determining noise on the presentation layer such that we could hide deltas within the noise bound and then (hopefully) show all the statistics we collect in some way.

That said, I am inclined to land this as is presuming this perf run comes back similarly (or better). I think most of the wall time regressions are on tiny crates - several milliseconds - and so aren't too interesting.

nagisa

comment created time in a day

pull request commentrust-lang/rust

Add issue template link to IRLO

@bors r+ rollup

I've also asked GitHub about the reordering.

jonas-schievink

comment created time in a day

pull request commentrust-lang/rust

Initialize tracing subscriber in compiletest tool

@bors r+

tmiasko

comment created time in a day

pull request commentrust-lang/rust

BTreeMap: ban BoxedNode from Root

@bors r+

ssomers

comment created time in a day

Pull request review commentrust-lang/rust

Improve doc for 'as _'

 /// assert_eq!(true as u8 + thing2 as u8, 100); /// ``` ///+/// `as` can also be used with the `_` placeholder when the destination type+/// can be inferred. Note that this can cause inference breakage and usually+/// such code should use an explicit type for both clarity and stability:+///+/// ```rust+/// let value1: i32 = 42;+/// let value2: i64 = value1 as _;+/// assert_eq!(value2, value1 as _);+/// ```

I feel like this is ambiguous whether this is actually providing an example of "good" or "bad" code. Maybe we can adjust the wording to be clearer, or just not providing a code example here is fine -- we don't want to recommend the pattern after all :)

poliorcetics

comment created time in a day

PullRequestReviewEvent

pull request commentrust-lang/rust

btree: merge the implementations of MergeIter

@bors r+ rollup=never

ssomers

comment created time in a day

Pull request review commentrust-lang/rust

Add cg_clif as optional codegen backend

 pub fn get_codegen_sysroot(backend_name: &str) -> fn() -> Box<dyn CodegenBackend      let mut file: Option<PathBuf> = None; -    let expected_name = format!("rustc_codegen_{}", backend_name);+    let expected_name =+        format!("rustc_codegen_{}-{}", backend_name, release_str().expect("CFG_RELEASE"));

I am a bit worried this is going to cause ICEs somewhere, but it shouldn't be in dist artifacts so I'm not too worried. We can deal with it if it comes up.

bjorn3

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

transmute_copy: explain that alignment is handled correctly

@bors r+ rollup

Thanks, I agree this is better.

RalfJung

comment created time in a day

pull request commentrust-lang/rust

add system-llvm-libunwind config option

r=me with commits squashed

Keruspe

comment created time in a day

pull request commentrust-lang/rust

Tweak `if let` suggestion to be more liberal with suggestion and to not ICE

Niko indicated that the flip in coercion order was likely fine during the last meeting -- @estebank, would you be up for squashing the commits here a bit? Ideally I'd prefer to avoid 4 commits for such a small and dense change :)

r=me though.

estebank

comment created time in a day

pull request commentrust-lang/rust

Optimise align_offset for stride=1 further

The perf results here don't seem to really correspond nicely to the conclusions laid out in the PR description: wall times contain a bunch of regressions, and the instruction counts are slightly up as well. Maybe LLVM 11 (which I think landed since then) changed the calculus for the compiler, though -- let's generate another round of benchmarks.

@bors try @rust-timer queue

@nagisa Do the perf results match your expectations? @joshtriplett -- I think you didn't comment on them at all, perhaps you have thoughts?

Generally speaking I'm fine with landing this -- the implementation looks correct -- but it seems like if it's a regression on rustc runtime then maybe we shouldn't?

nagisa

comment created time in a day

pull request commentrust-lang/rust

`#[deny(unsafe_op_in_unsafe_fn)]` in sys/wasm

@bors r+ rollup

chansuke

comment created time in a day

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link-self-contained=<yes|no>`][76158] Which tells `rustc` whether to link+  its own C runtime and libraries or to rely on a external linker to find them. (supported only on+  `windows-gnu`, `linux-musl`, and `wasi` platforms.)+- [You can now use `-C target-feature=+crt-static` on `linux-gnu` targets.][77386]+- [Added tier 2\* support for `aarch64-unknown-linux-musl`.][76420]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.++Libraries+---------+- [`io::Write` is now implemented for `&ChildStdin` `&Sink`, `&Stdout`,+  and `&Stderr`.][76275]+- [All arrays now implement `TryFrom<Vec<T>>`.][76310]+- [The `matches!` macro now supports having a trailing comma.][74880]+- [`Vec<A>` now implements `PartialEq<[B]>` where `A: PartialEq<B>`.][74194]+- [Nearly all of `Cell`'s panicking functions now use the `#[track_caller]`

Which ones did we miss (it would be good to at least add it on master now)? Also, it looks like the PR linked here modifies RefCell, not Cell, which doesn't panic.

XAMPPRocky

comment created time in a day

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link-self-contained=<yes|no>`][76158] Which tells `rustc` whether to link+  its own C runtime and libraries or to rely on a external linker to find them. (supported only on+  `windows-gnu`, `linux-musl`, and `wasi` platforms.)+- [You can now use `-C target-feature=+crt-static` on `linux-gnu` targets.][77386]+- [Added tier 2\* support for `aarch64-unknown-linux-musl`.][76420]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.++Libraries+---------+- [`io::Write` is now implemented for `&ChildStdin` `&Sink`, `&Stdout`,+  and `&Stderr`.][76275]+- [All arrays now implement `TryFrom<Vec<T>>`.][76310]+- [The `matches!` macro now supports having a trailing comma.][74880]+- [`Vec<A>` now implements `PartialEq<[B]>` where `A: PartialEq<B>`.][74194]+- [Nearly all of `Cell`'s panicking functions now use the `#[track_caller]`+  attribute.][77055]++Stabilized APIs+---------------+- [`slice::as_ptr_range`]+- [`slice::as_mut_ptr_range`]+- [`VecDeque::make_contiguous`]+- [`future::pending`]+- [`future::ready`]++The following previously stable methods are now `const fn`'s:++- [`Option::is_some`]+- [`Option::is_none`]+- [`Option::as_ref`]+- [`Result::is_ok`]+- [`Result::is_err`]+- [`Result::as_ref`]+- [`Ordering::reverse`]+- [`Ordering::then`]++Cargo+-----++Misc+----+- [You can now link to different items in `rustdoc` using the intra-doc link+  syntax.][74430] E.g. ``/// Uses [`std::future`]`` will automatically generate+  a link to `std::future`'s documentation. See ["Linking to items by+  name"][intradoc-links] for more information.+- [You can now specify `#[doc(alias = "<alias>")]` on items to add search aliases+  when searching through `rustdoc`'s UI.][75740]+- [You can now use `rustup install <major>.<minor>` to specify installing the+  latest available patch of that minor version of the toolchain.][76107] E.g.+  `rustup install 1.45` would install `1.45.2`, and `1.46` would install `1.46.0`.++Compatibility Notes+-------------------+- [`const fn`s are now implicitly promoted to `const`.][75502] Meaning that it+  will only warn if your code fails `const` evaluation, and not produce an error.+- [Associated type bindings on trait objects are now verified to meet the bounds+  declared on the trait when checking that they implement the trait.][27675]+- [When trait bounds on associated types or opaque types are ambiguous, the+  compiler no longer makes an arbitrary choice on which bound to use.][54121]+- [Fixed recursive nonterminals not being expended in macros during
- [Fixed recursive nonterminals not being expanded in macros during
XAMPPRocky

comment created time in a day

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link-self-contained=<yes|no>`][76158] Which tells `rustc` whether to link+  its own C runtime and libraries or to rely on a external linker to find them. (supported only on+  `windows-gnu`, `linux-musl`, and `wasi` platforms.)+- [You can now use `-C target-feature=+crt-static` on `linux-gnu` targets.][77386]+- [Added tier 2\* support for `aarch64-unknown-linux-musl`.][76420]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.++Libraries+---------+- [`io::Write` is now implemented for `&ChildStdin` `&Sink`, `&Stdout`,+  and `&Stderr`.][76275]+- [All arrays now implement `TryFrom<Vec<T>>`.][76310]

I read this as expanding the set from length <= 32 to all, but it looks like it's just all arrays... I would be interested if you have thoughts on how to clarify that, but ultimately I don't think it's important so fine to just resolve.

XAMPPRocky

comment created time in a day

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.48.0

+Version 1.48.0 (2020-11-19)+==========================++Language+--------++- [The `unsafe` keyword is now syntactically permitted on modules.][75857] This+  is still rejected *semantically*, but can now be parsed by procedural macros.++Compiler+--------+- [Stabilised the `-C link-self-contained=<yes|no>`][76158] Which tells `rustc` whether to link+  its own C runtime and libraries or to rely on a external linker to find them. (supported only on+  `windows-gnu`, `linux-musl`, and `wasi` platforms.)+- [You can now use `-C target-feature=+crt-static` on `linux-gnu` targets.][77386]+- [Added tier 2\* support for `aarch64-unknown-linux-musl`.][76420]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.++Libraries+---------+- [`io::Write` is now implemented for `&ChildStdin` `&Sink`, `&Stdout`,+  and `&Stderr`.][76275]+- [All arrays now implement `TryFrom<Vec<T>>`.][76310]+- [The `matches!` macro now supports having a trailing comma.][74880]+- [`Vec<A>` now implements `PartialEq<[B]>` where `A: PartialEq<B>`.][74194]+- [Nearly all of `Cell`'s panicking functions now use the `#[track_caller]`+  attribute.][77055]++Stabilized APIs+---------------+- [`slice::as_ptr_range`]+- [`slice::as_mut_ptr_range`]+- [`VecDeque::make_contiguous`]+- [`future::pending`]+- [`future::ready`]++The following previously stable methods are now `const fn`'s:++- [`Option::is_some`]+- [`Option::is_none`]+- [`Option::as_ref`]+- [`Result::is_ok`]+- [`Result::is_err`]+- [`Result::as_ref`]+- [`Ordering::reverse`]+- [`Ordering::then`]++Cargo+-----++Misc+----+- [You can now link to different items in `rustdoc` using the intra-doc link+  syntax.][74430] E.g. ``/// Uses [`std::future`]`` will automatically generate+  a link to `std::future`'s documentation. See ["Linking to items by+  name"][intradoc-links] for more information.+- [You can now specify `#[doc(alias = "<alias>")]` on items to add search aliases+  when searching through `rustdoc`'s UI.][75740]+- [You can now use `rustup install <major>.<minor>` to specify installing the+  latest available patch of that minor version of the toolchain.][76107] E.g.+  `rustup install 1.45` would install `1.45.2`, and `1.46` would install `1.46.0`.++Compatibility Notes+-------------------+- [`const fn`s are now implicitly promoted to `const`.][75502] Meaning that it+  will only warn if your code fails `const` evaluation, and not produce an error.

I think this isn't quite right -- what has changed is that const fn will no longer get implicitly promoted, I think? i.e., &foo() where foo is a const fn and the type is requested at &'static T will no longer compile on beta.

cc @rust-lang/wg-const-eval is there a succinct summary we could include here? Maybe we can get someone to put together a short inside rust blog post we can link to here?

XAMPPRocky

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/homu

Add a "create a similar rollup" link in rollup PR body

I would prefer to avoid putting these URLs in PR bodies if we don't automatically strip them out when adding the PR to the commit log. Maybe we could add that filtering? See e.g. #100 for an example of such.

That said I'd want feedback from people doing rollups on the regular if this is a good solution -- cc @RalfJung @dylan-dpc @jonas-schievink (we really need a pingable team here)

oliviacrain

comment created time in a day

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 884a916832c83b5c2cf0674a728995f2cc34f2ed

Automatic stats update

view details

push time in 2 days

pull request commentrust-lang/rust

BTreeMap: stop mistaking node::MIN_LEN for a node level constraint

@bors r+

ssomers

comment created time in 2 days

pull request commentrust-lang/rust

Use separate sysroot directories for `check` and `build`

@jyn514 to check in, do you think you'd be interested in implementing the solution I suggested above?

jyn514

comment created time in 2 days

issue commentrust-lang/rust

Enable profiler=true in config.toml and target = [wasm32-unknown-unknown] will cause bootstrap fail

That would make sense to me; that said, for CI and other environments that want all targets to have this it'll be much easier to have the global option around too. I would likely accept a PR for this if the implementation can be localized to configuration parsing (and maybe slight alterations of how we query for sanitizer/profiler enablement).

12101111

comment created time in 2 days

push eventrust-lang/thanks

Deploy from CI

commit sha c6699489c021264ea8e085887a3be26f2a9cd0a8

Deploy f44933b615ecd6778838f92f5e389525a446f286 to gh-pages

view details

push time in 2 days

push eventrust-lang/thanks

Mara Bos

commit sha fa776039eb2ec1087d15e7bec06b1e21961c3542

Add myself.

view details

Mark Rousskov

commit sha f44933b615ecd6778838f92f5e389525a446f286

Merge pull request #28 from m-ou-se/master Add myself.

view details

push time in 2 days

PR merged rust-lang/thanks

Add myself.
+1 -0

0 comment

1 changed file

m-ou-se

pr closed time in 2 days

pull request commentrust-lang/rust

Turn quadratic time on number of impl blocks into linear time

We don't currently record self profile data for rustc compilation.

est31

comment created time in 2 days

push eventrust-lang/thanks

Deploy from CI

commit sha 5dfb534840fdfeacb562ad603a59ce134265a5a6

Deploy 5ed3a3eda6783092085ed9f3196327be9cf003aa to gh-pages

view details

push time in 2 days

pull request commentrust-lang/rust

Turn quadratic time on number of impl blocks into linear time

I would not look at incremental benchmarks on PRs like this - they're not likely to be super meaningful as an expression of improvement (or regression) because they are skipping parts of the build, and unless we think this optimization permits skipping more (seems unlikely), the percent win there is just larger because the base is smaller.

It looks like this is about a 1% win in practice instruction counts wise, but appears to be a regression on wall times (e.g. rustc middle regressed roughly 2 seconds, it looks like).

I think we are least don't have solid evidence this is a win on the code examples tested by perf. I'm not sure if perhaps switching algorithms when we detect n > 30 or something like that makes sense?

est31

comment created time in 2 days

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 6f66d601c54b4d298f74bbc22879ea7900940b82

Automatic stats update

view details

push time in 3 days

pull request commentrust-lang/rust

Fix inconsistencies in handling of inert attributes on statements

Nominating for lang team, I suspect we'll want to just let this go through (it's not really breaking) but it's an interesting question of whether these documentation comments are truly unused.

Aaron1011

comment created time in 3 days

PR opened rust-lang/homu

Store cache locally

EFS is shared between the (potentially multiple) instances of bors which are running, and in general the git lockfile can get left spuriously behind (e.g., if we end up aborting not-nicely). The rust repository is not that big especially without submodules too.

+0 -1

0 comment

1 changed file

pr created time in 3 days

create barnchrust-lang/homu

branch : no-shared-cache

created branch time in 3 days

issue commentrust-lang/rust

Replace submodules with subtrees

Probably we want to call it rustc-subtree then, or something like that. Doesn't seem like a huge concern -- people interacting with it are a relatively small set, hopefully.

oli-obk

comment created time in 3 days

pull request commentrust-lang/measureme

Decode paged buffers from memory

Thanks! I think this is still good to merge (we might want to adjust the 3 buffer taking function to be private since it seems likely useless now, though I'd prefer to do that in a separate PR).

Mark-Simulacrum

comment created time in 3 days

Pull request review commentrust-lang/blog.rust-lang.org

Core team membership changes

+---+layout: post+title: "Core team membership changes"+author: Mark Rousskov+team: The Core Team <https://www.rust-lang.org/governance/teams/core>+---++The core team has had a few membership updates in the last month, and we wanted to provide an update.

Seems fine as is

Mark-Simulacrum

comment created time in 3 days

PullRequestReviewEvent

delete branch Mark-Simulacrum/blog.rust-lang.org

delete branch : core-team

delete time in 3 days

push eventrust-lang/blog.rust-lang.org

Mark Rousskov

commit sha 17519a8f45877dbfaabb390abf1d4f483e0325c6

Core team membership changes

view details

Mark Rousskov

commit sha 9feb096cd3d949b48233a09cf73389727f772815

Merge pull request #716 from Mark-Simulacrum/core-team Core team membership changes

view details

push time in 3 days

delete branch Mark-Simulacrum/team

delete branch : core-update

delete time in 3 days

push eventrust-lang/team

Mark Rousskov

commit sha c56a7d7147f6218839d218f2dae5f4513b7daf77

Carol is stepping down from the core team

view details

Mark Rousskov

commit sha c19e05c072a25238cfcf8fd2f42d3f0d98d5cd43

Merge pull request #460 from Mark-Simulacrum/core-update Carol is stepping down from the core team

view details

push time in 3 days

more