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

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

Mark-Simulacrum/amd-resolver 0

Resolve AMD module names to File objects

delete branch Mark-Simulacrum/triagebot

delete branch : codeblock-mentions

delete time in a minute

push eventrust-lang/triagebot

Mark Rousskov

commit sha 8532c3b30e1fbb465ae4487760e1915251f1af51

Skip mentions inside codeblocks

view details

push time in a minute

PR merged rust-lang/triagebot

Skip mentions inside codeblocks

This replaces the regex-based mention parser with a more thorough implementation. Unfortunately, I wasn't able to find the precise algorithm GitHub uses for the mention syntax, and testing seemed inconclusive (at least, non-ASCII alphabetic characters have different results as a precursor to the @ sign than ASCII onces...)?

For now, go with a relatively simple (though plausibly wrong) set of characters allowed in usernames and a separate set of disallowed characters.

+95 -5

0 comment

3 changed files

Mark-Simulacrum

pr closed time in a minute

PR opened rust-lang/triagebot

Skip mentions inside codeblocks

This replaces the regex-based mention parser with a more thorough implementation. Unfortunately, I wasn't able to find the precise algorithm GitHub uses for the mention syntax, and testing seemed inconclusive (at least, non-ASCII alphabetic characters have different results as a precursor to the @ sign than ASCII onces...)?

For now, go with a relatively simple (though plausibly wrong) set of characters allowed in usernames and a separate set of disallowed characters.

(Also using this to test pinging in PR comments, hey @Mark-Simulacrum)

+95 -5

0 comment

3 changed files

pr created time in 18 minutes

push eventMark-Simulacrum/triagebot

Mark Rousskov

commit sha f2cd1da2a154511c991270c1173eaf120c46ae9c

Skip mentions inside codeblocks

view details

push time in 31 minutes

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 5f263f100478a5950df8e701ee71d38fcee9f9ae

Automatic stats update

view details

push time in an hour

create barnchMark-Simulacrum/triagebot

branch : codeblock-mentions

created branch time in an hour

pull request commentrust-lang/rust

BTreeMap navigation done safer & faster

Could you provide a medium-level description of what this is doing? I likely don't have enough time to try to reconstruct that from the diff, which looks to be moving a bunch of stuff around (I guess splitting something into two?).

ssomers

comment created time in 3 hours

push eventrust-lang/team

matthewjasper

commit sha bde6f8b54206682e5340d31d00fa25ea074e9c66

Add Zulip Id (#280)

view details

push time in 4 hours

PR merged rust-lang/team

Add Zulip Id
+1 -0

0 comment

1 changed file

matthewjasper

pr closed time in 4 hours

push eventrust-lang/triagebot

Mark Rousskov

commit sha 4ef3ae95f5626d9a6a60e160689b0bb8cc3fd88f

serde's default does not do what we expected for null

view details

push time in 6 hours

delete branch nikomatsakis/rfcs

delete branch : roadmap-2020

delete time in 6 hours

push eventrust-lang/wg-traits

Deploy from CI

commit sha 3bd79b53764cfeb1bf9595e180a0b2691c971537

Deploy c96900430da4802ccdfd78e6ee5807130a75a873 to gh-pages

view details

push time in 7 hours

push eventrust-lang/wg-traits

Deploy from CI

commit sha bd0fde7c8ecc6d349f22712e40290c3d281c1464

Deploy 7b31305a9dfbed4303a4322f388116b68ebb3e6a to gh-pages

view details

push time in 9 hours

push eventrust-lang/triagebot

Mark Rousskov

commit sha 1685ef5f4e564b84d2008a8caa1931dd8c7ba897

Pull request review bodies may be null We should interpret these as empty bodies rather than erroring out

view details

push time in 10 hours

push eventrust-lang/thanks

Deploy from CI

commit sha 6639ff1899ec2f214971fbcdbef5374e825ebe06

Deploy f6d7fe6f2abe92bf0695bcec69ccd6ba861067d7 to gh-pages

view details

push time in 10 hours

push eventrust-lang/triagebot

Mark Rousskov

commit sha 24112cf8aa639de46e1f1923f774aa2b908102ba

Do not expect repository_url in pull_request Unfortunately, it looks like the pull_request_review_comment endpoint does not provide this field (despite otherwise being very much similar). It does seem to provide the comments_url field though so just pull the relevant information from there.

view details

push time in 10 hours

push eventrust-lang/triagebot

Mark Rousskov

commit sha 0a55ae9e95672d523d3afcc819b2b5fe19341419

Reply to GitHub with context for error

view details

push time in 10 hours

push eventrust-lang/triagebot

Mark Rousskov

commit sha 2f959424884c9de0c999d89c52c1486e0e38237b

Fix contexts to properly note failure

view details

Mark Rousskov

commit sha d6bd972a5b2e945a29a54d21d9ad6285c0c40b05

Note deserialization failure path

view details

push time in 11 hours

pull request commentrust-lang/rust

x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy

Huh, I'm pretty sure I ran that with the clippy I had (a stable clippy) and it didn't work.

x.py for the cargo function.

matthiaskrgr

comment created time in 14 hours

pull request commentrust-lang/rust

x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy

Here's a proposal:

We edit clippy-driver (or whatever the clippy we're using is) to provide the "channel" in the --version (e.g., nightly, beta, etc.). I think this is the easiest way for us to determine what "stage" we should be running in.

Then we modify the cargo function to, if we're running cargo clippy, get the version information and if it's a nightly clippy, force stage 1, if it's a beta clippy, force stage 0, and if it's a stable clippy use stage 0 but print a warning that it's not really supported to do that.

This would, I think, work well. However, it's quite a bit of work (and we'd need to wait for the channel printing to roll out) -- I would propose that in this PR we just set stage = 1 if we're running cargo clippy and document that you should be using nightly.

I think that should work, right? And we'd presumably not need any of the other changes then?

matthiaskrgr

comment created time in a day

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 3935cc34baf8516b86eec03c21ec0e2ea2da3e94

Automatic stats update

view details

push time in a day

pull request commentrust-lang/rust

[stable] Cherry-pick LLVM fix for 1.41.1

We're currently planning on releasing the new version (i.e., with the LLVM backport).

pietroalbini

comment created time in a day

pull request commentrust-lang/rust

x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy

Hm, so AFAIK x.py clippy today is just using the clippy it finds in the environment, right? Can we perhaps make sure that's a nightly clippy (e.g,. running cargo +nightly clippy) or so?

Basically I feel like this is going to some non-trivial effort to patch over the fact that we're using different versions of clippy and we don't know what we're using which feels like it's never going to work out quite as well as trying to detect what we're using. We should likely also be using the same cargo as the clippy we're using, right? vs. using the beta cargo with (for example) a nightly clippy?

matthiaskrgr

comment created time in a day

pull request commentrust-lang/rust

[master] Backport release notes of 1.41.1

(beta accepting, but see also https://github.com/rust-lang/rust/pull/69467)

pietroalbini

comment created time in a day

pull request commentrust-lang/rust

[master] Backport release notes of 1.41.1

@bors r+ rollup=always

pietroalbini

comment created time in a day

pull request commentrust-lang/rust

[beta] Backport release notes of 1.41.1

hm, is there a reason for a direct beta backport vs. our "usual" policy of just beta-nominating?

pietroalbini

comment created time in a day

pull request commentrust-lang/rust

Remove "unnecessary `unsafe` block in `unsafe` fn" lint

Presumably you'd set #![deny(the_new_at_first_allow_by_default_warning)] instead.

If we're suggesting this as the true path to migration, maybe just having that lint is enough? I imagine 90% of unsafe code authors would eagerly migrate over to it where applicable pretty much right way. And we avoid heuristics...

LeSeulArtichaut

comment created time in a day

Pull request review commentrust-lang/rust

Amend Rc/Arc::from_raw() docs regarding unsafety

 impl<T: ?Sized> Rc<T> {         ptr     } -    /// Constructs an `Rc` from a raw pointer.+    /// Constructs an `Rc<T>` from a raw pointer.     ///-    /// The raw pointer must have been previously returned by a call to a-    /// [`Rc::into_raw`][into_raw].+    /// The raw pointer must have been previously returned by a call to+    /// [`Rc<U>::into_raw`][into_raw] where `U` must have the same size+    /// and alignment as `T`. This is trivially true if `U` is `T`.+    /// Note that if `U` is not `T` but has the same size and alignment, this is+    /// basically like transmuting references of different types. See+    /// [`mem::transmute`][transmute] for more information on what+    /// restrictions apply in this case.     ///-    /// This function is unsafe because improper use may lead to memory problems. For example, a-    /// double-free may occur if the function is called twice on the same raw pointer.+    /// The user of `from_raw` has to make sure a specific value of `T` is only+    /// dropped once.

I think it's certainly more detailed :)

However, I think it should clarify that even if you know T is safe to drop lots of times (e.g., () unit type), it is still not okay to let Rc drop more than once for the "last" time.

lukaslueg

comment created time in a day

pull request commentrust-lang/rust

Upgrade dependencies

Please do split out changes to dependencies of std (and friends), like hashbrown. I would also ask that the polonius changes are either dropped or split to a separate PR at least -- I'm not sure whether just updating polonius makes sense (cc @matthewjasper, perhaps?)

mati865

comment created time in a day

push eventrust-lang/thanks

Deploy from CI

commit sha e1f41aee0dd97d76db4ae4a9d62da88aba0a7ff1

Deploy f6d7fe6f2abe92bf0695bcec69ccd6ba861067d7 to gh-pages

view details

push time in a day

issue commentrust-lang/rust

`is_x86_feature_detected!("avx512f")` fails to build on nightly

To be clear, stable today has the list in https://github.com/rust-lang/rust/issues/68905#issuecomment-589098209 stabilized, which includes mmx -- we can technically say "woops" I guess and revert that to being unstable, but that seems not great. (Though if there are good reasons to do so, then perhaps we should.)

oconnor663

comment created time in a day

pull request commentrust-lang/rust

Add option for deterministic hashing

I tend to agree that I would feel this needs some wider discussion with the community.

I am also not sure that I want this -- it feels like we would rather expect this to be something like a configuration flag to std (e.g., Cargo feature). I don't think Cargo's std-aware support is far enough along to support that, though, if it's intended for debugging (you'd need to rebuild the compiler and that's rather hard).

I would also personally suspect that randomness isolation like this is best done at the system level -- but I don't know enough about platforms to know how much support they provide for that. I would hope that there's existing tooling that makes something like getrandom consistently seeded, versus pulling from "true" entropy.

I think if we do pursue this, I would personally rather put this in something like core, and essentially be a single global flag that can be set at most once -- basically core::hint::should_be_deterministic() or something like that. We would then encourage rand and similar crates to use it.

smoelius

comment created time in a day

pull request commentrust-lang/rust

[WIP] Add `From<(Vec<T>, C)>` for BinaryHeap a.k.a. flexible `BinaryHeap`

I don't personally think this is something we want. Most users should likely be satisfied with a wrapper struct with a similar structure to what you have here, and something more involved can likely be dealt with by wrapping BinaryHeap itself (e.g., CustomBinaryHeap) and internally wrapping as needed. AFAIK, the special casing of the ordering function is quite rare, so this would be a relatively niche extension, too.

I think implementing this in the ecosystem may be the better option to start with; it would (AFAICT) be instantly a stable implementation detail that the struct has a custom comparator with is a pretty high bar to meet.

(To be clear, my opinions are not the library team's who would be responsible for ultimately accepting this. But I believe these are reasonable concerns to have some answer to before bringing it to a wider audience).

sekineh

comment created time in a day

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

 impl DiagnosticCode {                 DiagnosticId::Error(s) => s,                 DiagnosticId::Lint(s) => s,             };-            let explanation =-                je.registry.as_ref().and_then(|registry| registry.find_description(&s));+            let reg_result =+                je.registry.as_ref().and_then(|registry| Some(registry.find_description(&s)));+            let reg_result = reg_result.unwrap();++            let explanation = match reg_result {+                HasLongDescription(s) => Some(s),+                _ => None,

Doesn't matter too much. Just panic!("unexpected invalid error code {}", code); would be fine.

jakevossen5

comment created time in 2 days

pull request commentrust-lang/rust

Allow getting `no_std` from the config file

@bors r+

Ericson2314

comment created time in 2 days

Pull request review commentrust-lang/rust

tidy: Better license checks.

 const LICENSES: &[&str] = &[ /// should be considered bugs. Exceptions are only allowed in Rust /// tooling. It is _crucial_ that no exception crates be dependencies /// of the Rust runtime (std/test).-const EXCEPTIONS: &[&str] = &[-    "mdbook",             // MPL2, mdbook-    "openssl",            // BSD+advertising clause, cargo, mdbook-    "pest",               // MPL2, mdbook via handlebars-    "arrayref",           // BSD-2-Clause, mdbook via handlebars via pest-    "thread-id",          // Apache-2.0, mdbook-    "toml-query",         // MPL-2.0, mdbook-    "is-match",           // MPL-2.0, mdbook-    "cssparser",          // MPL-2.0, rustdoc-    "smallvec",           // MPL-2.0, rustdoc-    "rdrand",             // ISC, mdbook, rustfmt-    "fuchsia-cprng",      // BSD-3-Clause, mdbook, rustfmt-    "fuchsia-zircon-sys", // BSD-3-Clause, rustdoc, rustc, cargo-    "fuchsia-zircon",     // BSD-3-Clause, rustdoc, rustc, cargo (jobserver & tempdir)-    "cssparser-macros",   // MPL-2.0, rustdoc-    "selectors",          // MPL-2.0, rustdoc-    "clippy_lints",       // MPL-2.0, rls-    "colored",            // MPL-2.0, rustfmt-    "ordslice",           // Apache-2.0, rls-    "cloudabi",           // BSD-2-Clause, (rls -> crossbeam-channel 0.2 -> rand 0.5)-    "ryu",                // Apache-2.0, rls/cargo/... (because of serde)-    "bytesize",           // Apache-2.0, cargo-    "im-rc",              // MPL-2.0+, cargo-    "adler32",            // BSD-3-Clause AND Zlib, cargo dep that isn't used-    "constant_time_eq",   // CC0-1.0, rustfmt-    "utf8parse",          // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "vte",                // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "sized-chunks",       // MPL-2.0+, cargo via im-rc-    "bitmaps",            // MPL-2.0+, cargo via im-rc+const EXCEPTIONS: &[(&str, &str)] = &[+    ("mdbook", "MPL-2.0"),                  // mdbook+    ("openssl", "Apache-2.0"),              // cargo, mdbook+    ("arrayref", "BSD-2-Clause"),           // mdbook via handlebars via pest+    ("toml-query", "MPL-2.0"),              // mdbook+    ("toml-query_derive", "MPL-2.0"),       // mdbook+    ("is-match", "MPL-2.0"),                // mdbook+    ("rdrand", "ISC"),                      // mdbook, rustfmt+    ("fuchsia-cprng", "BSD-3-Clause"),      // mdbook, rustfmt+    ("fuchsia-zircon-sys", "BSD-3-Clause"), // rustdoc, rustc, cargo+    ("fuchsia-zircon", "BSD-3-Clause"),     // rustdoc, rustc, cargo (jobserver & tempdir)+    ("colored", "MPL-2.0"),                 // rustfmt+    ("ordslice", "Apache-2.0"),             // rls+    ("cloudabi", "BSD-2-Clause"),           // (rls -> crossbeam-channel 0.2 -> rand 0.5)+    ("ryu", "Apache-2.0 OR BSL-1.0"),       // rls/cargo/... (because of serde)+    ("bytesize", "Apache-2.0"),             // cargo+    ("im-rc", "MPL-2.0+"),                  // cargo+    ("adler32", "BSD-3-Clause AND Zlib"),   // cargo dep that isn't used+    ("constant_time_eq", "CC0-1.0"),        // rustfmt+    ("sized-chunks", "MPL-2.0+"),           // cargo via im-rc+    ("bitmaps", "MPL-2.0+"),                // cargo via im-rc     // FIXME: this dependency violates the documentation comment above:-    "fortanix-sgx-abi",   // MPL-2.0+, libstd but only for `sgx` target-    "dunce",              // CC0-1.0 mdbook-linkcheck-    "codespan-reporting", // Apache-2.0 mdbook-linkcheck-    "codespan",           // Apache-2.0 mdbook-linkcheck-    "crossbeam-channel",  // MIT/Apache-2.0 AND BSD-2-Clause, cargo+    ("fortanix-sgx-abi", "MPL-2.0"), // libstd but only for `sgx` target+    ("dunce", "CC0-1.0"),            // mdbook-linkcheck+    ("codespan-reporting", "Apache-2.0"), // mdbook-linkcheck+    ("codespan", "Apache-2.0"),      // mdbook-linkcheck+    ("crossbeam-channel", "MIT/Apache-2.0 AND BSD-2-Clause"), // cargo ]; +/// These are the root crates that are part of the runtime. The licenses for+/// these and all their dependencies *must not* be in the exception list.+const RUNTIME_CRATES: &[&str] = &["std", "core", "alloc", "panic_abort", "panic_unwind"];+ /// Which crates to check against the whitelist?-const WHITELIST_CRATES: &[CrateVersion<'_>] =-    &[CrateVersion("rustc", "0.0.0"), CrateVersion("rustc_codegen_llvm", "0.0.0")];+const WHITELIST_CRATES: &[&str] = &["rustc", "rustc_codegen_llvm"];  /// Whitelist of crates rustc is allowed to depend on. Avoid adding to the list if possible.-const WHITELIST: &[Crate<'_>] = &[-    Crate("adler32"),-    Crate("aho-corasick"),-    Crate("annotate-snippets"),-    Crate("ansi_term"),-    Crate("arrayvec"),-    Crate("atty"),-    Crate("autocfg"),-    Crate("backtrace"),-    Crate("backtrace-sys"),-    Crate("bitflags"),-    Crate("build_const"),-    Crate("byteorder"),-    Crate("c2-chacha"),-    Crate("cc"),-    Crate("cfg-if"),-    Crate("chalk-engine"),-    Crate("chalk-macros"),-    Crate("cloudabi"),-    Crate("cmake"),-    Crate("compiler_builtins"),-    Crate("crc"),-    Crate("crc32fast"),-    Crate("crossbeam-deque"),-    Crate("crossbeam-epoch"),-    Crate("crossbeam-queue"),-    Crate("crossbeam-utils"),-    Crate("datafrog"),-    Crate("dlmalloc"),-    Crate("either"),-    Crate("ena"),-    Crate("env_logger"),-    Crate("filetime"),-    Crate("flate2"),-    Crate("fortanix-sgx-abi"),-    Crate("fuchsia-zircon"),-    Crate("fuchsia-zircon-sys"),-    Crate("getopts"),-    Crate("getrandom"),-    Crate("hashbrown"),-    Crate("humantime"),-    Crate("indexmap"),-    Crate("itertools"),-    Crate("jobserver"),-    Crate("kernel32-sys"),-    Crate("lazy_static"),-    Crate("libc"),-    Crate("libz-sys"),-    Crate("lock_api"),-    Crate("log"),-    Crate("log_settings"),-    Crate("measureme"),-    Crate("memchr"),-    Crate("memmap"),-    Crate("memoffset"),-    Crate("miniz-sys"),-    Crate("miniz_oxide"),-    Crate("miniz_oxide_c_api"),-    Crate("nodrop"),-    Crate("num_cpus"),-    Crate("owning_ref"),-    Crate("parking_lot"),-    Crate("parking_lot_core"),-    Crate("pkg-config"),-    Crate("polonius-engine"),-    Crate("ppv-lite86"),-    Crate("proc-macro2"),-    Crate("punycode"),-    Crate("quick-error"),-    Crate("quote"),-    Crate("rand"),-    Crate("rand_chacha"),-    Crate("rand_core"),-    Crate("rand_hc"),-    Crate("rand_isaac"),-    Crate("rand_pcg"),-    Crate("rand_xorshift"),-    Crate("redox_syscall"),-    Crate("redox_termios"),-    Crate("regex"),-    Crate("regex-syntax"),-    Crate("remove_dir_all"),-    Crate("rustc-demangle"),-    Crate("rustc-hash"),-    Crate("rustc-rayon"),-    Crate("rustc-rayon-core"),-    Crate("rustc_version"),-    Crate("scoped-tls"),-    Crate("scopeguard"),-    Crate("semver"),-    Crate("semver-parser"),-    Crate("serde"),-    Crate("serde_derive"),-    Crate("smallvec"),-    Crate("stable_deref_trait"),-    Crate("syn"),-    Crate("synstructure"),-    Crate("tempfile"),-    Crate("termcolor"),-    Crate("terminon"),-    Crate("termion"),-    Crate("termize"),-    Crate("thread_local"),-    Crate("ucd-util"),-    Crate("unicode-normalization"),-    Crate("unicode-script"),-    Crate("unicode-security"),-    Crate("unicode-width"),-    Crate("unicode-xid"),-    Crate("unreachable"),-    Crate("utf8-ranges"),-    Crate("vcpkg"),-    Crate("version_check"),-    Crate("void"),-    Crate("wasi"),-    Crate("winapi"),-    Crate("winapi-build"),-    Crate("winapi-i686-pc-windows-gnu"),-    Crate("winapi-util"),-    Crate("winapi-x86_64-pc-windows-gnu"),-    Crate("wincolor"),-    Crate("hermit-abi"),+///+/// This list is here to provide a speed-bump to adding a new dependency to+/// rustc. Please check with the compiler team before adding an entry.+const WHITELIST: &[&str] = &[+    "adler32",+    "aho-corasick",+    "annotate-snippets",+    "ansi_term",+    "arrayvec",+    "atty",+    "autocfg",+    "backtrace",+    "backtrace-sys",+    "bitflags",+    "byteorder",+    "c2-chacha",+    "cc",+    "cfg-if",+    "chalk-engine",+    "chalk-macros",+    "cloudabi",+    "cmake",+    "compiler_builtins",+    "crc32fast",+    "crossbeam-deque",+    "crossbeam-epoch",+    "crossbeam-queue",+    "crossbeam-utils",+    "datafrog",+    "dlmalloc",+    "either",+    "ena",+    "env_logger",+    "filetime",+    "flate2",+    "fortanix-sgx-abi",+    "fuchsia-zircon",+    "fuchsia-zircon-sys",+    "getopts",+    "getrandom",+    "hashbrown",+    "humantime",+    "indexmap",+    "itertools",+    "jobserver",+    "kernel32-sys",+    "lazy_static",+    "libc",+    "libz-sys",+    "lock_api",+    "log",+    "log_settings",+    "measureme",+    "memchr",+    "memmap",+    "memoffset",+    "miniz_oxide",+    "nodrop",+    "num_cpus",+    "parking_lot",+    "parking_lot_core",+    "pkg-config",+    "polonius-engine",+    "ppv-lite86",+    "proc-macro2",+    "punycode",+    "quick-error",+    "quote",+    "rand",+    "rand_chacha",+    "rand_core",+    "rand_hc",+    "rand_isaac",+    "rand_pcg",+    "rand_xorshift",+    "redox_syscall",+    "redox_termios",+    "regex",+    "regex-syntax",+    "remove_dir_all",+    "rustc-demangle",+    "rustc-hash",+    "rustc-rayon",+    "rustc-rayon-core",+    "rustc_version",+    "scoped-tls",+    "scopeguard",+    "semver",+    "semver-parser",+    "serde",+    "serde_derive",+    "smallvec",+    "stable_deref_trait",+    "syn",+    "synstructure",+    "tempfile",+    "termcolor",+    "termion",+    "termize",+    "thread_local",+    "ucd-util",+    "unicode-normalization",+    "unicode-script",+    "unicode-security",+    "unicode-width",+    "unicode-xid",+    "utf8-ranges",+    "vcpkg",+    "version_check",+    "wasi",+    "winapi",+    "winapi-build",+    "winapi-i686-pc-windows-gnu",+    "winapi-util",+    "winapi-x86_64-pc-windows-gnu",+    "wincolor",+    "hermit-abi", ]; -// Some types for Serde to deserialize the output of `cargo metadata` to.--#[derive(Deserialize)]-struct Output {-    resolve: Resolve,-}--#[derive(Deserialize)]-struct Resolve {-    nodes: Vec<ResolveNode>,-}--#[derive(Deserialize)]-struct ResolveNode {-    id: String,-    dependencies: Vec<String>,-}--/// A unique identifier for a crate.-#[derive(Copy, Clone, PartialOrd, Ord, PartialEq, Eq, Debug, Hash)]-struct Crate<'a>(&'a str); // (name)--#[derive(Copy, Clone, PartialOrd, Ord, PartialEq, Eq, Debug, Hash)]-struct CrateVersion<'a>(&'a str, &'a str); // (name, version)--impl Crate<'_> {-    pub fn id_str(&self) -> String {-        format!("{} ", self.0)-    }-}--impl<'a> CrateVersion<'a> {-    /// Returns the struct and whether or not the dependency is in-tree.-    pub fn from_str(s: &'a str) -> (Self, bool) {-        let mut parts = s.split(' ');-        let name = parts.next().unwrap();-        let version = parts.next().unwrap();-        let path = parts.next().unwrap();--        let is_path_dep = path.starts_with("(path+");--        (CrateVersion(name, version), is_path_dep)-    }--    pub fn id_str(&self) -> String {-        format!("{} {}", self.0, self.1)-    }+/// Dependency checks.+///+/// `path` is path to the `src` directory, `cargo` is path to the cargo executable.+pub fn check(path: &Path, cargo: &Path, bad: &mut bool) {+    let mut cmd = cargo_metadata::MetadataCommand::new();+    cmd.cargo_path(cargo)+        .manifest_path(path.parent().unwrap().join("Cargo.toml"))+        .features(cargo_metadata::CargoOpt::AllFeatures);+    let metadata = t!(cmd.exec());+    check_exceptions(&metadata, bad);+    check_whitelist(&metadata, bad);+    check_crate_duplicate(&metadata, bad); } -impl<'a> From<CrateVersion<'a>> for Crate<'a> {-    fn from(cv: CrateVersion<'a>) -> Crate<'a> {-        Crate(cv.0)+/// Check that all licenses are in the valid list in `LICENSES`.+///+/// Packages listed in `EXCEPTIONS` are allowed for tools.+fn check_exceptions(metadata: &Metadata, bad: &mut bool) {+    // Validate the EXCEPTIONS list hasn't changed.+    for (name, license) in EXCEPTIONS {+        // Check that the package actually exists.+        if !metadata.packages.iter().any(|p| p.name == *name) {+            println!(+                "could not find exception package `{}`\n\+                Remove from EXCEPTIONS list if it is no longer used.",+                name+            );+            *bad = true;+        }+        // Check that the license hasn't changed.+        for pkg in metadata.packages.iter().filter(|p| p.name == *name) {+            if pkg.name == "fuchsia-cprng" {+                // This package doesn't declare a license expression. Manual+                // inspection of the license file is necessary, which appears+                // to be BSD-3-Clause.+                assert!(pkg.license.is_none());

cc @cramertj (?) -- could we get this populated perhaps?

ehuss

comment created time in 2 days

Pull request review commentrust-lang/rust

tidy: Better license checks.

 const LICENSES: &[&str] = &[ /// should be considered bugs. Exceptions are only allowed in Rust /// tooling. It is _crucial_ that no exception crates be dependencies /// of the Rust runtime (std/test).-const EXCEPTIONS: &[&str] = &[-    "mdbook",             // MPL2, mdbook-    "openssl",            // BSD+advertising clause, cargo, mdbook-    "pest",               // MPL2, mdbook via handlebars-    "arrayref",           // BSD-2-Clause, mdbook via handlebars via pest-    "thread-id",          // Apache-2.0, mdbook-    "toml-query",         // MPL-2.0, mdbook-    "is-match",           // MPL-2.0, mdbook-    "cssparser",          // MPL-2.0, rustdoc-    "smallvec",           // MPL-2.0, rustdoc-    "rdrand",             // ISC, mdbook, rustfmt-    "fuchsia-cprng",      // BSD-3-Clause, mdbook, rustfmt-    "fuchsia-zircon-sys", // BSD-3-Clause, rustdoc, rustc, cargo-    "fuchsia-zircon",     // BSD-3-Clause, rustdoc, rustc, cargo (jobserver & tempdir)-    "cssparser-macros",   // MPL-2.0, rustdoc-    "selectors",          // MPL-2.0, rustdoc-    "clippy_lints",       // MPL-2.0, rls-    "colored",            // MPL-2.0, rustfmt-    "ordslice",           // Apache-2.0, rls-    "cloudabi",           // BSD-2-Clause, (rls -> crossbeam-channel 0.2 -> rand 0.5)-    "ryu",                // Apache-2.0, rls/cargo/... (because of serde)-    "bytesize",           // Apache-2.0, cargo-    "im-rc",              // MPL-2.0+, cargo-    "adler32",            // BSD-3-Clause AND Zlib, cargo dep that isn't used-    "constant_time_eq",   // CC0-1.0, rustfmt-    "utf8parse",          // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "vte",                // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "sized-chunks",       // MPL-2.0+, cargo via im-rc-    "bitmaps",            // MPL-2.0+, cargo via im-rc+const EXCEPTIONS: &[(&str, &str)] = &[+    ("mdbook", "MPL-2.0"),                  // mdbook+    ("openssl", "Apache-2.0"),              // cargo, mdbook+    ("arrayref", "BSD-2-Clause"),           // mdbook via handlebars via pest+    ("toml-query", "MPL-2.0"),              // mdbook+    ("toml-query_derive", "MPL-2.0"),       // mdbook+    ("is-match", "MPL-2.0"),                // mdbook+    ("rdrand", "ISC"),                      // mdbook, rustfmt+    ("fuchsia-cprng", "BSD-3-Clause"),      // mdbook, rustfmt+    ("fuchsia-zircon-sys", "BSD-3-Clause"), // rustdoc, rustc, cargo+    ("fuchsia-zircon", "BSD-3-Clause"),     // rustdoc, rustc, cargo (jobserver & tempdir)+    ("colored", "MPL-2.0"),                 // rustfmt+    ("ordslice", "Apache-2.0"),             // rls+    ("cloudabi", "BSD-2-Clause"),           // (rls -> crossbeam-channel 0.2 -> rand 0.5)+    ("ryu", "Apache-2.0 OR BSL-1.0"),       // rls/cargo/... (because of serde)+    ("bytesize", "Apache-2.0"),             // cargo+    ("im-rc", "MPL-2.0+"),                  // cargo+    ("adler32", "BSD-3-Clause AND Zlib"),   // cargo dep that isn't used+    ("constant_time_eq", "CC0-1.0"),        // rustfmt+    ("sized-chunks", "MPL-2.0+"),           // cargo via im-rc+    ("bitmaps", "MPL-2.0+"),                // cargo via im-rc     // FIXME: this dependency violates the documentation comment above:-    "fortanix-sgx-abi",   // MPL-2.0+, libstd but only for `sgx` target-    "dunce",              // CC0-1.0 mdbook-linkcheck-    "codespan-reporting", // Apache-2.0 mdbook-linkcheck-    "codespan",           // Apache-2.0 mdbook-linkcheck-    "crossbeam-channel",  // MIT/Apache-2.0 AND BSD-2-Clause, cargo+    ("fortanix-sgx-abi", "MPL-2.0"), // libstd but only for `sgx` target+    ("dunce", "CC0-1.0"),            // mdbook-linkcheck+    ("codespan-reporting", "Apache-2.0"), // mdbook-linkcheck+    ("codespan", "Apache-2.0"),      // mdbook-linkcheck+    ("crossbeam-channel", "MIT/Apache-2.0 AND BSD-2-Clause"), // cargo ]; +/// These are the root crates that are part of the runtime. The licenses for+/// these and all their dependencies *must not* be in the exception list.+const RUNTIME_CRATES: &[&str] = &["std", "core", "alloc", "panic_abort", "panic_unwind"];+ /// Which crates to check against the whitelist?-const WHITELIST_CRATES: &[CrateVersion<'_>] =-    &[CrateVersion("rustc", "0.0.0"), CrateVersion("rustc_codegen_llvm", "0.0.0")];+const WHITELIST_CRATES: &[&str] = &["rustc", "rustc_codegen_llvm"];  /// Whitelist of crates rustc is allowed to depend on. Avoid adding to the list if possible.-const WHITELIST: &[Crate<'_>] = &[-    Crate("adler32"),-    Crate("aho-corasick"),-    Crate("annotate-snippets"),-    Crate("ansi_term"),-    Crate("arrayvec"),-    Crate("atty"),-    Crate("autocfg"),-    Crate("backtrace"),-    Crate("backtrace-sys"),-    Crate("bitflags"),-    Crate("build_const"),-    Crate("byteorder"),-    Crate("c2-chacha"),-    Crate("cc"),-    Crate("cfg-if"),-    Crate("chalk-engine"),-    Crate("chalk-macros"),-    Crate("cloudabi"),-    Crate("cmake"),-    Crate("compiler_builtins"),-    Crate("crc"),-    Crate("crc32fast"),-    Crate("crossbeam-deque"),-    Crate("crossbeam-epoch"),-    Crate("crossbeam-queue"),-    Crate("crossbeam-utils"),-    Crate("datafrog"),-    Crate("dlmalloc"),-    Crate("either"),-    Crate("ena"),-    Crate("env_logger"),-    Crate("filetime"),-    Crate("flate2"),-    Crate("fortanix-sgx-abi"),-    Crate("fuchsia-zircon"),-    Crate("fuchsia-zircon-sys"),-    Crate("getopts"),-    Crate("getrandom"),-    Crate("hashbrown"),-    Crate("humantime"),-    Crate("indexmap"),-    Crate("itertools"),-    Crate("jobserver"),-    Crate("kernel32-sys"),-    Crate("lazy_static"),-    Crate("libc"),-    Crate("libz-sys"),-    Crate("lock_api"),-    Crate("log"),-    Crate("log_settings"),-    Crate("measureme"),-    Crate("memchr"),-    Crate("memmap"),-    Crate("memoffset"),-    Crate("miniz-sys"),-    Crate("miniz_oxide"),-    Crate("miniz_oxide_c_api"),-    Crate("nodrop"),-    Crate("num_cpus"),-    Crate("owning_ref"),-    Crate("parking_lot"),-    Crate("parking_lot_core"),-    Crate("pkg-config"),-    Crate("polonius-engine"),-    Crate("ppv-lite86"),-    Crate("proc-macro2"),-    Crate("punycode"),-    Crate("quick-error"),-    Crate("quote"),-    Crate("rand"),-    Crate("rand_chacha"),-    Crate("rand_core"),-    Crate("rand_hc"),-    Crate("rand_isaac"),-    Crate("rand_pcg"),-    Crate("rand_xorshift"),-    Crate("redox_syscall"),-    Crate("redox_termios"),-    Crate("regex"),-    Crate("regex-syntax"),-    Crate("remove_dir_all"),-    Crate("rustc-demangle"),-    Crate("rustc-hash"),-    Crate("rustc-rayon"),-    Crate("rustc-rayon-core"),-    Crate("rustc_version"),-    Crate("scoped-tls"),-    Crate("scopeguard"),-    Crate("semver"),-    Crate("semver-parser"),-    Crate("serde"),-    Crate("serde_derive"),-    Crate("smallvec"),-    Crate("stable_deref_trait"),-    Crate("syn"),-    Crate("synstructure"),-    Crate("tempfile"),-    Crate("termcolor"),-    Crate("terminon"),-    Crate("termion"),-    Crate("termize"),-    Crate("thread_local"),-    Crate("ucd-util"),-    Crate("unicode-normalization"),-    Crate("unicode-script"),-    Crate("unicode-security"),-    Crate("unicode-width"),-    Crate("unicode-xid"),-    Crate("unreachable"),-    Crate("utf8-ranges"),-    Crate("vcpkg"),-    Crate("version_check"),-    Crate("void"),-    Crate("wasi"),-    Crate("winapi"),-    Crate("winapi-build"),-    Crate("winapi-i686-pc-windows-gnu"),-    Crate("winapi-util"),-    Crate("winapi-x86_64-pc-windows-gnu"),-    Crate("wincolor"),-    Crate("hermit-abi"),+///+/// This list is here to provide a speed-bump to adding a new dependency to+/// rustc. Please check with the compiler team before adding an entry.+const WHITELIST: &[&str] = &[+    "adler32",+    "aho-corasick",+    "annotate-snippets",+    "ansi_term",+    "arrayvec",+    "atty",+    "autocfg",+    "backtrace",+    "backtrace-sys",+    "bitflags",+    "byteorder",+    "c2-chacha",+    "cc",+    "cfg-if",+    "chalk-engine",+    "chalk-macros",+    "cloudabi",+    "cmake",+    "compiler_builtins",+    "crc32fast",+    "crossbeam-deque",+    "crossbeam-epoch",+    "crossbeam-queue",+    "crossbeam-utils",+    "datafrog",+    "dlmalloc",+    "either",+    "ena",+    "env_logger",+    "filetime",+    "flate2",+    "fortanix-sgx-abi",+    "fuchsia-zircon",+    "fuchsia-zircon-sys",+    "getopts",+    "getrandom",+    "hashbrown",+    "humantime",+    "indexmap",+    "itertools",+    "jobserver",+    "kernel32-sys",+    "lazy_static",+    "libc",+    "libz-sys",+    "lock_api",+    "log",+    "log_settings",+    "measureme",+    "memchr",+    "memmap",+    "memoffset",+    "miniz_oxide",+    "nodrop",+    "num_cpus",+    "parking_lot",+    "parking_lot_core",+    "pkg-config",+    "polonius-engine",+    "ppv-lite86",+    "proc-macro2",+    "punycode",+    "quick-error",+    "quote",+    "rand",+    "rand_chacha",+    "rand_core",+    "rand_hc",+    "rand_isaac",+    "rand_pcg",+    "rand_xorshift",+    "redox_syscall",+    "redox_termios",+    "regex",+    "regex-syntax",+    "remove_dir_all",+    "rustc-demangle",+    "rustc-hash",+    "rustc-rayon",+    "rustc-rayon-core",+    "rustc_version",+    "scoped-tls",+    "scopeguard",+    "semver",+    "semver-parser",+    "serde",+    "serde_derive",+    "smallvec",+    "stable_deref_trait",+    "syn",+    "synstructure",+    "tempfile",+    "termcolor",+    "termion",+    "termize",+    "thread_local",+    "ucd-util",+    "unicode-normalization",+    "unicode-script",+    "unicode-security",+    "unicode-width",+    "unicode-xid",+    "utf8-ranges",+    "vcpkg",+    "version_check",+    "wasi",+    "winapi",+    "winapi-build",+    "winapi-i686-pc-windows-gnu",+    "winapi-util",+    "winapi-x86_64-pc-windows-gnu",+    "wincolor",+    "hermit-abi",

Since we're changing the whole list anyway, mind sorting it while we're at it?

ehuss

comment created time in 2 days

Pull request review commentrust-lang/rust

Miscellaneous cleanup to formatting

 struct Void { #[unstable(feature = "fmt_internals", reason = "internal to format_args!", issue = "none")] #[doc(hidden)] pub struct ArgumentV1<'a> {-    value: &'a Void,-    formatter: fn(&Void, &mut Formatter<'_>) -> Result,+    value: &'a Opaque,+    formatter: fn(&Opaque, &mut Formatter<'_>) -> Result, } -impl<'a> ArgumentV1<'a> {-    #[inline(never)]-    fn show_usize(x: &usize, f: &mut Formatter<'_>) -> Result {-        Display::fmt(x, f)-    }+// This gurantees a single stable value for the function pointer associated with+// indices/counts in the formatting infrastructure.+//+// Note that a function defined as such would not be correct as functions are+// always tagged unnamed_addr with the current lowering to LLVM IR, so their+// address is not considered important to LLVM and as such the as_usize cast+// could have been miscompiled. In practice, we never call as_usize on non-usize+// containing data (as a matter of static generation of the formatting+// arguments), so this is merely an additional check.+#[unstable(feature = "fmt_internals", reason = "internal to format_args!", issue = "none")]+static USIZE_MARKER: fn(&usize, &mut Formatter<'_>) -> Result = |_, _| loop {};

I will try to do this in a follow-up PR to avoid getting this bogged down (and r? you on that one).

Mark-Simulacrum

comment created time in 2 days

pull request commentrust-lang/rust

Relax str::get_unchecked precondition to permit empty slicing

(In hindsight, I missed that this was referring to a range index vs. a usize index).

ridiculousfish

comment created time in 2 days

issue commentrust-lang/measureme

`summarize` shouldn't show columns that don't apply to the profile

Please make sure (or let me know if otherwise) that changes here either do not affect the JSON output (i.e., we should have default values instead of omitting keys.

OTOH, if we do change the JSON output, then that's fine, I can handle it on perf's side, but a heads up would be appreciated.

wesleywiser

comment created time in 2 days

pull request commentrust-lang/rust

Allow getting `no_std` from the config file

Okay, I think the new logic is better, thanks!

@bors r+

Ericson2314

comment created time in 2 days

Pull request review commentrust-lang/rust

x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy

 impl<'a> Builder<'a> {         };          let mut rustflags = Rustflags::new(&target);-        if stage != 0 {+        // nightly clippy needs --cfg=bootstrap to run successfully+        if stage != 0 || cmd == "clippy" {

I am actually rather surprised by us needing to do this, as AFAICT if the cmd is clippy we should always be in stage 0? When is that not the case today?

(and if Clippy is already in stage 0, then the right flags would be in RUSTFLAGS_BOOTSTRAP, right?)

matthiaskrgr

comment created time in 2 days

pull request commentrust-lang/rust

rustc_metadata: Use binary search from standard library

@bors r+ r? @Mark-Simulacrum

petrochenkov

comment created time in 2 days

pull request commentrust-lang/crater

Identify ICEs as separate class of error

Hm, for the latter, I feel like such a test would be rather brittle, in the sense that long-term we would likely fix that ICE? I guess I can select an ICE that is unlikely to get fixed soon (by some heuristic)... would that be what you expected?

Mark-Simulacrum

comment created time in 2 days

push eventMark-Simulacrum/cargobomb

Mark Rousskov

commit sha 707bafeb109726ce7061f2ab8ba8340bebee3724

Test the regression identification

view details

push time in 2 days

Pull request review commentrust-lang/crater

Identify ICEs as separate class of error

 string_enum!(pub enum FailureReason {     Unknown => "unknown",     OOM => "oom",     Timeout => "timeout",+    ICE => "ice", }); +impl Fail for FailureReason {}

I think this feels worse, we don't really want to override the result, just provide the additional metadata that we had an ICE.

Mark-Simulacrum

comment created time in 2 days

Pull request review commentrust-lang/rust

tidy: Better license checks.

 const LICENSES: &[&str] = &[ /// should be considered bugs. Exceptions are only allowed in Rust /// tooling. It is _crucial_ that no exception crates be dependencies /// of the Rust runtime (std/test).-const EXCEPTIONS: &[&str] = &[-    "mdbook",             // MPL2, mdbook-    "openssl",            // BSD+advertising clause, cargo, mdbook-    "pest",               // MPL2, mdbook via handlebars-    "arrayref",           // BSD-2-Clause, mdbook via handlebars via pest-    "thread-id",          // Apache-2.0, mdbook-    "toml-query",         // MPL-2.0, mdbook-    "is-match",           // MPL-2.0, mdbook-    "cssparser",          // MPL-2.0, rustdoc-    "smallvec",           // MPL-2.0, rustdoc-    "rdrand",             // ISC, mdbook, rustfmt-    "fuchsia-cprng",      // BSD-3-Clause, mdbook, rustfmt-    "fuchsia-zircon-sys", // BSD-3-Clause, rustdoc, rustc, cargo-    "fuchsia-zircon",     // BSD-3-Clause, rustdoc, rustc, cargo (jobserver & tempdir)-    "cssparser-macros",   // MPL-2.0, rustdoc-    "selectors",          // MPL-2.0, rustdoc-    "clippy_lints",       // MPL-2.0, rls-    "colored",            // MPL-2.0, rustfmt-    "ordslice",           // Apache-2.0, rls-    "cloudabi",           // BSD-2-Clause, (rls -> crossbeam-channel 0.2 -> rand 0.5)-    "ryu",                // Apache-2.0, rls/cargo/... (because of serde)-    "bytesize",           // Apache-2.0, cargo-    "im-rc",              // MPL-2.0+, cargo-    "adler32",            // BSD-3-Clause AND Zlib, cargo dep that isn't used-    "constant_time_eq",   // CC0-1.0, rustfmt-    "utf8parse",          // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "vte",                // Apache-2.0 OR MIT, cargo via strip-ansi-escapes-    "sized-chunks",       // MPL-2.0+, cargo via im-rc-    "bitmaps",            // MPL-2.0+, cargo via im-rc+const EXCEPTIONS: &[(&str, &str)] = &[+    ("mdbook", "MPL-2.0"),                  // mdbook+    ("openssl", "Apache-2.0"),              // cargo, mdbook+    ("arrayref", "BSD-2-Clause"),           // mdbook via handlebars via pest+    ("toml-query", "MPL-2.0"),              // mdbook+    ("toml-query_derive", "MPL-2.0"),       // mdbook+    ("is-match", "MPL-2.0"),                // mdbook+    ("rdrand", "ISC"),                      // mdbook, rustfmt+    ("fuchsia-cprng", "BSD-3-Clause"),      // mdbook, rustfmt+    ("fuchsia-zircon-sys", "BSD-3-Clause"), // rustdoc, rustc, cargo+    ("fuchsia-zircon", "BSD-3-Clause"),     // rustdoc, rustc, cargo (jobserver & tempdir)+    ("colored", "MPL-2.0"),                 // rustfmt+    ("ordslice", "Apache-2.0"),             // rls+    ("cloudabi", "BSD-2-Clause"),           // (rls -> crossbeam-channel 0.2 -> rand 0.5)+    ("ryu", "Apache-2.0 OR BSL-1.0"),       // rls/cargo/... (because of serde)+    ("bytesize", "Apache-2.0"),             // cargo+    ("im-rc", "MPL-2.0+"),                  // cargo+    ("adler32", "BSD-3-Clause AND Zlib"),   // cargo dep that isn't used+    ("constant_time_eq", "CC0-1.0"),        // rustfmt+    ("sized-chunks", "MPL-2.0+"),           // cargo via im-rc+    ("bitmaps", "MPL-2.0+"),                // cargo via im-rc     // FIXME: this dependency violates the documentation comment above:-    "fortanix-sgx-abi",   // MPL-2.0+, libstd but only for `sgx` target-    "dunce",              // CC0-1.0 mdbook-linkcheck-    "codespan-reporting", // Apache-2.0 mdbook-linkcheck-    "codespan",           // Apache-2.0 mdbook-linkcheck-    "crossbeam-channel",  // MIT/Apache-2.0 AND BSD-2-Clause, cargo+    ("fortanix-sgx-abi", "MPL-2.0"), // libstd but only for `sgx` target+    ("dunce", "CC0-1.0"),            // mdbook-linkcheck+    ("codespan-reporting", "Apache-2.0"), // mdbook-linkcheck+    ("codespan", "Apache-2.0"),      // mdbook-linkcheck+    ("crossbeam-channel", "MIT/Apache-2.0 AND BSD-2-Clause"), // cargo ]; +/// These are the root crates that are part of the runtime. The licenses for+/// these and all their dependencies *must not* be in the exception list.+const RUNTIME_CRATES: &[&str] = &["std", "core", "alloc", "panic_abort", "panic_unwind"];

I think this should include libtest, particularly as it might be linked in for e.g. black_box even in non-test executables.

ehuss

comment created time in 2 days

pull request commentrust-lang/rust

Mark attributes consumed by `check_mod_attrs` as normal

I guess this feels fine to me, but I don't know why this wasn't already the case? Are we in a transition period or something like that? Without that knowledge (and I don't have time to hunt it down), I can't confidently approve this. r? @petrochenkov, I guess, though I'm not sure why @Centril thought that'd be reasonable.

tmiasko

comment created time in 2 days

pull request commentrust-lang/rust

debug_assert a few more raw pointer methods

Oh, actually, that try build is useless as it didn't build with debug-assertions... never mind.

Yeah, I think increasing the slack space here is fine, I was hoping to dig in a bit more and figure out exactly what's changed but I don't think it's worth it, almost no one is going to be running with a debug-assert std anyway.

@bors r+

RalfJung

comment created time in 2 days

pull request commentrust-lang/rust

Remove "unnecessary `unsafe` block in `unsafe` fn" lint

@cramertj's proposal in https://github.com/rust-lang/rust/pull/69245#issuecomment-590473831 seems okay to me. It's a slightly more granular proposal than I had in mind, but it also satisfies the "atomic transition" plan but on a per-function basis and in an automated fashion. I think this might be worse.

In particular, I am still concerned that folks will have trouble identifying whether a function is "new" or "old" -- i.e., if I see no unsafe blocks in my unsafe function, is that function body entirely unsafe (with lots of unsafe calls) or entirely safe code? That's something that @cramertj's proposal, AFAICT, does not solve, in the sense that when transitioning you'd almost want to add a let () = unsafe { () }; to every unsafe function or something like that just to opt-in to the new behavior. With that in mind, I still lean towards a lint that enables the new functionality (and most crates would likely want to opt-in at the root).

LeSeulArtichaut

comment created time in 2 days

pull request commentrust-lang/rust

BTreeMap navigation done safer & faster

I will try to take a look soon, though given the relatively hairy nature of the BTreeMap code it'll likely be some time until I can allocate a big enough block of time to dig in sufficiently.

ssomers

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

+use crate::registry::RegistryResult::HasLongDescription; use rustc_data_structures::fx::FxHashMap; +pub enum RegistryResult {+    InvalidErrorCode,+    NoLongDescription,+    HasLongDescription(&'static str),+}++impl RegistryResult {+    pub fn has_value(&self) -> bool {+        match self {+            HasLongDescription(_s) => true,+            _ => false,+        }+    }+}+ #[derive(Clone)] pub struct Registry {-    descriptions: FxHashMap<&'static str, &'static str>,+    long_descriptions: FxHashMap<&'static str, Option<&'static str>>, }  impl Registry {-    pub fn new(descriptions: &[(&'static str, &'static str)]) -> Registry {-        Registry { descriptions: descriptions.iter().cloned().collect() }+    pub fn new(long_descriptions: &[(&'static str, Option<&'static str>)]) -> Registry {+        Registry { long_descriptions: long_descriptions.iter().cloned().collect() }     } -    pub fn find_description(&self, code: &str) -> Option<&'static str> {-        self.descriptions.get(code).cloned()+    pub fn find_description(&self, code: &str) -> RegistryResult {

Looking at the use sites, it looks like most of the time (well, 2 out of 3?) expect to be passing in a valid code, and we should panic if they don't.

I think we'll want the following API:


#[derive(Debug)]
struct InvalidErrorCode;

/// This will panic if an invalid error code is passed in
pub fn find_description(&self, code: &str) -> Option<&'static str> {
    self.try_find_description(code).unwrap()
}

pub fn try_find_description(&self, code: &str) -> Result<Option<&'static str>, InvalidErrorCode> {
    // ...
}
jakevossen5

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

 impl DiagnosticCode {                 DiagnosticId::Error(s) => s,                 DiagnosticId::Lint(s) => s,             };-            let explanation =-                je.registry.as_ref().and_then(|registry| registry.find_description(&s));+            let reg_result =+                je.registry.as_ref().and_then(|registry| Some(registry.find_description(&s)));+            let reg_result = reg_result.unwrap();++            let explanation = match reg_result {+                HasLongDescription(s) => Some(s),+                _ => None,

Ah, we should actually be able to panic or so if there's an invalid error code getting passed in here, that should never happen (if it does in practice we can fix it in this PR).

jakevossen5

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

 impl DiagnosticCode {                 DiagnosticId::Error(s) => s,                 DiagnosticId::Lint(s) => s,             };-            let explanation =-                je.registry.as_ref().and_then(|registry| registry.find_description(&s));+            let reg_result =+                je.registry.as_ref().and_then(|registry| Some(registry.find_description(&s)));

I think this code'll be easier to read if we have an if let Some(registry) = je.registry { ... } and avoid the combinators on Option here.

jakevossen5

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

 fn handle_explain(registry: Registry, code: &str, output: ErrorOutputType) {                 print!("{}", text);             }         }-        None => {+        NoLongDescription => {             early_error(output, &format!("no extended information for {}", code));         }+        InvalidErrorCode => {+            early_error(output, &format!("{} is not a valid error code ", code));

Yes, this is fine.

jakevossen5

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

 fn handle_explain(registry: Registry, code: &str, output: ErrorOutputType) {                 print!("{}", text);             }         }-        None => {+        NoLongDescription => {             early_error(output, &format!("no extended information for {}", code));         }+        InvalidErrorCode => {+            early_error(output, &format!("{} is not a valid error code ", code));
            early_error(output, &format!("{} is not a valid error code", code));
jakevossen5

comment created time in 2 days

Pull request review commentrust-lang/rust

`--explain` disamiguates no long description and invalid error codes

  macro_rules! register_diagnostics {     ($($ecode:ident: $message:expr,)* ; $($code:ident,)*) => (-        pub static DIAGNOSTICS: &[(&str, &str)] = &[+        pub static DIAGNOSTICS: &[(&str, Option<&str>)] = &[             $( (stringify!($ecode), $message), )*

It looks like at some point this macro was updated and we forgot about the $code argument. We should be able to avoid changing every line in error_codes.rs and instead have this be something like the following, I think.

$( (stringify!($ecode), Some($message)), )*
$( (stringify!($code), None), )*
jakevossen5

comment created time in 2 days

issue commentrust-lang/rust

UTF-8 error unwrap when building project

Interesting. The error happens in the decode implementation for Symbol, specifically the read_str call. This probably means that we're just messed up reading metadata -- i.e., we're not actually reading a string. But I'm not sure why our normal "stale metadata" checking doesn't account for this, I would expect the compiler versions to be different and for us to just not load the metadata at all.

Razican

comment created time in 2 days

IssuesEvent

pull request commentrust-lang/rust

Do not ping PR reviewers in toolstate breakage

I think pinging the PR author is at least reasonable, though I agree that many PR authors in practice won't followup (and leave it to tool people). I think that mostly speaks to a not-great experience to the "I want to fix tools" story today, though.

I'd like T-compiler sign-off on this as the primary affected party, though I think FCP is overkill -- let's just see if anyone objects at/before the meeting. cc @rust-lang/compiler

JohnTitor

comment created time in 2 days

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha aa2e2e43be1496f9314352f8142cf07e8be58db0

Automatic stats update

view details

push time in 2 days

push eventrust-lang/thanks

Deploy from CI

commit sha af20d57c8200d128f3045a03ea0c26190501d99a

Deploy f6d7fe6f2abe92bf0695bcec69ccd6ba861067d7 to gh-pages

view details

push time in 2 days

issue commentrust-lang/rust

Occasional non-reproducibility when building rustc

Hm, perhaps. Though I'm not sure :) Certainly one would likely expect some way to get the arguments passed in a stage-specific way... I would need to look into it, and I don't have the bandwidth or energy right now unfortunately.

jgalenson

comment created time in 2 days

pull request commentrust-lang/rust

[beta] beta backports

@bors r+

Mark-Simulacrum

comment created time in 3 days

push eventMark-Simulacrum/rust

Mark Rousskov

commit sha e5532435d0aaf661f331431d0561c04f72b6ad27

Fix stderr for test

view details

push time in 3 days

pull request commentrust-lang/rust

[stable] 1.41.1 release

@bors r+

Gah, forgot to update the .rs file as well...

Mark-Simulacrum

comment created time in 3 days

push eventMark-Simulacrum/rust

Mark Rousskov

commit sha 53139c51c1122e7108033a2da08fe490a47c25cc

Correct stderr output for failing tests

view details

push time in 3 days

pull request commentrust-lang/rust

Deduplicate identifier printing a bit

@bors r+

Looks good, thanks for the clarifications!

petrochenkov

comment created time in 3 days

Pull request review commentrust-lang/rust

Deduplicate identifier printing a bit

 impl UseSpecializedDecodable for Ident {     } } +/// This is the most general way to print identifiers.+/// AST pretty-printer is used as a fallback for turning AST structures into token streams for+/// proc macros. Additionally, proc macros may stringify their input and expect it survive the+/// stringification (especially true for proc macro derives written between Rust 1.15 and 1.30).+/// So we need to somehow pretty-print `$crate` in a way preserving at least some of its+/// hygiene data, most importantly name of the crate it refers to.+/// As a result we print `$crate` as `crate` if it refers to the local crate+/// and as `::other_crate_name` if it refers to some other crate.+/// Note, that this is only done if the ident token is printed from inside of AST pretty-pringing,+/// but not otherwise. Pretty-printing is the only way for proc macros to discover token contents,+/// so we should not perform this lossy conversion if the top level call to the pretty-printer was+/// done for a token stream or a single token.+pub struct IdentPrinter {+    symbol: Symbol,+    is_raw: bool,+    convert_dollar_crate: Option<Span>,+}++impl IdentPrinter {+    pub fn new(symbol: Symbol, is_raw: bool, convert_dollar_crate: Option<Span>) -> IdentPrinter {

Makes sense. Could we document that (prefer the printing functions for ast/tokens)?

petrochenkov

comment created time in 3 days

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 123cd129ec07b641a3a9feb77e48339778b0ba10

Automatic stats update

view details

push time in 3 days

pull request commentrust-lang/rust

[stable] 1.41.1 release

@bors r+

Mark-Simulacrum

comment created time in 3 days

push eventMark-Simulacrum/rust

Mark Rousskov

commit sha a7629882db0827e8a8794901c934f7604c806a1d

Correct stderr output for failing tests

view details

push time in 3 days

pull request commentrust-lang/rust

[beta] beta backports

@bors r+

Mark-Simulacrum

comment created time in 3 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

It may be worth considering a non-hashing IndexMap or so for the map there, if that's the case, since there are so few crate nums generally -- as well as replacing the DefId in the vector with a DefIndex (presuming the associated CrateNum is enough. But that might also be a performance loss, it really depends.

@bors try @rust-timer queue

Aaron1011

comment created time in 3 days

issue openedrust-lang/triagebot

Spurious notification for commented pings

https://github.com/rust-lang/rust/issues/69392#issuecomment-590029971 for example should not have pinged the release team.

We should be able to reuse parser code to make this happen.

created time in 3 days

pull request commentrust-lang/rust

Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`

Cc @rust-lang/docs

I'm going to go ahead and approve this, because it feels like a clear win, though I think this is the first such use. Worst case we can always revert though as this isn't promising anything stable AFAICT.

@bors r+

memoryruins

comment created time in 3 days

push eventrust-lang/thanks

Deploy from CI

commit sha 46a7aa5fe19ec1ac508ed100c323907554cac2f4

Deploy f6d7fe6f2abe92bf0695bcec69ccd6ba861067d7 to gh-pages

view details

push time in 3 days

pull request commentrust-lang/rust

Relax str::get_unchecked precondition to permit empty slicing

Surely get_unchecked is invalid on an empty slice, with any index? (Possibly modulo ZSTs, but even there I'm not sure).

It was always my understanding that get_unchecked is UB exactly when get would return None; but this sort of implies that's not correct?

Could you provide an example where this would be fine?

ridiculousfish

comment created time in 4 days

Pull request review commentrust-lang/rust

x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy

 impl<'a> Builder<'a> {          // cfg(bootstrap): the flag was renamed from `-Zexternal-macro-backtrace`         // to `-Zmacro-backtrace`, keep only the latter after beta promotion.-        if stage == 0 {+        if stage == 0 && cmd != "clippy" {

Seems strange to gate this flag only on stage == 0, presumably it should be around the whole thing?

matthiaskrgr

comment created time in 4 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

@bors try @rust-timer queue

Aaron1011

comment created time in 4 days

Pull request review commentrust-lang/rust

Deduplicate identifier printing a bit

 impl UseSpecializedDecodable for Ident {     } } +/// This is the most general way to print identifiers.+/// AST pretty-printer is used as a fallback for turning AST structures into token streams for+/// proc macros. Additionally, proc macros may stringify their input and expect it survive the+/// stringification (especially true for proc macro derives written between Rust 1.15 and 1.30).+/// So we need to somehow pretty-print `$crate` in a way preserving at least some of its+/// hygiene data, most importantly name of the crate it refers to.+/// As a result we print `$crate` as `crate` if it refers to the local crate+/// and as `::other_crate_name` if it refers to some other crate.+/// Note, that this is only done if the ident token is printed from inside of AST pretty-pringing,+/// but not otherwise. Pretty-printing is the only way for proc macros to discover token contents,+/// so we should not perform this lossy conversion if the top level call to the pretty-printer was+/// done for a token stream or a single token.+pub struct IdentPrinter {+    symbol: Symbol,+    is_raw: bool,+    convert_dollar_crate: Option<Span>,

Could we get some documentation on the meaning of this? AFAICT, it's something like "hygiene information to pull the crate name from" if it's present, but at least a pointer to the Display impl here I think could be helpful.

petrochenkov

comment created time in 4 days

Pull request review commentrust-lang/rust

Deduplicate identifier printing a bit

 impl UseSpecializedDecodable for Ident {     } } +/// This is the most general way to print identifiers.+/// AST pretty-printer is used as a fallback for turning AST structures into token streams for+/// proc macros. Additionally, proc macros may stringify their input and expect it survive the+/// stringification (especially true for proc macro derives written between Rust 1.15 and 1.30).+/// So we need to somehow pretty-print `$crate` in a way preserving at least some of its+/// hygiene data, most importantly name of the crate it refers to.+/// As a result we print `$crate` as `crate` if it refers to the local crate+/// and as `::other_crate_name` if it refers to some other crate.+/// Note, that this is only done if the ident token is printed from inside of AST pretty-pringing,+/// but not otherwise. Pretty-printing is the only way for proc macros to discover token contents,+/// so we should not perform this lossy conversion if the top level call to the pretty-printer was+/// done for a token stream or a single token.+pub struct IdentPrinter {+    symbol: Symbol,+    is_raw: bool,+    convert_dollar_crate: Option<Span>,+}++impl IdentPrinter {+    pub fn new(symbol: Symbol, is_raw: bool, convert_dollar_crate: Option<Span>) -> IdentPrinter {

This basically appears to be for token_kind_to_string_ext only -- where does that get it's span from? I suspect that in practice almost everyone should not be calling this, but prefer from_ident instead. Could we either rename this to a less innocuous sounding name than new (perhaps "with_crate_span"?) or add a comment saying "prefer from_ident" here?

petrochenkov

comment created time in 4 days

Pull request review commentrust-lang/rust

Deduplicate identifier printing a bit

 mod a {}  macro_rules! m {     () => {-        use a::$crate; //~ ERROR unresolved import `a::$crate`+        use a::$crate; //~ ERROR unresolved import `a::crate`

I am a bit surprised to see this, though I didn't try to trace the calls to the new infrastructure. I think it's a correct change though strange (to me) that how we print paths differs from how we print the errors below, I guess. But ultimately seems good -- it's a more correct error AFAICT.

Out of interest, in a cross-crate use, does the expansion break down and expand to a::::crate_name here?

petrochenkov

comment created time in 4 days

issue openedrust-lang/triagebot

Missing notifications from new PR opening?

https://github.com/rust-lang/rust/pull/69387 did not seem to get into my notification queue. I suspect that either we're not listening on the appropriate webhook, or some other (similar) error caused this.

created time in 4 days

push eventMark-Simulacrum/rust

Mark Rousskov

commit sha a9b95b3515f800896b1b30bdabd08ed0659bc29f

Clean out some default-installed directories This helps us have enough disk space for our builders to be able to complete successfully. For now, the choices are ad-hoc and 'definitely not needed'. This should never fail the build, as everything our build needs should be inside Docker.

view details

push time in 4 days

pull request commentrust-lang/rust

Do not ping the infrastructure team on toolstate changes

@bors r=Dylan-DPC I guess, no need to wait for FCP I think. We can always revert, and I'm getting sufficiently annoyed at this filling up my triagebot notifications with noise :)

Mark-Simulacrum

comment created time in 4 days

issue commentrust-lang/rust

Occasional non-reproducibility when building rustc

If we do have to do this the hard way, maybe exposing cargo rustc via ./x.py rustc would be a good idea? It also would've come in handy when debugging bugs while compiling stage1 libcore (being able to add flags easily just to one crate's rustc's invocation).

This wold be pretty painful to do today I suspect do to how rustbuild works internally, and I haven't had the energy to try and investigate changes there for the past couple months.

jgalenson

comment created time in 4 days

pull request commentrust-lang/rust

[stable] 1.41.1 release

Cherry-picked https://github.com/rust-lang/rust/pull/69252 (and marked as stable-accepted). Also beta-nominated (and accepted) that PR, seems harmless and likely necessary on beta too (at least sometimes).

@bors r+ p=100

Hopefully this'll land now (I was hoping to get try artifacts, but now that I think of it "stable" artifacts will work just as well for crater).

Mark-Simulacrum

comment created time in 4 days

delete branch Mark-Simulacrum/rust

delete branch : disk-try

delete time in 4 days

push eventMark-Simulacrum/rust

Mark Rousskov

commit sha 6d4e588d042189300646ac40187ecd70504190c4

Clean out some default-installed directories This helps us have enough disk space for our builders to be able to complete successfully. For now, the choices are ad-hoc and 'definitely not needed'. This should never fail the build, as everything our build needs should be inside Docker.

view details

push time in 4 days

Pull request review commentrust-lang/rust

Allow getting `no_std` from the config file

 pub fn check(build: &mut Build) {          if target.contains("-none-") || target.contains("nvptx") {             if build.no_std(*target).is_none() {

This function looks potentially relevant; is there a reason it's not receiving updates or so?

Ericson2314

comment created time in 4 days

Pull request review commentrust-lang/rust

Allow getting `no_std` from the config file

 impl Config {                 target.musl_root = cfg.musl_root.clone().map(PathBuf::from);                 target.wasi_root = cfg.wasi_root.clone().map(PathBuf::from);                 target.qemu_rootfs = cfg.qemu_rootfs.clone().map(PathBuf::from);+                target.no_std =+                    cfg.no_std.unwrap_or(triple.contains("-none-") || triple.contains("nvptx"));

Hm, is -none- perhaps a bit too broad? I guess we presumably don't ship any platforms with that triple today that do have std compiled?

Ericson2314

comment created time in 4 days

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha 8b0d9c84d7e4dc98b16d5b454e6dfba4933e590b

Automatic stats update

view details

push time in 4 days

push eventrust-lang/rustc-timing

Mark Rousskov

commit sha 7adb2c2a5d4aac825c41ac5cc511891edc169580

recode to smaller data size

view details

push time in 4 days

pull request commentrust-lang/rust

[stable] 1.41.1 release

@bors try

Mark-Simulacrum

comment created time in 4 days

push eventMark-Simulacrum/rust

Esteban Küber

commit sha a978a9723ef6aeeef0acf707b7232eb1c4debfb6

Do not ICE when encountering `yield` inside `async` block

view details

Michael Burge

commit sha bb392dc052fa5598ac59b6a0b2ebbdfbc8df259d

Correct ICE caused by macros generating invalid spans.

view details

Kornel

commit sha 2427a4970dbd6a1acd6f4dc6a5b5b1fa3285b9e3

Demonstrate final build-override syntax

view details

Wesley Wiser

commit sha c5b841cee229d4d29307b4cb9c8bdc778f7190f0

Resolve long compile times when evaluating always valid constants This extends the existing logic which skips validating every integer or floating point number type to also skip validating empty structs because they are also trivially valid. Fixes #67539

view details

Matthew Jasper

commit sha 6195b6024577f4755403e079c5d076cfff8c898b

Check `Copy` lifetimes bounds when copying from a projection

view details

Matthew Jasper

commit sha 8f92102486d85e1247f72286a99f0e1bcd77e0dc

Check types of statics in MIR typeck

view details

push time in 4 days

IssuesEvent

issue commentrust-lang/rust

VecDeque has no `sort_by` method (should possibly have one to match Vec).

It seems like this should be possible, at least. A slightly non-optimal implementation would be to sort the front and back slices separately and then swap elements back and forth as needed (second step of merge sort, basically).

mitchmindtree

comment created time in 5 days

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha ecf460960ccb6a3cfca37edfd1c6cf17e78f87da

Automatic stats update

view details

push time in 5 days

more