profile
viewpoint

pnkfelix/boxdraw-rs 2

Library for drawing ASCII art rectangles

Manishearth/rust 1

a safe, concurrent, practical language

pnkfelix/BinFiles 1

Little scripts that my ConfigFiles and DotFiles sometimes reference. Meant to be alias of ~/bin/

pnkfelix/ack 0

A replacement for grep for programmers

pnkfelix/ack2 0

ack 2.0

pnkfelix/add3 0

A demo project for illustrating dependency handling in Cargo

pnkfelix/add6 0

Toy crate that depends on past version of add3 crate.

pnkfelix/agents 0

Agent based simulation

pnkfelix/alexa-rs 0

Rust library for building Alexa skills

issue commentrust-lang/rust

Increasingly slow compilation as more levels of `async` are added in Rust 1.46

We've seen a couple different links to repositories in the comment thread; I spent some time reducing the repo provided by @steadylearner and have gotten it down to this:

#![allow(unreachable_code)]

use actix_web::Route;
use actix_web::http::Method;
use actix_web::HttpResponse;

pub async fn cc_create() -> HttpResponse
{
    let _new_contact = create().await;
    HttpResponse::Ok().json("")
}

use mongodb::bson::doc;
use mongodb::{error::Error, results::InsertOneResult, Collection};

pub async fn create() -> Result<InsertOneResult, Error> {
    let _collection: Collection = loop { };
    let r = _collection.insert_one(doc! { "email": "", "name": "" }, None);
    Ok(r.await?)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let _post_to = Route::new().method(Method::POST).to(cc_create);
    Ok(())
}

My planned next step is to get rid of the dependencies on mongodb and actix_web (I just wanted to get the test case down to something small before doing so...)

nicholasbishop

comment created time in 3 days

issue openedrust-lang/rust

MatchBranchSimplication is unsound

Spawned off of PR #78151, which turned the mir-opt MatchBranchSimplification off by default.

I just want a dedicated issue for discussing the unsoundness identified there, and to track how resolve this bug in the mir-opt (and then maybe turn it back on again, if it can pay for its own cost, which it might not have done before...)

created time in 4 days

pull request commentrust-lang/rust

Implement rustc side of report-future-incompat

Okay, I think the approach given here makes sense to me.

But it needs unit tests in tests/ui; each lint that we revise to use this framework will want to add its own tests of the functionality. And that in turn, I think, will motivate the human readable output format that I alluded to above (this human readable format would be enabled via a -Z flag, and then the ui test will enable that flag.

Aaron1011

comment created time in 10 days

Pull request review commentrust-lang/rust

Implement rustc side of report-future-incompat

 impl Emitter for JsonEmitter {         }     } +    fn emit_future_breakage_report(&mut self, diags: Vec<(FutureBreakage, crate::Diagnostic)>) {+        let data: Vec<FutureBreakageItem> = diags+            .into_iter()+            .map(|(breakage, mut diag)| {+                if diag.level == crate::Level::Allow {+                    diag.level = crate::Level::Warning;+                }+                FutureBreakageItem {+                    future_breakage_date: breakage.date,+                    diagnostic: Diagnostic::from_errors_diagnostic(&diag, self),+                }+            })+            .collect();+        let result = if self.pretty {+            writeln!(&mut self.dst, "{}", as_pretty_json(&data))+        } else {+            writeln!(&mut self.dst, "{}", as_json(&data))+        }

should we consider a mode (not the default; presumably under a -Z flag) that emits the data in a human readable format?

Aaron1011

comment created time in 10 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Modify executable checking to be more universal

@bors r+ rollup

Mark-Simulacrum

comment created time in 10 days

Pull request review commentrust-lang/rust

Modify executable checking to be more universal

 use std::path::Path;  // All files are executable on Windows, so just check on Unix. #[cfg(windows)]-pub fn check(_path: &Path, _bad: &mut bool) {}+pub fn check(_path: &Path, _output: &Path, _bad: &mut bool) {}  #[cfg(unix)]-pub fn check(path: &Path, bad: &mut bool) {+pub fn check(path: &Path, output: &Path, bad: &mut bool) {     use std::fs;     use std::os::unix::prelude::*;     use std::process::{Command, Stdio}; -    if let Ok(contents) = fs::read_to_string("/proc/version") {-        // Probably on Windows Linux Subsystem or Docker via VirtualBox,-        // all files will be marked as executable, so skip checking.-        if contents.contains("Microsoft") || contents.contains("boot2docker") {-            return;+    fn is_executable(path: &Path) -> std::io::Result<bool> {+        Ok(path.metadata()?.mode() & 0o111 != 0)

Actually, I guess given the single context where this is called, namely a check if the filesystem is magically treating fresh created files as executable, the OR of all the triads does make sense to me.

(I might rename the method to is_any_triad_executable, though, to make that clear.)

Mark-Simulacrum

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Modify executable checking to be more universal

 use std::path::Path;  // All files are executable on Windows, so just check on Unix. #[cfg(windows)]-pub fn check(_path: &Path, _bad: &mut bool) {}+pub fn check(_path: &Path, _output: &Path, _bad: &mut bool) {}  #[cfg(unix)]-pub fn check(path: &Path, bad: &mut bool) {+pub fn check(path: &Path, output: &Path, bad: &mut bool) {     use std::fs;     use std::os::unix::prelude::*;     use std::process::{Command, Stdio}; -    if let Ok(contents) = fs::read_to_string("/proc/version") {-        // Probably on Windows Linux Subsystem or Docker via VirtualBox,-        // all files will be marked as executable, so skip checking.-        if contents.contains("Microsoft") || contents.contains("boot2docker") {-            return;+    fn is_executable(path: &Path) -> std::io::Result<bool> {+        Ok(path.metadata()?.mode() & 0o111 != 0)

So my only misgiving here is that when I first read this, I spent a while wondering about why its looking at the group and others bits at all, and about what scenarios could arise here. (Does owner alone not suffice? Is there any scenario where we could get an exec-bit set for group and/or others, and not owner, and yet we would still expect things to continue to work? Because the logic as written here seems to imply that interpretation of matters...)

I don't really know the best way to fix this, or if it really is something to fix at all. I figure the code as written is probably just playing it safe (no one ever got fired for taking the OR of all three triads, right?). But I would be curious if there is actually a scenario that its anticipating, and if so, maybe a comment here is warranted.

Mark-Simulacrum

comment created time in 10 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Implement rustc side of report-future-incompat

@Aaron1011 my personal preference would be for this to be broken into more commits; e.g. the initial factoring of rustc_lint_defs into its own crate, without adding any new functionality (such as variants to enums it defines), could be a separate commit.

My main motivation for splitting it up into commits like that is that its easier to distinguish the pure refactorings from the commits that actually add functionality and/or change behavior, which in turn allows my brain to focus on different kinds of bugs to look for.

But I will still take a look at it as-is, since its not an enormous revision and so I can hopefully still provide useful feedback on the approach as written.

Aaron1011

comment created time in 10 days

pull request commentrust-lang/blog.rust-lang.org

Fix url typo

(but, r+)

spastorino

comment created time in 11 days

pull request commentrust-lang/blog.rust-lang.org

Fix url typo

(FYI I'm not in core)

spastorino

comment created time in 11 days

issue commentrust-lang/compiler-team

inherit stable annotations in enum variants and field items

Discussed at T-compiler meeting; we're going to put this through a full FCP process rather than the MCP seconding process.

@rfcbot fcp merge

nikomatsakis

comment created time in 11 days

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous on nightly but not beta

self-assigning as reminder to do prep to describe issue at next T-lang meeting.

jmesmon

comment created time in 18 days

issue commentrust-lang/rust

`use dep1::foo as dep1` is considered ambiguous on nightly but not beta

Discussed at T-compiler meeting.

nominating for discussion at T-lang meeting.

jmesmon

comment created time in 18 days

issue commentrust-lang/rust

unexpected panic whilst using base64!() macro from binary_macros crate

discussed at wg-incr-comp meeting.

closing since this doesn't ICE any more.

If you encounter it again, please re-open (hopefully with info about the pre- and post-states of your code base so that the wg-incr-comp team can quickly identify what incremental change to the source code was causing this to arise.)

asib

comment created time in 20 days

issue closedrust-lang/rust

unexpected panic whilst using base64!() macro from binary_macros crate

Sorry if this isn't very descriptive, I've got no clue why this happened.

thread 'main' panicked at 'index out of bounds: the len is 10 but the index is 10', /Users/travis/build/rust-lang/rust/src/libcore/slice/mod.rs:2085:10

I tried this code:

#[macro_use] extern crate binary_macros;

const KEY: [u8] = base64!("MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAk8Jku/4H1aQCxO9/JleaGWGeGafdqkF0cHt6dvHOGopvuZXMBITZMHth5Mg7sp6lqbD298+4B3iMKC9b0nNTAiZxu+fPiLpMDb7MEUAe2L213lurcekv5/L53EZnrRxkQ+UwYyPPTKPqZYziMvOshKoJ9yjcQNFmR0JeWFoot2Vyhk/1l2kEpJE0/DRyew20UIecOTt7uLI2V8mpM18kYMtC1StmFwy61fZimdYO1lN8iI8GuTMYrkkLV1CxQ8Jn/68VHcZaipOCYznVMRKfyXThcghOM1cg2HrVeZvdLilntN/0UtEjbpO3lgwwfWzfww5m/YInz0fLJSFhvWwl0qJV31/P7U+MIbIf+O3unTy7EUcHOTJY8gUptDgdYdVbo4V5vdtx51gxe1qIRJ4Ug7G943JE1wO86idFwzJEYBFClhliaqQ7hHO8spHPaqYsphnbWynDQmSf0WYBdgN55siLWyc5HC8K4++aSN7aqfNIuYbgf6RJzTq35l/HfY6/IwFw/+bx5iJ9sgJxA8uAfncTwnbfUlf5SpT6uKalNnACP9gD1hTTgz6/ANZfBrkBSgOMBTj/8zlmIzQExYr1sCeW0pZHjwoqGFA/wCaXLOjl41IrcECdWXNlbtBj1gICr3Hvu7rqVT5wN65G3wV8dk+dcdHMfxu012o4ENN1Kj0CAwEAAQ==");

I expected to see this happen: I was just trying to run some tests, and needed to load this key in, so expected tests to run.

Instead, this happened: I got the unexpected panic, along with the following output:

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.29.1 (b801ae664 2018-09-20) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental

note: some of the compiler flags provided by cargo are hidden

Meta

rustc --version --verbose:

rustc 1.29.1 (b801ae664 2018-09-20)
binary: rustc
commit-hash: b801ae66425cf7c3c71052b19ef8f145b0d0513d
commit-date: 2018-09-20
host: x86_64-apple-darwin
release: 1.29.1
LLVM version: 7.0

Backtrace:

thread 'main' panicked at 'index out of bounds: the len is 10 but the index is 10', /Users/travis/build/rust-lang/rust/src/libcore/slice/mod.rs:2085:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic_bounds_check
  10: rustc_metadata::cstore_impl::<impl rustc::middle::cstore::CrateStore for rustc_metadata::cstore::CStore>::def_path_hash
  11: <[T] as rustc_data_structures::stable_hasher::HashStable<CTX>>::hash_stable
  12: rustc::dep_graph::graph::DepGraph::with_task_impl
  13: rustc::ty::context::tls::with_related_context
  14: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  15: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  16: rustc_typeck::check::method::suggest::compute_all_traits::handle_external_def
  17: core::ops::function::FnOnce::call_once
  18: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::all_traits<'tcx>>::compute
  19: rustc::ty::context::tls::with_context
  20: rustc::dep_graph::graph::DepGraph::with_task_impl
  21: rustc::ty::context::tls::with_related_context
  22: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  23: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  24: rustc_typeck::check::method::suggest::all_traits
  25: rustc_typeck::check::method::probe::ProbeContext::assemble_extension_candidates_for_all_traits
  26: rustc::infer::InferCtxt::probe
  27: rustc_typeck::check::FnCtxt::suggest_ref_or_into
  28: rustc_typeck::check::FnCtxt::suggest_mismatched_types_on_tail
  29: <rustc_typeck::check::coercion::CoerceMany<'gcx, 'tcx, 'exprs, E>>::coerce_inner
  30: rustc_typeck::check::FnCtxt::check_block_with_expected
  31: rustc_typeck::check::FnCtxt::check_expr_kind
  32: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  33: rustc_typeck::check::FnCtxt::check_block_with_expected
  34: rustc_typeck::check::FnCtxt::check_expr_kind
  35: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  36: rustc::ty::context::tls::with_related_context
  37: rustc::infer::InferCtxtBuilder::enter
  38: rustc_typeck::check::typeck_tables_of
  39: rustc::ty::query::__query_compute::typeck_tables_of
  40: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  41: rustc::ty::context::tls::with_context
  42: rustc::dep_graph::graph::DepGraph::with_task_impl
  43: rustc::ty::context::tls::with_related_context
  44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  45: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  46: rustc::ty::query::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::typeck_tables_of
  47: rustc_typeck::check::check_item_type
  48: rustc::hir::Crate::visit_all_item_likes
  49: rustc_typeck::check::check_item_types
  50: rustc::util::common::time
  51: rustc_typeck::check_crate
  52: rustc::ty::context::tls::enter_context
  53: <std::thread::local::LocalKey<T>>::with
  54: rustc::ty::context::TyCtxt::create_and_enter
  55: rustc_driver::driver::compile_input
  56: rustc_driver::run_compiler_with_pool
  57: <scoped_tls::ScopedKey<T>>::set
  58: <scoped_tls::ScopedKey<T>>::set
  59: syntax::with_globals
  60: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  61: __rust_maybe_catch_panic
  62: rustc_driver::run
  63: rustc_driver::main
  64: std::rt::lang_start::{{closure}}
  65: std::panicking::try::do_call
  66: __rust_maybe_catch_panic
  67: std::rt::lang_start_internal
  68: main
query stack during panic:

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

closed time in 20 days

asib

issue closedrust-lang/rust

Incremental compiliation is ineffective when building compiler

Rebuilding the compiler took 15 minutes after simply running touch on a file. Given that nothing has actually changed, I would expect that rebuilding would be much faster.

Steps to reproduce:

  1. Clone the rust repository.
  2. Set incremental = true in the rust section of config.toml.
  3. Run ./x.py clean if you've previously built the compiler
  4. Run ./x.py build
  5. Run touch src/librustc/traits/auto_trait.rs
  6. Run ./x.py build again.

The second ./x.py build invocation takes much longer than it should (~15 minutes on my machine), considering that the only thing that's changed is a file timestamp.

closed time in 20 days

Aaron1011

issue commentrust-lang/rust

Incremental compiliation is ineffective when building compiler

discussed at wg-incr-comp meeting.

We think that the issue as described here is probably largely an artifact of the build process discussed above is building all the way to stage 2, which A. imposes work that is hard to avoid (at least automatically), and B. is no longer the default in x.py for rustc development, and thus should not be affecting most rustc developers.

closing as (presumed) "fixed" or at least "not a bug for wg-incr-comp"...

Aaron1011

comment created time in 20 days

issue commentrust-lang/rust

Hard-linking incremental files can be expensive.

One idea also posed by @wesleywiser : we could consider switching from leaning on FS features like linking, and instead use e.g. a text file storing the linking info. The latter might be much faster.

ehuss

comment created time in 20 days

issue commentrust-lang/rust

Hard-linking incremental files can be expensive.

(@wesleywiser notes that this might also be a big issue on windows, since we probably aren't using junction points there, and thus we may be copying files back and forth there, which would be ... bad with respect to time and space usage...)

ehuss

comment created time in 20 days

issue closedrust-lang/rust

error: unused attribute const_fn_union with incr-comp

Every time I try to recompile the compiler using incremental compilation with ./x.py build -i --stage 1 --keep-stage 1 src/libstd I get the following error ...

error: unused attribute                                                                                                
  --> src/libcore/slice/mod.rs:66:5                                                                                    
   |                                                                                                                   
66 |     #[allow_internal_unstable(const_fn_union)]                                                                    
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                                                 
   = note: `-D unused-attributes` implied by `-D warnings`
                                                                                                                       
error: unused attribute                                                                                                
    --> src/libcore/str/mod.rs:2170:5                      
     |                                                                                                                 
2170 |     #[allow_internal_unstable(const_fn_union)]                                                                  
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                  
                                                                                                                       
error: aborting due to 2 previous errors                                                                               
                                                                                                                                                                                                                                              
error: could not compile `core`.                   

closed time in 20 days

spastorino

issue commentrust-lang/rust

error: unused attribute const_fn_union with incr-comp

closing as "worked-around", (we think this really only affects people working on rustc development itself).

((there are some notes about fixme's mentioned in linked prs but I'm not going to try to address those right now.))

spastorino

comment created time in 20 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

My current assumption is that LLVM is peforming some incorrect optimization of the SPIRV-Tools library.

At least, I cannot find any reason that the code linked by @ehuss above would be allowed to have to_string return an empty string.

danieldeankon

comment created time in 25 days

pull request commentrust-lang/rust

Switch `mutable_borrow_reservation_conflict` lint to deny by default

nominating for discussion at T-lang meeting, so that we can ponder when/if we are going to have time to do the follow-on work of evaluating semantic models et cetera that was promised here.

marmeladema

comment created time in 25 days

pull request commentrust-lang/rust

Switch `mutable_borrow_reservation_conflict` lint to deny by default

(However, I'm also not sure whether turning this lint to deny-by-default needs to be coupled to turning on feature(nll) by default? maybe I misremember, but I had thought this lint was largely independent of all the other stuff turned on by feature(nll)...)

marmeladema

comment created time in 25 days

pull request commentrust-lang/rust

Switch `mutable_borrow_reservation_conflict` lint to deny by default

The lang team had agreed (described here) that we need to do a more thorough evaluation of the semantic models before we convert this to a hard error.

I think several members of the lang team would be annoyed if we turned this into a hard error simply because "its been a warning for so long." We reached the compromise that we adopted in part because we promised we would not do that.

marmeladema

comment created time in 25 days

pull request commentrust-lang/rust

Add `-Zprecise-enum-drop-elaboration`

@bors r+ rollup

ecstatic-morse

comment created time in 25 days

issue commentrust-lang/rust

Linker error with wasm target with spaces in install path

Hurm. My local windows virtual box ran x.py dist with lld = true in the config.toml, and the resulting set up ... does not exhibit the problem. :cry:

I haven't dug deeply into why it doesn't reproduce the problem, beyond checking the recent git log info for llvm and for rust to see if anyone secretly fixed this.

My main point in reporting this here is to say that I am not confident I'll be able to fix the bug if I cannot reproduce it via a local build.

jminer

comment created time in 25 days

issue commentrust-lang/rust

Linker error with wasm target with spaces in install path

(yes, it affects beta, and basically breaks LDD usage on windows, which means it breaks wasm32-unknown-unknown targets on Windows.)

Upgrading priority to P-critical to reflect importance of addressing this.

(Luckily @eddyb has already outlined some reasonable solutions, as discussed above.)

jminer

comment created time in 25 days

issue commentrust-lang/rust

Linker error with wasm target with spaces in install path

assigning self to figure out if this is also a stable-to-beta regression, and if so, identify a beta-backportable fix.

jminer

comment created time in 25 days

issue commentmozilla/rr

Ryzen 3900X test failures

So this confirms that my problem is a duplicate of issue #2694, since __getgrnam_r appears in the backtrace, right?

Manishearth

comment created time in a month

issue commentmozilla/rr

Ryzen 3900X test failures

Backtrace:

% ./bin/rr replay /tmp/rr-test-setuid-TgOCW9j3p/latest-trace/
On Zen CPUs, rr will not work reliably unless you disable the hardware SpecLockMap optimization.
For instructions on how to do this, see https://github.com/mozilla/rr/wiki/Zen
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/rr-test-setuid-TgOCW9j3p/setuid-TgOCW9j3p-0/mmap_pack_5_setuid-TgOCW9j3p...
Really redefine built-in command "restart"? (y or n) [answered Y; input not from terminal]
Remote debugging using 127.0.0.1:50382
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f534470d100 in ?? () from /lib64/ld-linux-x86-64.so.2
(rr) hbreak *0x7f534449603f
Hardware assisted breakpoint 1 at 0x7f534449603f
(rr) continue
Continuing.

Breakpoint 1, 0x00007f534449603f in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
(rr) bt
#0  0x00007f534449603f in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#1  0x00007f5344496273 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#2  0x00007f5344496541 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#3  0x00007f5344484b11 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#4  0x00007f534448ab1e in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#5  0x00007f534448b251 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#6  0x00007f5344498981 in _nss_systemd_getgrnam_r () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
#7  0x00007f53445a967d in __getgrnam_r (name=name@entry=0x55a992626030 "nobody", 
    resbuf=resbuf@entry=0x7f53446b5020 <resbuf>, buffer=0x55a993c23fc0 "", buflen=buflen@entry=1024, 
    result=result@entry=0x7fff06e2c640) at ../nss/getXXbyYY_r.c:315
#8  0x00007f53445a892c in getgrnam (name=0x55a992626030 "nobody") at ../nss/getXXbyYY.c:134
#9  0x000055a99262557e in main (argc=1, argv=0x7fff06e2c7d8)
    at /home/pnkfelix/Dev/Mozilla/rr.git/src/test/setuid.c:15
(rr) 
Manishearth

comment created time in a month

issue commentmozilla/rr

Ryzen 3900X test failures

Okay this tar ball has the packed version of the directory.

rr-test-setuid.tar.gz

Manishearth

comment created time in a month

issue commentmozilla/rr

Ryzen 3900X test failures

Oh, I'm sorry, you asked me to pack it, and I didn't realized that meant run rr pack on it as described in #2694. I'll do that now.

Manishearth

comment created time in a month

issue commentmozilla/rr

Ryzen 3900X test failures

I assume the trace you want packed is the one in the same /tmp/rr-test-setuid-XXX directory; I've put a tarball of that whole directory below.

rr-test-setuid.tar.gz

Manishearth

comment created time in a month

issue commentmozilla/rr

Ryzen 3900X test failures

On my end, with a 3990X, the setuid-no-syscallbuf test is failing (and that's the main one that I think I've seen fail with some repeated runs, though sometimes it doesn't fail), and the record.err says this:

[ERROR /home/pnkfelix/Dev/Mozilla/rr.git/src/Registers.cc:295:maybe_print_reg_mismatch()] r10 0x55a993c2e95a != 0x55a993c2e958 (replaying vs. recorded)
process 317197 sent SIGURG

<details> <summary>For full log, click here</summary>

% cat /tmp/rr-test-setuid-TgOCW9j3p/replay.err 
[ERROR /home/pnkfelix/Dev/Mozilla/rr.git/src/Registers.cc:295:maybe_print_reg_mismatch()] r10 0x55a993c2e95a != 0x55a993c2e958 (replaying vs. recorded)
process 317197 sent SIGURG
====== /proc/317197/status
Name:	rr
Umask:	0002
State:	S (sleeping)
Tgid:	317197
Ngid:	0
Pid:	317197
PPid:	317196
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	64
Groups:	4 27 1000 
NStgid:	317197
NSpid:	317197
NSpgid:	317197
NSsid:	4178
VmPeak:	   16508 kB
VmSize:	   15468 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	   10088 kB
VmRSS:	    9680 kB
RssAnon:	    1116 kB
RssFile:	    8564 kB
RssShmem:	       0 kB
VmData:	    1156 kB
VmStk:	     136 kB
VmExe:	    5728 kB
VmLib:	    1320 kB
VmPTE:	      68 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
THP_enabled:	1
Threads:	1
SigQ:	1/1030150
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	0000000180002000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	0
Speculation_Store_Bypass:	thread vulnerable
Cpus_allowed:	00000100,00000000,00000000,00000000
Cpus_allowed_list:	104
Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	2
nonvoluntary_ctxt_switches:	335
====== /proc/317197/stack
====== /proc/317198/status
Name:	rr:setuid-TgOCW
Umask:	0002
State:	t (tracing stop)
Tgid:	317198
Ngid:	0
Pid:	317198
PPid:	317197
TracerPid:	317197
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	1024
Groups:	4 27 1000 
NStgid:	317198
NSpid:	317198
NSpgid:	317198
NSsid:	317198
VmPeak:	    5212 kB
VmSize:	    5088 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	    2184 kB
VmRSS:	    2184 kB
RssAnon:	     380 kB
RssFile:	    1804 kB
RssShmem:	       0 kB
VmData:	    2460 kB
VmStk:	       0 kB
VmExe:	       8 kB
VmLib:	    1920 kB
VmPTE:	      56 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
THP_enabled:	1
Threads:	1
SigQ:	1/1030150
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000010000
SigCgt:	0000000000000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
NoNewPrivs:	1
Seccomp:	0
Speculation_Store_Bypass:	thread vulnerable
Cpus_allowed:	00000100,00000000,00000000,00000000
Cpus_allowed_list:	104
Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	332
nonvoluntary_ctxt_switches:	0
====== /proc/317198/stack
====== gdb -p 317197 -ex 'set confirm off' -ex 'set height 0' -ex 'thread apply all bt' -ex q </dev/null 2>&1
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 317197
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.

</details>

Manishearth

comment created time in a month

issue commentrust-lang/rust

Linker error with wasm target with spaces in install path

We did a bit of a deeper dive than expected into this bug during this week's T-compiler planning meeting.

The relevant portion of the log starts at around here

Investigation is ongoing

jminer

comment created time in a month

Pull request review commentrust-lang/rust

[mir-opt] Disable the `ConsideredEqual` logic in SimplifyBranchSame opt

 impl<'a, 'tcx> SimplifyBranchSameOptimizationFinder<'a, 'tcx> {              match rhs {                 Rvalue::Use(operand) if operand.place() == Some(adt_matched_on) => {-                    StatementEquality::ConsideredEqual(side_to_choose)+                    // FIXME(76803): This logic is currently broken because it does not take into+                    // account the current discriminant value.+                    if mir_opt_level > 2 {

To be clear, this is the PR that @wesleywiser is referring to: https://github.com/rust-lang/rust/pull/76899

wesleywiser

comment created time in a month

PullRequestReviewEvent

issue commentrust-lang/compiler-team

Uplift `drop-bounds` lint from clippy into rustc

@rustbot second

notriddle

comment created time in a month

issue commentrust-lang/wg-incr-comp

Project: Better bug reports for incremental issues

Example taken from recent zulip discussion: We should make it easier for people to archive their incremental state and send it to us. Telling them to archive their entire build/ directory is not non-optimal since those can be quite large (e.g. 39 GB in the discussion linked above)

wesleywiser

comment created time in a month

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

@rfcbot fcp merge

petrochenkov

comment created time in 2 months

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

@rfcbot rfc merge

petrochenkov

comment created time in 2 months

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

@rustbot fcp merge

petrochenkov

comment created time in 2 months

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

@rustbot fcp cancel

petrochenkov

comment created time in 2 months

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

I just re-read the protocol and realized that this requires full team check off.

petrochenkov

comment created time in 2 months

issue commentrust-lang/compiler-team

Accept RFC 2951 "Linking modifiers for native libraries"

@rustbot second

petrochenkov

comment created time in 2 months

pull request commentrust-lang/rust

build aarch64-musl host compiler in CI

This was discussed today as part of the compiler weekly meeting

More specifically, I think the T-compiler team was generally in favor of landing this.

So I'm removing S-waiting-on-team.

(One thing I do not know is whether T-infra has discussed this. Cc @rust-lang/infra )

alex

comment created time in 2 months

pull request commentrust-lang/rust

Don't run tidy exec check on WSL2

and there was further followup discussion today, here

The conclusion from yesterday had been "maybe we should revise things so that this check runs solely on CI, because the existing logic (with or without the change proposed here) isn't really doing the right thing -- you want to know properties of the file system, not of the host OS)."

But then today we rethought things more. maybe we'll still disable the check outside of CI, or maybe we'll come up with a more robust form of the check. See the discussion linked above.

I'm leaving this PR open for now, because if we do leave this logic in, then we should probably apply this amendment to it. But it would be better to figure out a way to revise the logic or remove it.

carbotaniuman

comment created time in 2 months

issue commentrust-lang/rust

Type mismatch in function arguments E0631, E0271 are falsely recognized as E0308 mismatched types

Discussed in T-compiler meeting. Seems related to (or potential duplicate of) #75791 ?

vandenheuvel

comment created time in 2 months

issue commentrust-lang/rust

diagnostics: "one type is more general" for two identical types?

discussed in T-compiler meeting. Assigning to @estebank to see if they can make progress on it over next week. Also nominating to ensure we circle back around to it next week if progress isn't made

matthiaskrgr

comment created time in 2 months

issue openedrust-lang/rust

Why didnt our test suite catch lldb breakage?

I am posting this issue mostly as a reminder that we should investigate why our current test suite didn't seem to catch the breakage from #76006 on any of our CI platforms

created time in 2 months

pull request commentrust-lang/rust

Promote aarch64-pc-windows-msvc to Tier 2 Development Platform

@pnkfelix hmm, that's on ARMv7 instead of AArch64.

Hmm okay good point

arlosi

comment created time in 2 months

issue commentrust-lang/rust

Tracking issue for supporting macOS on Apple Silicon (ARM)

I'm throwing a link to https://github.com/rust-lang/rust/issues/74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

shepmaster

comment created time in 2 months

pull request commentrust-lang/rust

Add aarch64-pc-windows-msvc to CI

I'm throwing a link to https://github.com/rust-lang/rust/issues/74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

arlosi

comment created time in 2 months

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

I'm throwing a link to https://github.com/rust-lang/rust/issues/74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

 fn default_visibility(tcx: TyCtxt<'_>, id: DefId, is_generic: bool) -> Visibilit     } } -fn merge_codegen_units<'tcx>(-    tcx: TyCtxt<'tcx>,-    initial_partitioning: &mut PreInliningPartitioning<'tcx>,-    target_cgu_count: usize,-) {-    assert!(target_cgu_count >= 1);-    let codegen_units = &mut initial_partitioning.codegen_units;--    // Note that at this point in time the `codegen_units` here may not be in a-    // deterministic order (but we know they're deterministically the same set).-    // We want this merging to produce a deterministic ordering of codegen units-    // from the input.-    //-    // Due to basically how we've implemented the merging below (merge the two-    // smallest into each other) we're sure to start off with a deterministic-    // order (sorted by name). This'll mean that if two cgus have the same size-    // the stable sort below will keep everything nice and deterministic.-    codegen_units.sort_by_cached_key(|cgu| cgu.name().as_str());--    // This map keeps track of what got merged into what.-    let mut cgu_contents: FxHashMap<Symbol, Vec<SymbolStr>> =-        codegen_units.iter().map(|cgu| (cgu.name(), vec![cgu.name().as_str()])).collect();--    // Merge the two smallest codegen units until the target size is reached.-    while codegen_units.len() > target_cgu_count {-        // Sort small cgus to the back-        codegen_units.sort_by_cached_key(|cgu| cmp::Reverse(cgu.size_estimate()));-        let mut smallest = codegen_units.pop().unwrap();-        let second_smallest = codegen_units.last_mut().unwrap();--        // Move the mono-items from `smallest` to `second_smallest`-        second_smallest.modify_size_estimate(smallest.size_estimate());-        for (k, v) in smallest.items_mut().drain() {-            second_smallest.items_mut().insert(k, v);-        }+impl<'tcx> Partitioner<'tcx> for DefaultPartitioning {+    fn place_root_mono_items(+        &mut self,+        tcx: TyCtxt<'tcx>,+        mono_items: &mut dyn Iterator<Item = MonoItem<'tcx>>,+    ) -> PreInliningPartitioning<'tcx> {+        let mut roots = FxHashSet::default();+        let mut codegen_units = FxHashMap::default();+        let is_incremental_build = tcx.sess.opts.incremental.is_some();+        let mut internalization_candidates = FxHashSet::default();++        // Determine if monomorphizations instantiated in this crate will be made+        // available to downstream crates. This depends on whether we are in+        // share-generics mode and whether the current crate can even have+        // downstream crates.+        let export_generics = tcx.sess.opts.share_generics() && tcx.local_crate_exports_generics();++        let cgu_name_builder = &mut CodegenUnitNameBuilder::new(tcx);+        let cgu_name_cache = &mut FxHashMap::default();++        for mono_item in mono_items {+            match mono_item.instantiation_mode(tcx) {+                InstantiationMode::GloballyShared { .. } => {}+                InstantiationMode::LocalCopy => continue,+            } -        // Record that `second_smallest` now contains all the stuff that was in-        // `smallest` before.-        let mut consumed_cgu_names = cgu_contents.remove(&smallest.name()).unwrap();-        cgu_contents.get_mut(&second_smallest.name()).unwrap().extend(consumed_cgu_names.drain(..));+            let characteristic_def_id = characteristic_def_id_of_mono_item(tcx, mono_item);+            let is_volatile = is_incremental_build && mono_item.is_generic_fn(); -        debug!(-            "CodegenUnit {} merged into CodegenUnit {}",-            smallest.name(),-            second_smallest.name()-        );-    }+            let codegen_unit_name = match characteristic_def_id {+                Some(def_id) => compute_codegen_unit_name(+                    tcx,+                    cgu_name_builder,+                    def_id,+                    is_volatile,+                    cgu_name_cache,+                ),+                None => fallback_cgu_name(cgu_name_builder),+            }; -    let cgu_name_builder = &mut CodegenUnitNameBuilder::new(tcx);--    if tcx.sess.opts.incremental.is_some() {-        // If we are doing incremental compilation, we want CGU names to-        // reflect the path of the source level module they correspond to.-        // For CGUs that contain the code of multiple modules because of the-        // merging done above, we use a concatenation of the names of-        // all contained CGUs.-        let new_cgu_names: FxHashMap<Symbol, String> = cgu_contents-            .into_iter()-            // This `filter` makes sure we only update the name of CGUs that-            // were actually modified by merging.-            .filter(|(_, cgu_contents)| cgu_contents.len() > 1)-            .map(|(current_cgu_name, cgu_contents)| {-                let mut cgu_contents: Vec<&str> = cgu_contents.iter().map(|s| &s[..]).collect();--                // Sort the names, so things are deterministic and easy to-                // predict.-                cgu_contents.sort();--                (current_cgu_name, cgu_contents.join("--"))-            })-            .collect();+            let codegen_unit = codegen_units+                .entry(codegen_unit_name)+                .or_insert_with(|| CodegenUnit::new(codegen_unit_name)); -        for cgu in codegen_units.iter_mut() {-            if let Some(new_cgu_name) = new_cgu_names.get(&cgu.name()) {-                if tcx.sess.opts.debugging_opts.human_readable_cgu_names {-                    cgu.set_name(Symbol::intern(&new_cgu_name));-                } else {-                    // If we don't require CGU names to be human-readable, we-                    // use a fixed length hash of the composite CGU name-                    // instead.-                    let new_cgu_name = CodegenUnit::mangle_name(&new_cgu_name);-                    cgu.set_name(Symbol::intern(&new_cgu_name));-                }+            let mut can_be_internalized = true;+            let (linkage, visibility) = mono_item_linkage_and_visibility(+                tcx,+                &mono_item,+                &mut can_be_internalized,+                export_generics,+            );+            if visibility == Visibility::Hidden && can_be_internalized {+                internalization_candidates.insert(mono_item);             }++            codegen_unit.items_mut().insert(mono_item, (linkage, visibility));+            roots.insert(mono_item);         }-    } else {-        // If we are compiling non-incrementally we just generate simple CGU-        // names containing an index.-        for (index, cgu) in codegen_units.iter_mut().enumerate() {-            cgu.set_name(numbered_codegen_unit_name(cgu_name_builder, index));++        // Always ensure we have at least one CGU; otherwise, if we have a+        // crate with just types (for example), we could wind up with no CGU.+        if codegen_units.is_empty() {+            let codegen_unit_name = fallback_cgu_name(cgu_name_builder);+            codegen_units.insert(codegen_unit_name, CodegenUnit::new(codegen_unit_name));         }-    }-} -fn place_inlined_mono_items<'tcx>(-    initial_partitioning: PreInliningPartitioning<'tcx>,-    inlining_map: &InliningMap<'tcx>,-) -> PostInliningPartitioning<'tcx> {-    let mut new_partitioning = Vec::new();-    let mut mono_item_placements = FxHashMap::default();+        PreInliningPartitioning {+            codegen_units: codegen_units+                .into_iter()+                .map(|(_, codegen_unit)| codegen_unit)+                .collect(),+            roots,+            internalization_candidates,+        }+    } -    let PreInliningPartitioning { codegen_units: initial_cgus, roots, internalization_candidates } =-        initial_partitioning;+    fn merge_codegen_units(+        &mut self,+        tcx: TyCtxt<'tcx>,+        initial_partitioning: &mut PreInliningPartitioning<'tcx>,+        target_cgu_count: usize,+    ) {+        assert!(target_cgu_count >= 1);+        let codegen_units = &mut initial_partitioning.codegen_units; -    let single_codegen_unit = initial_cgus.len() == 1;+        // Note that at this point in time the `codegen_units` here may not be in a+        // deterministic order (but we know they're deterministically the same set).+        // We want this merging to produce a deterministic ordering of codegen units+        // from the input.+        //+        // Due to basically how we've implemented the merging below (merge the two+        // smallest into each other) we're sure to start off with a deterministic+        // order (sorted by name). This'll mean that if two cgus have the same size+        // the stable sort below will keep everything nice and deterministic.+        codegen_units.sort_by_cached_key(|cgu| cgu.name().as_str());++        // This map keeps track of what got merged into what.+        let mut cgu_contents: FxHashMap<Symbol, Vec<SymbolStr>> =+            codegen_units.iter().map(|cgu| (cgu.name(), vec![cgu.name().as_str()])).collect();++        // Merge the two smallest codegen units until the target size is reached.+        while codegen_units.len() > target_cgu_count {+            // Sort small cgus to the back+            codegen_units.sort_by_cached_key(|cgu| cmp::Reverse(cgu.size_estimate()));+            let mut smallest = codegen_units.pop().unwrap();+            let second_smallest = codegen_units.last_mut().unwrap();++            // Move the mono-items from `smallest` to `second_smallest`+            second_smallest.modify_size_estimate(smallest.size_estimate());+            for (k, v) in smallest.items_mut().drain() {+                second_smallest.items_mut().insert(k, v);+            } -    for old_codegen_unit in initial_cgus {-        // Collect all items that need to be available in this codegen unit.-        let mut reachable = FxHashSet::default();-        for root in old_codegen_unit.items().keys() {-            follow_inlining(*root, inlining_map, &mut reachable);+            // Record that `second_smallest` now contains all the stuff that was in+            // `smallest` before.+            let mut consumed_cgu_names = cgu_contents.remove(&smallest.name()).unwrap();+            cgu_contents+                .get_mut(&second_smallest.name())+                .unwrap()+                .extend(consumed_cgu_names.drain(..));++            debug!(+                "CodegenUnit {} merged into CodegenUnit {}",+                smallest.name(),+                second_smallest.name()+            );         } -        let mut new_codegen_unit = CodegenUnit::new(old_codegen_unit.name());--        // Add all monomorphizations that are not already there.-        for mono_item in reachable {-            if let Some(linkage) = old_codegen_unit.items().get(&mono_item) {-                // This is a root, just copy it over.-                new_codegen_unit.items_mut().insert(mono_item, *linkage);-            } else {-                if roots.contains(&mono_item) {-                    bug!(-                        "GloballyShared mono-item inlined into other CGU: \-                          {:?}",-                        mono_item-                    );+        let cgu_name_builder = &mut CodegenUnitNameBuilder::new(tcx);++        if tcx.sess.opts.incremental.is_some() {+            // If we are doing incremental compilation, we want CGU names to+            // reflect the path of the source level module they correspond to.+            // For CGUs that contain the code of multiple modules because of the+            // merging done above, we use a concatenation of the names of+            // all contained CGUs.+            let new_cgu_names: FxHashMap<Symbol, String> = cgu_contents+                .into_iter()+                // This `filter` makes sure we only update the name of CGUs that+                // were actually modified by merging.+                .filter(|(_, cgu_contents)| cgu_contents.len() > 1)+                .map(|(current_cgu_name, cgu_contents)| {+                    let mut cgu_contents: Vec<&str> = cgu_contents.iter().map(|s| &s[..]).collect();++                    // Sort the names, so things are deterministic and easy to+                    // predict.+                    cgu_contents.sort();++                    (current_cgu_name, cgu_contents.join("--"))+                })+                .collect();++            for cgu in codegen_units.iter_mut() {+                if let Some(new_cgu_name) = new_cgu_names.get(&cgu.name()) {+                    if tcx.sess.opts.debugging_opts.human_readable_cgu_names {+                        cgu.set_name(Symbol::intern(&new_cgu_name));+                    } else {+                        // If we don't require CGU names to be human-readable, we+                        // use a fixed length hash of the composite CGU name+                        // instead.+                        let new_cgu_name = CodegenUnit::mangle_name(&new_cgu_name);+                        cgu.set_name(Symbol::intern(&new_cgu_name));+                    }                 }+            }+        } else {+            // If we are compiling non-incrementally we just generate simple CGU+            // names containing an index.+            for (index, cgu) in codegen_units.iter_mut().enumerate() {+                cgu.set_name(numbered_codegen_unit_name(cgu_name_builder, index));+            }+        }+    } -                // This is a CGU-private copy.-                new_codegen_unit-                    .items_mut()-                    .insert(mono_item, (Linkage::Internal, Visibility::Default));+    fn place_inlined_mono_items(+        &mut self,+        initial_partitioning: PreInliningPartitioning<'tcx>,+        inlining_map: &InliningMap<'tcx>,+    ) -> PostInliningPartitioning<'tcx> {+        let mut new_partitioning = Vec::new();+        let mut mono_item_placements = FxHashMap::default();++        let PreInliningPartitioning {+            codegen_units: initial_cgus,+            roots,+            internalization_candidates,+        } = initial_partitioning;++        let single_codegen_unit = initial_cgus.len() == 1;

Viewing in diff mode with whitespace changes hidden is a huge win here. :)

wesleywiser

comment created time in 2 months

PullRequestReviewEvent

issue openedrust-lang/rust

bootstrap test failure with parallel-compiler=true

I changed the config.toml to say

parallel-compiler = true

and ran x.py test.

I got this result:

failures:
    [ui] ui/associated-types/defaults-cyclic-fail-1.rs
    [ui] ui/associated-types/defaults-cyclic-fail-2.rs
    [ui] ui/privacy/privacy2.rs
    [ui] ui/privacy/privacy3.rs
    [ui] ui/traits/cycle-cache-err-60010.rs

test result: FAILED. 10601 passed; 5 failed; 63 ignored; 0 measured; 0 filtered out

<details>

More specifically:

failures:

---- [ui] ui/associated-types/defaults-cyclic-fail-1.rs stdout ----
diff of stderr:

22	LL |     type A = Box<Self::B>;
23	   |     ^^^^^^^^^^^^^^^^^^^^^^
24	
-	error[E0275]: overflow evaluating the requirement `<usize as Tr>::A`
-	  --> $DIR/defaults-cyclic-fail-1.rs:37:5
-	   |
-	LL |     type B = &'static Self::A;
-	   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
-	
-	error: aborting due to 5 previous errors
+	error: aborting due to 4 previous errors
32	
33	For more information about this error, try `rustc --explain E0275`.
34	


The actual stderr differed from the expected stderr.
Actual stderr saved to /home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-1/defaults-cyclic-fail-1.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args associated-types/defaults-cyclic-fail-1.rs`

error: 1 errors occurred comparing output.
status: exit code: 1
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-1.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-1" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-1/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0275]: overflow evaluating the requirement `<() as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-1.rs:10:6
   |
LL | impl Tr for () {}
   |      ^^

error[E0275]: overflow evaluating the requirement `<bool as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-1.rs:28:6
   |
LL | impl Tr for bool {
   |      ^^

error[E0275]: overflow evaluating the requirement `<usize as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-1.rs:35:6
   |
LL | impl Tr for usize {
   |      ^^

error[E0275]: overflow evaluating the requirement `<bool as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-1.rs:30:5
   |
LL |     type A = Box<Self::B>;
   |     ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0275`.

------------------------------------------


---- [ui] ui/associated-types/defaults-cyclic-fail-2.rs stdout ----
diff of stderr:

22	LL |     type A = Box<Self::B>;
23	   |     ^^^^^^^^^^^^^^^^^^^^^^
24	
-	error[E0275]: overflow evaluating the requirement `<usize as Tr>::A`
-	  --> $DIR/defaults-cyclic-fail-2.rs:39:5
-	   |
-	LL |     type B = &'static Self::A;
-	   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
-	
-	error: aborting due to 5 previous errors
+	error: aborting due to 4 previous errors
32	
33	For more information about this error, try `rustc --explain E0275`.
34	


The actual stderr differed from the expected stderr.
Actual stderr saved to /home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-2/defaults-cyclic-fail-2.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args associated-types/defaults-cyclic-fail-2.rs`

error: 1 errors occurred comparing output.
status: exit code: 1
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-2.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-2" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/associated-types/defaults-cyclic-fail-2/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0275]: overflow evaluating the requirement `<() as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-2.rs:12:6
   |
LL | impl Tr for () {}
   |      ^^

error[E0275]: overflow evaluating the requirement `<bool as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-2.rs:30:6
   |
LL | impl Tr for bool {
   |      ^^

error[E0275]: overflow evaluating the requirement `<usize as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-2.rs:37:6
   |
LL | impl Tr for usize {
   |      ^^

error[E0275]: overflow evaluating the requirement `<bool as Tr>::B`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/associated-types/defaults-cyclic-fail-2.rs:32:5
   |
LL |     type A = Box<Self::B>;
   |     ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0275`.

------------------------------------------


---- [ui] ui/privacy/privacy2.rs stdout ----
diff of stderr:

23	
24	error: requires `sized` lang_item
25	
-	error: aborting due to 3 previous errors
+	error: requires `sized` lang_item
+	
+	error: requires `sized` lang_item
+	
+	error: aborting due to 5 previous errors
27	
28	Some errors have detailed explanations: E0432, E0603.
29	For more information about an error, try `rustc --explain E0432`.


The actual stderr differed from the expected stderr.
Actual stderr saved to /home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy2/privacy2.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args privacy/privacy2.rs`

error: 1 errors occurred comparing output.
status: exit code: 1
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy2.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy2" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy2/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0432]: unresolved import `bar::foo`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy2.rs:17:9
   |
LL |     use bar::foo;
   |         ^^^^^^^^ no `foo` in `bar`

error[E0603]: function import `foo` is private
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy2.rs:23:20
   |
LL |     use bar::glob::foo;
   |                    ^^^ private function import
   |
note: the function import `foo` is defined here...
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy2.rs:10:13
   |
LL |         use foo;
   |             ^^^
note: ...and refers to the function `foo` which is defined here
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy2.rs:14:1
   |
LL | pub fn foo() {}
   | ^^^^^^^^^^^^ consider importing it directly

error: requires `sized` lang_item

error: requires `sized` lang_item

error: requires `sized` lang_item

error: aborting due to 5 previous errors

Some errors have detailed explanations: E0432, E0603.
For more information about an error, try `rustc --explain E0432`.

------------------------------------------


---- [ui] ui/privacy/privacy3.rs stdout ----
diff of stderr:

6	
7	error: requires `sized` lang_item
8	
-	error: aborting due to 2 previous errors
+	error: requires `sized` lang_item
+	
+	error: requires `sized` lang_item
+	
+	error: aborting due to 4 previous errors
10	
11	For more information about this error, try `rustc --explain E0432`.
12	


The actual stderr differed from the expected stderr.
Actual stderr saved to /home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy3/privacy3.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args privacy/privacy3.rs`

error: 1 errors occurred comparing output.
status: exit code: 1
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy3.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy3" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/privacy/privacy3/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0432]: unresolved import `bar::gpriv`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/privacy/privacy3.rs:18:9
   |
LL |     use bar::gpriv;
   |         ^^^^^^^^^^ no `gpriv` in `bar`

error: requires `sized` lang_item

error: requires `sized` lang_item

error: requires `sized` lang_item

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0432`.

------------------------------------------


---- [ui] ui/traits/cycle-cache-err-60010.rs stdout ----
diff of stderr:

6	   |
7	   = note: required because of the requirements on the impl of `Query<RootDatabase>` for `ParseQuery`
8	
-	error[E0275]: overflow evaluating the requirement `Runtime<RootDatabase>: std::panic::RefUnwindSafe`
-	  --> $DIR/cycle-cache-err-60010.rs:31:20
-	   |
-	LL | trait Database {
-	   |       -------- required by a bound in this
-	LL |     type Storage;
-	   |     ------------- required by this bound in `Database`
-	...
-	LL |     type Storage = SalsaStorage;
-	   |                    ^^^^^^^^^^^^
-	   |
-	   = note: required because it appears within the type `RootDatabase`
-	   = note: required because of the requirements on the impl of `SourceDatabase` for `RootDatabase`
-	   = note: required because of the requirements on the impl of `Query<RootDatabase>` for `ParseQuery`
-	   = note: required because it appears within the type `SalsaStorage`
-	
-	error: aborting due to 2 previous errors
+	error: aborting due to previous error
26	
27	For more information about this error, try `rustc --explain E0275`.
28	


The actual stderr differed from the expected stderr.
Actual stderr saved to /home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/traits/cycle-cache-err-60010/cycle-cache-err-60010.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args traits/cycle-cache-err-60010.rs`

error: 1 errors occurred comparing output.
status: exit code: 1
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/traits/cycle-cache-err-60010.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/traits/cycle-cache-err-60010" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui/traits/cycle-cache-err-60010/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error[E0275]: overflow evaluating the requirement `RootDatabase: SourceDatabase`
  --> /home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui/traits/cycle-cache-err-60010.rs:27:13
   |
LL |     _parse: <ParseQuery as Query<RootDatabase>>::Data, //~ ERROR overflow
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: required because of the requirements on the impl of `Query<RootDatabase>` for `ParseQuery`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0275`.

------------------------------------------



failures:
    [ui] ui/associated-types/defaults-cyclic-fail-1.rs
    [ui] ui/associated-types/defaults-cyclic-fail-2.rs
    [ui] ui/privacy/privacy2.rs
    [ui] ui/privacy/privacy3.rs
    [ui] ui/traits/cycle-cache-err-60010.rs

test result: FAILED. 10601 passed; 5 failed; 63 ignored; 0 measured; 0 filtered out

thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:353:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


command did not execute successfully: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/lib" "--run-lib-path" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "--src-base" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/ui" "--build-base" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage1-x86_64-unknown-linux-gnu" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-opt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python" "--lldb-python" "/usr/bin/python" "--gdb" "/usr/bin/gdb" "--lldb-version" "lldb version 10.0.0\n" "--lldb-python-dir" "/usr/lib/lib/python3/dist-packages" "--quiet" "--llvm-version" "10.0.1-rust-dev" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel gtest gtest_main hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcerror orcjit passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target testingsupport textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""

</details>

I know that the parallel-compiler setting is still experimental/unsupported.

But it would be nice if it didn't inject test failures like this, if we can fix it.

created time in 2 months

pull request commentrust-lang/rust

Disable zlib in LLVM on Haiku

The specific outcome from the meeting can be summarized like so:

Anyway I think the main question for this meeting is whether we're okay with diverging behavior between tier 1 and 2 (and 3) without bugs filed to fix that

This seems ok to me provided we document tier 1 support requires zlib support.

nielx

comment created time in 2 months

issue commentrust-lang/compiler-team-prioritization

Triagebot command to open associated zulip topic

Cc @Mark-Simulacrum

pnkfelix

comment created time in 2 months

issue openedrust-lang/compiler-team-prioritization

Triagebot command to open associated zulip topic

@spastorino and @pnkfelix were recently discussing ways to more readily link to associated zulip conversations, and to create fresh Zulip topcs when needed.

During that discussion, @spastorino suggested the idea of something like @triagebot discuss <optional-title>, which would be a way to ask triagebot to:

  1. Create a zulip topic that links back to the current issue or PR (or, if a topic with the matching title and issue number already exists, then build a link to that pre-existing topic)
  2. Add a comment that links to that topic to the issue/PR
  3. Edit the issue/PR description to link to the Zulip discussion.

This would hopefully ease driving people towards Zulip for transient discussion (e.g. debating finer details of a posted comment, for example), and also help normalize the selection of Zulip topics (since right now the creation of associated Zulip topics is entirely up to the person creating the topic, and so it isn’t always easy for others to discover such pre-created topics)...

created time in 2 months

pull request commentrust-lang/rust

allow escaping bound vars when normalizing `ty::Opaque`

Unilaterally beta-accepting

lcnr

comment created time in 2 months

Pull request review commentrust-lang/rust

Disallow later override of forbid lint in same scope

 impl<'s> LintLevelsBuilder<'s> {         self.sets.list.push(LintSet::CommandLine { specs });     } +    /// Attempts to insert the `id` to `level_src` map entry. If unsuccessful+    /// (e.g. if a forbid was already inserted on the same scope), then emits a+    /// diagnostic with no change to `specs`.+    fn insert_spec(+        &mut self,+        specs: &mut FxHashMap<LintId, LevelSource>,+        id: LintId,+        (level, src): LevelSource,+    ) {+        if let Some((old_level, old_src)) = specs.get(&id) {+            if old_level == &Level::Forbid && level != Level::Forbid {+                let mut diag_builder = struct_span_err!(+                    self.sess,+                    src.span(),+                    E0453,+                    "{}({}) incompatible with previous forbid in same scope",

The problem with making command line arguments "consistent" with lint attributes, from my point of view, is that I think a lot of tools do inject (or freely mix) new command line arguments, and so I think users run into combinations of -F and -A on a single command line a lot more often than they run into #[forbid] and #[allow] in a single source item.

A hard error for mixing -F and -A when they arose due to e.g. makefile variables is really annoying for end users.

(I suppose the analogy for source code items would be macro expansion, right? Does one see #[allow] getting injected from macros very often? I can admit this has crossed my mind at times, especially back when I put in the push_unsafe/pop_unsafe hacks five years ago ...)

pnkfelix

comment created time in 2 months

PullRequestReviewEvent

pull request commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

I left feedback over here on zulip; basically, I asked wesley to refactor the commit series so that the code shuffling is its own commit, so that the diff will better show what the actual changes are regarding the new trait.

wesleywiser

comment created time in 2 months

Pull request review commentrust-lang/rust

Disallow later override of forbid lint in same scope

 impl<'s> LintLevelsBuilder<'s> {         self.sets.list.push(LintSet::CommandLine { specs });     } +    /// Attempts to insert the `id` to `level_src` map entry. If unsuccessful+    /// (e.g. if a forbid was already inserted on the same scope), then emits a+    /// diagnostic with no change to `specs`.+    fn insert_spec(+        &mut self,+        specs: &mut FxHashMap<LintId, LevelSource>,+        id: LintId,+        (level, src): LevelSource,+    ) {+        if let Some((old_level, old_src)) = specs.get(&id) {+            if old_level == &Level::Forbid && level != Level::Forbid {+                let mut diag_builder = struct_span_err!(+                    self.sess,+                    src.span(),+                    E0453,+                    "{}({}) incompatible with previous forbid in same scope",

I don't understand your response.

Its a hard error to have a forbid on one scope and something else in a nested scope. (AIUI, that's the whole point of forbid, versus deny).

For example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=63cb51c86b8b1c15a8b22f132ce6c32e

Can you show me an example of what current behavior of forbid that you think I should be modelling instead?

pnkfelix

comment created time in 2 months

push eventpnkfelix/rust

bors

commit sha 18e2a891999e66d856ea13db879e93076de9e237

Auto merge of #74945 - dingxiangfei2009:promote-static-ref-deref, r=oli-obk [mir] Special treatment for dereferencing a borrow to a static definition Fix #70584. As suggested by @oli-obk in this [comment](https://github.com/rust-lang/rust/issues/70584#issuecomment-626009260), one can chase the definition of the local variable being de-referenced and check if it is a true static variable. If that is the case, `validate_place` will admit the promotion. This is my first time to contribute to `rustc`, and I have two questions. 1. A generalization to some extent is applied to decide if the promotion is possible in the static context. In case that there are more projection operations preceding the de-referencing, `validate_place` recursively decent into inner projection operations. I have put thoughts into its correctness but I am not totally sure about it. 2. I have a hard time to find a good place for the test case. This patch has to do with MIR, but this test case would look out of place compared to other tests in `src/test/ui/mir` or `src/test/ui/borrowck` because it does not generate errors while others do. It is tentatively placed in `src/test/ui/statics` for now. Thank you for any comments and suggestions!

view details

Oliver Scherer

commit sha aba0251c78f88b12c499ba956beb8a9734ffdc1a

Replace a recursive algorithm with an iterative one and a stack.

view details

Bastian Kauschke

commit sha d51b71a35a816f4be56f77d1d1a6f4095352649e

add tracking issue

view details

bors

commit sha b5eae9c44d713779a08e6db352088d45cad3e9b6

Auto merge of #74373 - lcnr:array_chunks, r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed, these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735

view details

bors

commit sha dfe1e3b641abbede6230e3931d14f0d43e5b8e54

Auto merge of #74582 - Lezzz:rename-hair, r=nikomatsakis Rename HAIR to THIR (Typed HIR). r? @nikomatsakis Originally suggested by @eddyb

view details

bors

commit sha cfdf9d335501cc0a53ae69c940095cca7d4be0f8

Auto merge of #74993 - sunfishcode:update-wasi-libc, r=alexcrichton Update the bundled wasi-libc with libstd This just updates WASI libc, in preparation for WASI reactor support in a separate change. r? @alexcrichton

view details

Stein Somers

commit sha 240ef70c7b2a8f6833355d41001bc65b3a660eb3

Define forget_type only when relevant

view details

Eduard-Mihai Burtescu

commit sha 6bf3a4bcd836e4b29108bfb6d8d7b00d405fd03e

rustc_metadata: track the simplified Self type for every trait impl.

view details

Guillaume Gomez

commit sha 4bd313fb0fd3436058c10c95958f3eb80125a2a3

Clean up E0743 explanation

view details

Oliver Scherer

commit sha c7290379be40f930802f0deea87cdb313332e5cc

Remove chrono feature from tracing

view details

Manish Goregaokar

commit sha 60bf83d21531c09c7005adff681e32e186d40f4b

Rollup merge of #74977 - GuillaumeGomez:cleanup-e0741, r=pickfire Clean up E0741 error explanation r? @Dylan-DPC

view details

Manish Goregaokar

commit sha e65d6ed80ff1b0f1f5bab3e210f8f2cd165d4f14

Rollup merge of #74981 - giraffate:fix_sample_codes_in_unstable_book_plugin, r=GuilliameGomez Some fixes for `plugin.md` in unstable-book - sample codes not working I referred to https://github.com/rust-lang/rust/blob/master/src/test/ui-fulldeps/auxiliary/lint-plugin-test.rs and https://github.com/rust-lang/rust/blob/master/src/test/ui-fulldeps/lint-plugin.rs. - broken link https://github.com/rust-lang/rust/blob/master/src/librustc/lint/builtin.rs -> https://github.com/rust-lang/rust/blob/master/src/librustc_session/lint/builtin.rs

view details

Manish Goregaokar

commit sha 69515819b625292f0c175a92d93339b2f231b947

Rollup merge of #74983 - oli-obk:mir_opt_goto_chain, r=ecstatic-morse Replace a recursive algorithm with an iterative one and a stack. fixes #74931

view details

Manish Goregaokar

commit sha 58df0a0473d7a02959a2a7043a2d46688909b5fe

Rollup merge of #74995 - sunfishcode:update-llvm, r=alexcrichton Update the WASI libc build to LLVM 10. Among other things, this brings in [the `__main_argc_argv`] patch, which simplifies the interaction between the compiler and WASI libc's startup code, which will help work on reactor support. [the `__main_argc_argv` patch]: https://github.com/llvm/llvm-project/commit/00072c08c75050ae2c835b7bb0e505475dbcd7b9 r? @alexcrichton

view details

Manish Goregaokar

commit sha 302dfbc5674bc05c931e1f61a7fcf69aad79c2ca

Rollup merge of #74996 - matthiaskrgr:submodule_upd, r=ehuss submodules: update cargo from 974eb438d to 2d5c2381e Changes: ```` Use the same index location on nightly as beta relax deprecated diagnostic message check Don't print to raw stderr in test Emit the `test` field in cargo metadata ```` r? @ehuss Trying to get the fix to the registry-index-hash upstream soonish.

view details

Manish Goregaokar

commit sha 2e53ac53e7e760d46f47a3aed806b172ccffd88d

Rollup merge of #75007 - GuillaumeGomez:cleanup-e0743, r=pickfire Clean up E0743 explanation r? @Dylan-DPC

view details

Amanieu d'Antras

commit sha df3a30aee4fe514c1fd1193d3a7e739b1a66ab8f

Add Vec::spare_capacity_mut

view details

Alexis Bourget

commit sha 54eb3768e0077bc18152b5fc3d19824cde69c8ce

Reword incorrect use of zeroed()

view details

Stein Somers

commit sha 602f9aab89791ac2e63d0a41731ddf0a9b727f29

More benchmarks of BTreeMap mutation

view details

Josh Stone

commit sha 66a02ec2d6d8c2f0394be18b9a5011acccc4ba9a

Use a slice pattern instead of rchunks_exact(_).next() This is a minor cleanup, but trying a single-use `rchunks` iterator can be more directly matched with a slice pattern, `[.., a, b]`.

view details

push time in 2 months

issue commentrust-lang/compiler-team

Form t-compiler/wg-parser-library

@rustbot second

matklad

comment created time in 2 months

push eventpnkfelix/pnkfelix.github.com

dependabot[bot]

commit sha 9e7d7d1d6330d13ff48298760939065282c36de0

Bump mustache from 0.7.3 to 4.0.1 in /reveal.js Bumps [mustache](https://github.com/janl/mustache.js) from 0.7.3 to 4.0.1. - [Release notes](https://github.com/janl/mustache.js/releases) - [Changelog](https://github.com/janl/mustache.js/blob/master/CHANGELOG.md) - [Commits](https://github.com/janl/mustache.js/compare/0.7.3...v4.0.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

Felix S Klock II

commit sha 3e70a4821ea41289924c4e11b1425d41583900ef

Merge pull request #1 from pnkfelix/dependabot/npm_and_yarn/reveal.js/mustache-4.0.1 Bump mustache from 0.7.3 to 4.0.1 in /reveal.js

view details

push time in 2 months

PR merged pnkfelix/pnkfelix.github.com

Bump mustache from 0.7.3 to 4.0.1 in /reveal.js dependencies

Bumps mustache from 0.7.3 to 4.0.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/janl/mustache.js/releases">mustache's releases</a>.</em></p> <blockquote> <h2>v3.1.0</h2> <h3>Added</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">#717</a>: Added support .js files as views in command line tool, by [<a href="https://github.com/JEStaubach">@JEStaubach</a>].</li> </ul> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">#716</a>: Bugfix for indentation of inline partials, by [<a href="https://github.com/yotammadem">@yotammadem</a>].</li> </ul> <p><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">#716</a>: <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/716">janl/mustache.js#716</a> <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">#717</a>: <a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/717">janl/mustache.js#717</a> [<a href="https://github.com/JEStaubach">@JEStaubach</a>]: <a href="https://github.com/JEStaubach">https://github.com/JEStaubach</a> [<a href="https://github.com/yotammadem">@yotammadem</a>]: <a href="https://github.com/yotammadem">https://github.com/yotammadem</a></p> <h2>v3.0.2</h2> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/705">#705</a>: Fix indentation of partials, by <a href="https://github.com/kevindew">@kevindew</a> and <a href="https://github.com/yotammadem">@yotammadem</a>.</li> </ul> <h3>Dev</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/701">#701</a>: Fix test failure for Node 10 and above, by <a href="https://github.com/andersk">@andersk</a>.</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/704">#704</a>: Lint all test files just like the source files, by <a href="https://github.com/phillipj">@phillipj</a>.</li> <li>Start experimenting & comparing GitHub Actions vs Travis CI, by <a href="https://github.com/phillipj">@phillipj</a>.</li> </ul> <h2>v3.0.1</h2> <p><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/679">#679</a>: Fix partials not rendering tokens when using custom tags, by <a href="https://github.com/stackchain">@stackchain</a>.</p> <h2>v3.0.0</h2> <h2>[3.0.0] / 16 September 2018</h2> <p>We are very happy to announce a new major version of mustache.js. We want to be very careful not to break projects out in the wild, and adhering to <a href="http://semver.org/">Semantic Versioning</a> we have therefore cut this new major version.</p> <p>The changes introduced will likely not require any actions for most using projects. The things to look out for that might cause unexpected rendering results are described in the migration guide below.</p> <p>A big shout out and thanks to [<a href="https://github.com/raymond-lam">@raymond-lam</a>] for this release! Without his contributions with code and issue triaging, this release would never have happened.</p> <h3>Major</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/618">#618</a>: Allow rendering properties of primitive types that are not objects, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/643">#643</a>: <code>Writer.prototype.parse</code> to cache by tags in addition to template string, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/664">#664</a>: Fix <code>Writer.prototype.parse</code> cache, by [<a href="https://github.com/seminaoki">@seminaoki</a>].</li> </ul> <h3>Minor</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/673">#673</a>: Add <code>tags</code> parameter to <code>Mustache.render()</code>, by [<a href="https://github.com/raymond-lam">@raymond-lam</a>].</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/janl/mustache.js/blob/master/CHANGELOG.md">mustache's changelog</a>.</em></p> <blockquote> <h2>[4.0.1] / 15 March 2020</h2> <h3>Fixed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/739">#739</a>: Fix custom delimiters in nested partials, by [<a href="https://github.com/aielo">@aielo</a>].</li> </ul> <h2>[4.0.0] / 16 January 2020</h2> <p>Majority of using projects don't have to worry by this being a new major version.</p> <p><strong>TLDR;</strong> if your project manipulates <code>Writer.prototype.parse | Writer.cache</code> directly or uses <code>.to_html()</code>, you probably have to change that code.</p> <p>This release allows the internal template cache to be customised, either by disabling it completely or provide a custom strategy deciding how the cache should behave when mustache.js parses templates.</p> <pre lang="js"><code>const mustache = require('mustache'); <p>// disable caching Mustache.templateCache = undefined;</p> <p>// or use a built-in Map in modern environments Mustache.templateCache = new Map(); </code></pre></p> <p>Projects that wanted to customise the caching behaviour in earlier versions of mustache.js were forced to override internal method responsible for parsing templates; <code>Writer.prototype.parse</code>. In short, that was unfortunate because there is more than caching happening in that method.</p> <p>We've improved that now by introducing a first class API that only affects template caching.</p> <p>The default template cache behaves as before and is still compatible with older JavaScript environments. For those who wants to provide a custom more sopisiticated caching strategy, one can do that with an object that adheres to the following requirements:</p> <pre lang="ts"><code>{ set(cacheKey: string, value: string): void get(cacheKey: string): string | undefined clear(): void } </code></pre> <h3>Added</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/731">#731</a>: Allow template caching to be customised, by [<a href="https://github.com/AndrewLeedham">@AndrewLeedham</a>].</li> </ul> <h3>Removed</h3> <ul> <li><a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/735">#735</a>: Remove <code>.to_html()</code>, by [<a href="https://github.com/phillipj">@phillipj</a>].</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/janl/mustache.js/commit/1de94bbdd3fe4b903cfbc084ebaaccfd1299dd3f"><code>1de94bb</code></a> :ship: bump to version 4.0.1</li> <li><a href="https://github.com/janl/mustache.js/commit/f3bd88837eda6f08bef5ace4b302f8d0e1cc8e14"><code>f3bd888</code></a> Fix custom delimiters in nested partials (<a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/739">#739</a>)</li> <li><a href="https://github.com/janl/mustache.js/commit/aca97b82c80e8fd1d36162e05e4b289380965d96"><code>aca97b8</code></a> :ship: bump to version 4.0.0</li> <li><a href="https://github.com/janl/mustache.js/commit/f3012a2477a90ac98a1f8cbd2a53bafaeb4adc7d"><code>f3012a2</code></a> Remove mustache.to_html() (<a href="https://github-redirect.dependabot.com/janl/mustache.js/issues/735">#735</a>)</li> <li><a href="https://github.com/janl/mustache.js/commit/5938104ba717a43dfd9e963dd67accdc1a526421"><code>5938104</code></a> Use fetched template in usage example</li> <li><a href="https://github.com/janl/mustache.js/commit/3bdd27c4e762f665232dc46186c7639e60dbd70e"><code>3bdd27c</code></a> Add a section about TypeScript defs in README</li> <li><a href="https://github.com/janl/mustache.js/commit/7f94f138cbec5592529605cc8af02b58ed20c456"><code>7f94f13</code></a> Move CLI and contribute section down in README</li> <li><a href="https://github.com/janl/mustache.js/commit/39ee6ffc2c25ce8f89a906104498450bbfb31527"><code>39ee6ff</code></a> Point out it's a zero-dependency package in README</li> <li><a href="https://github.com/janl/mustache.js/commit/c41045baf8fcb14cc6b48db4b784dcef3e82cd26"><code>c41045b</code></a> Removing the rtype API definitions from README</li> <li><a href="https://github.com/janl/mustache.js/commit/bd742d5080f70008dc35e58a1d87152938d2f98b"><code>bd742d5</code></a> Add response.text() from fetch() in README example</li> <li>Additional commits viewable in <a href="https://github.com/janl/mustache.js/compare/0.7.3...v4.0.1">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~flipp">flipp</a>, a new releaser for mustache since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 2 months

issue commentrust-lang/rust

async-std docs no longer build on recent nightlies

@jyn514 I just reviewed it. I assume the rustdoc team is onboard with the other changes it makes. (Certainly ignoring the resolution errors in those cases seems to be in line with what rustdoc does elsewhere at this point.)

yoshuawuyts

comment created time in 3 months

pull request commentrust-lang/rust

Fix async-std by special-casing rustdoc in typeck

@bors rollup=never

jyn514

comment created time in 3 months

pull request commentrust-lang/rust

Fix async-std by special-casing rustdoc in typeck

@bors r+

jyn514

comment created time in 3 months

issue commentrust-lang/rust

async-std docs no longer build on recent nightlies

Another option since beta is coming up in ~3 weeks is to just eat the ICE and say that error -> ICE is better than working code to error :/ and then go back and fix the root cause later. The only ICE is from invalid code:

https://github.com/rust-lang/rust/blob/0f5be70ea4c3ec4544cdeb80e3138832e15815f9/src/test/rustdoc-ui/infinite-recursive-type.rs#L1-L4

Also, keep in mind that yet another option, which I think is similar (but maybe less risky), is to revert PR# #73566, with the intention of relanding a more robust version of the change once the bugs are ironed out. (The presentation given in an earlier comment's discussion of a revert made it sound to me like it was a decision we'd have to live with forever, which is not the case as far as I can tell.)

  • (Of course, a revert of PR #73566 would mean suffering with the bugs that PR fixed for a bit longer on stable Rust.)
yoshuawuyts

comment created time in 3 months

pull request commentrust-lang/rust

[android] Add support for android's file descriptor ownership tagging to libstd.

discussed at today's T-compiler triage meeting.

The T-compiler members present at the meeting didn't have any strong opinions here. We agreed with @nikomatsakis that this warrants an FCP of some sort.

There was general consensus that this is, at its heart, a question of what the publicly specified API for Rust's File should be; the actual implementation code (which T-compiler maintains) is pretty trivial.

So we collectively decided at the meeting that while this should require an FCP, it should really solely require an FCP of the members of T-libs; T-compiler is going to opt out of participating in the FCP.

Thus, I am removing T-compiler, adding T-libs, and will go see if I can find a T-libs member to start up the FCP process for this PR.

jmgao

comment created time in 3 months

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

@zeldin okay, thanks. While I was hoping you'd have a smaller test case, the info you have given is nonetheless very helpful, since I think I'll have an easier time investigating this on PPC64, which is (I believe) a higher tier platform than SPARC Solaris. (At the very least, PPC64 has rustup-support...)

psumbera

comment created time in 3 months

startedshepmaster/rust

started time in 3 months

issue commentrust-lang/compiler-team

Discuss results of 2020 Contributor Survey

After learning that @mark-i-m may be unavailable on the scheduled August 14th, we decided to drop this meeting from the schedule; we'll try to get it into the next steering meeting cycle.

mark-i-m

comment created time in 3 months

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

@zeldin when you say "exactly the same problem", are you also attempting to build firefox and seeing this failure on teh gkrust crate?

Or do you have a smaller example test case to illustrate the problem on Linux/PPC64?

psumbera

comment created time in 3 months

push eventpnkfelix/pnkfelix.github.com

Felix S. Klock II

commit sha a0839d1d0a1644978ae4c052d067c2fbf3cb9cd6

updated resume.

view details

Felix S. Klock II

commit sha cabc2851699a4ddb3cda2f2c8acd6202c749be8f

updated generated resume.

view details

push time in 3 months

issue openedrust-lang/rust

support for boostraping on linux with `target = ["x86_64-unknown-linux-gnu", "x86_64-pc-windows-msvc"]`

Spawned off of https://zulip-archive.rust-lang.org/131828tcompiler/10990bootstraponlinuxwsupportforcrosscompilingtowind.html

After being reminded that one can install the stdlib for windows-msvc on a Linux host, that led me to ask whether one could build that artifact locally.

I tried to do so, but failed. You can see the results of some questions I asked and suggestions made in response at the above chat thread.

I don't think we need to make this support 100% transparent; e.g., it seems okay to force people to also specify that they don't want any dylibs, just rlibs. (Though it might be nice if there were a config.toml line for this rather than being forced to edit the Config.toml for a bunch of stdlib crates.)

In any case, I couldn't figure out how to get it to work, so this issue is meant to track effort to make this possible, and, if necessary, document what other changes a developer would need to make to their local setup (such as the aforementioned rlib thing) to get it going.

(The current roadblock is that the attempt to build compiler-builtins is trying to add /Zl as an option, which does not work on this host.)

<details> <summary>Click for more info on what changes I made locally to get as far as I could</summary>

% git diff --no-color && diff -u ../config.toml.example config.toml ; time ../x.py build --stage 1
diff --git a/library/std/Cargo.toml b/library/std/Cargo.toml
index 474765d8638..ed09312cb84 100644
--- a/library/std/Cargo.toml
+++ b/library/std/Cargo.toml
@@ -8,7 +8,7 @@ description = "The Rust Standard Library"
 edition = "2018"
 
 [lib]
-crate-type = ["dylib", "rlib"]
+crate-type = ["rlib"]
 
 [dependencies]
 alloc = { path = "../alloc" }
diff --git a/library/test/Cargo.toml b/library/test/Cargo.toml
index 7b76dc83aa2..42bfdb526c5 100644
--- a/library/test/Cargo.toml
+++ b/library/test/Cargo.toml
@@ -5,7 +5,7 @@ version = "0.0.0"
 edition = "2018"
 
 [lib]
-crate-type = ["dylib", "rlib"]
+crate-type = ["rlib"]
 
 [dependencies]
 cfg-if = { version = "0.1.8", features = ['rustc-dep-of-std'] }
diff --git a/src/bootstrap/sanity.rs b/src/bootstrap/sanity.rs
index f89bef50de9..f319d6194d5 100644
--- a/src/bootstrap/sanity.rs
+++ b/src/bootstrap/sanity.rs
@@ -217,13 +217,14 @@ pub fn check(build: &mut Build) {
             }
         }
 
-        if target.contains("msvc") {
+        if building_llvm && build.hosts.iter().any(|host|host.contains("msvc"))
+        {
             // There are three builds of cmake on windows: MSVC, MinGW, and
             // Cygwin. The Cygwin build does not have generators for Visual
             // Studio, so detect that here and error.
             let out = output(Command::new("cmake").arg("--help"));
             if !out.contains("Visual Studio") {
-                panic!(
+                eprintln!(
                     "
 cmake does not support Visual Studio generators.
 
--- ../config.toml.example	2020-08-04 11:10:07.940144080 -0400
+++ config.toml	2020-08-04 11:23:11.839046744 -0400
@@ -136,6 +136,7 @@
 #
 # Defaults to just the build triple
 #target = ["x86_64-unknown-linux-gnu"]
+target = ["x86_64-unknown-linux-gnu", "x86_64-pc-windows-msvc"]
 
 # Use this directory to store build artifacts.
 # You can use "$ROOT" to indicate the root of the git repository.
@@ -525,6 +526,7 @@
 # compiler itself. This is useful for building rustc on targets that normally
 # only use static libraries. If unset, the target's default linkage is used.
 #crt-static = false
+crt-static = true
 
 # The root location of the musl installation directory. The library directory
 # will also need to contain libunwind.a for an unwinding implementation. Note
Updating only changed submodules
Submodules updated in 0.03 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-pc-windows-msvc)
   Compiling core v0.0.0 (/home/pnkfelix/Dev/Mozilla/rust-xplat/library/core)
   Compiling libc v0.2.74
   Compiling compiler_builtins v0.1.32
The following warnings were emitted during compilation:

warning: cc: error: /Zl: No such file or directory

error: failed to run custom build command for `compiler_builtins v0.1.32`

Caused by:
  process didn't exit successfully: `/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/release/build/compiler_builtins-09dda507c59e8728/build-script-build` (exit code: 1)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:compiler-rt=/home/pnkfelix/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.32/compiler-rt
  cargo:rustc-cfg=feature="unstable"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c
  cargo:rustc-cfg=__absvdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvsi2.c
  cargo:rustc-cfg=__absvsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvti2.c
  cargo:rustc-cfg=__absvti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvdi3.c
  cargo:rustc-cfg=__addvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvsi3.c
  cargo:rustc-cfg=__addvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/addvti3.c
  cargo:rustc-cfg=__addvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzdi2.c
  cargo:rustc-cfg=__clzdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzsi2.c
  cargo:rustc-cfg=__clzsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/clzti2.c
  cargo:rustc-cfg=__clzti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/cmpdi2.c
  cargo:rustc-cfg=__cmpdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/cmpti2.c
  cargo:rustc-cfg=__cmpti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzdi2.c
  cargo:rustc-cfg=__ctzdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzsi2.c
  cargo:rustc-cfg=__ctzsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ctzti2.c
  cargo:rustc-cfg=__ctzti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divdc3.c
  cargo:rustc-cfg=__divdc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divsc3.c
  cargo:rustc-cfg=__divsc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/divxc3.c
  cargo:rustc-cfg=__divxc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/extendhfsf2.c
  cargo:rustc-cfg=__extendhfsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ffsti2.c
  cargo:rustc-cfg=__ffsti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatdisf.c
  cargo:rustc-cfg=__floatdisf="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatdixf.c
  cargo:rustc-cfg=__floatdixf="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/int_util.c
  cargo:rustc-cfg=__int_util="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/muldc3.c
  cargo:rustc-cfg=__muldc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulsc3.c
  cargo:rustc-cfg=__mulsc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvdi3.c
  cargo:rustc-cfg=__mulvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvsi3.c
  cargo:rustc-cfg=__mulvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulvti3.c
  cargo:rustc-cfg=__mulvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/mulxc3.c
  cargo:rustc-cfg=__mulxc3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negdf2.c
  cargo:rustc-cfg=__negdf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negdi2.c
  cargo:rustc-cfg=__negdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negsf2.c
  cargo:rustc-cfg=__negsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negti2.c
  cargo:rustc-cfg=__negti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvdi2.c
  cargo:rustc-cfg=__negvdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvsi2.c
  cargo:rustc-cfg=__negvsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/negvti2.c
  cargo:rustc-cfg=__negvti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/paritydi2.c
  cargo:rustc-cfg=__paritydi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/paritysi2.c
  cargo:rustc-cfg=__paritysi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/parityti2.c
  cargo:rustc-cfg=__parityti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountdi2.c
  cargo:rustc-cfg=__popcountdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountsi2.c
  cargo:rustc-cfg=__popcountsi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/popcountti2.c
  cargo:rustc-cfg=__popcountti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/powixf2.c
  cargo:rustc-cfg=__powixf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvdi3.c
  cargo:rustc-cfg=__subvdi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvsi3.c
  cargo:rustc-cfg=__subvsi3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/subvti3.c
  cargo:rustc-cfg=__subvti3="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncdfhf2.c
  cargo:rustc-cfg=__truncdfhf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncdfsf2.c
  cargo:rustc-cfg=__truncdfsf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/truncsfhf2.c
  cargo:rustc-cfg=__truncsfhf2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ucmpdi2.c
  cargo:rustc-cfg=__ucmpdi2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/ucmpti2.c
  cargo:rustc-cfg=__ucmpti2="optimized-c"
  cargo:rerun-if-changed=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/apple_versioning.c
  cargo:rustc-cfg=apple_versioning="optimized-c"
  TARGET = Some("x86_64-pc-windows-msvc")
  OPT_LEVEL = Some("3")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_x86_64-pc-windows-msvc = None
  CC_x86_64_pc_windows_msvc = None
  TARGET_CC = None
  CC = None
  CROSS_COMPILE = None
  CFLAGS_x86_64-pc-windows-msvc = None
  CFLAGS_x86_64_pc_windows_msvc = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = Some("crt-static,fxsr,mmx,sse,sse2")
  CC_x86_64-pc-windows-msvc = None
  CC_x86_64_pc_windows_msvc = None
  TARGET_CC = None
  CC = None
  CROSS_COMPILE = None
  CFLAGS_x86_64-pc-windows-msvc = None
  CFLAGS_x86_64_pc_windows_msvc = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("crt-static,fxsr,mmx,sse,sse2")
  running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-static" "/Zl" "-ffile-prefix-map=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt=." "-D__func__=__FUNCTION__" "-Fo/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-pc-windows-msvc/release/build/compiler_builtins-53591ff0903ba093/out/absvdi2.o" "-c" "/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c"
  cargo:warning=cc: error: /Zl: No such file or directory
  exit code: 1

  --- stderr


  error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-static" "/Zl" "-ffile-prefix-map=/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt=." "-D__func__=__FUNCTION__" "-Fo/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-pc-windows-msvc/release/build/compiler_builtins-53591ff0903ba093/out/absvdi2.o" "-c" "/home/pnkfelix/Dev/Mozilla/rust-xplat/src/llvm-project/compiler-rt/lib/builtins/absvdi2.c" with args "cc" did not execute successfully (status code exit code: 1).


warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-pc-windows-msvc" "-Zbinary-dep-depinfo" "-j" "128" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/pnkfelix/Dev/Mozilla/rust-xplat/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /home/pnkfelix/Dev/Mozilla/rust-xplat/objdir/build/bootstrap/debug/bootstrap build --stage 1
Build completed unsuccessfully in 0:00:10

real	0m10.967s
user	0m15.619s
sys	0m0.656s

</details>

created time in 3 months

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

At the same time, I'm not really a big fan of putting in such narrowly targetted hacks to work around LLVM bugs, especially ones that have been confirmed to be bugs on LLVM's end.

(having said that, this bug does seem to serve as evidence that our code is probably executing an overflowing addition via unchecked_add. Even though that "merely" generates poison under this particular codegen path (that should be unused and thus won't cause UB), strictly speaking, it is a violation of the contract written for Rust's unchecked_add:

Returns the result of an unchecked addition, resulting in undefined behavior when x + y > T::MAX or x + y < T::MIN.

I'm going to go in and confirm that this add may indeed be overflowing, and if it is, I probably will push for changing to wrapping_add here instead.

AlyoshaVasilieva

comment created time in 3 months

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

To be clear: my thinking is that we could change the range.rs and/or Step code to use wrapping_add rather than unchecked_add.

That way, we shouldn't generate any overflow checking code, so I wouldn't expect any significant performance hit.

At the same time, I'm not really a big fan of putting in such narrowly targetted hacks to work around LLVM bugs, especially ones that have been confirmed to be bugs on LLVM's end.

AlyoshaVasilieva

comment created time in 3 months

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

The only remaining question on our end is if we should, for the short term, change that range.rs code to not used an unchecked_add, in order to (hopefully) bypass the misoptimization here.

(That, or try to figure out a patch to LLVM to fix the bug on their end.)

AlyoshaVasilieva

comment created time in 3 months

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

Filed https://bugs.llvm.org/show_bug.cgi?id=46943 with LLVM upstream.

AlyoshaVasilieva

comment created time in 3 months

push eventpnkfelix/blog.rust-lang.org

Felix S Klock II

commit sha 15c0d9fffa82706ed31d89764559d0e69124ef65

Update 2020-07-31-upcoming-compiler-design-meeting.md

view details

push time in 3 months

PR opened rust-lang/blog.rust-lang.org

Create 2020-07-31-upcoming-compiler-design-meeting.md

Followed structure suggested by https://forge.rust-lang.org/compiler/steering-meeting/how-to-run-planning.html#publish-a-blog-post ; got file name format by looking at past posts.

+28 -0

0 comment

1 changed file

pr created time in 3 months

push eventpnkfelix/blog.rust-lang.org

Felix S Klock II

commit sha da774a9b76011429c89bd2666acb6099fa9a8bff

Create 2020-07-31-upcoming-compiler-design-meeting.md

view details

push time in 3 months

issue commentrust-lang/compiler-team

Discuss results of 2020 Contributor Survey

discussed in today's planning meeting; scheduled for August 14th meeting slot.

<a target="_blank" href="https://calendar.google.com/event?action=TEMPLATE&tmeid=Mzh2ZWlmNjlnbnBtM212OTI0dXN2aWNodG8gNnU1cnJ0Y2U2bHJ0djA3cGZpM2RhbWdqdXNAZw&tmsrc=6u5rrtce6lrtv07pfi3damgjus%40group.calendar.google.com"></a>

mark-i-m

comment created time in 3 months

issue commentrust-lang/rust

error: could not compile `gkrust` since Rust 1.43 on SPARC Solaris

self-assigning to investigate whether its reasonable to replicate this atop GCC build farm or not

psumbera

comment created time in 3 months

issue commentrust-lang/rust

Compiler doesn't terminate with --release

self-assigning to 1. verify this is an LLVM bug and if so, 2. isolate .bc file that we can use to file bug against LLVM itself.

io12

comment created time in 3 months

issue commentrust-lang/rust

Compiler doesn't terminate with --release

@rustbot ping llvm

io12

comment created time in 3 months

pull request commentrust-lang/rust

[stable] 1.45.2 release

@bors r+

Mark-Simulacrum

comment created time in 3 months

issue commentrust-lang/rust

Regression from 1.44 to 1.45

@lcnr commented:

This is a duplicate of the already fixed #73609

by the way, this issue was not, technically, a duplicate of #73609.

Or at least, the issue described in #73609 only surfaces under conditions witnessed after commit 38bd83df88288f2f8d1fc2dd317189cac3825920

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc 2020-04-01 --end 2020-06-22 -- run

</details>

while this issue surfaces under conditions witnessed after commit 3fe4dd2dda2826643c4ce4ee7307707a90e08d25

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc 2020-05-01 --end 2020-06-01 -- run

</details>

It does seem like the same patch fixes both issues; i.e., it seems likely that there is indeed one bug underlying both distinct issues.

But the fact that they are distinct issues helps explain why we did not backport the fix to beta way back when.

mcarton

comment created time in 3 months

pull request commentrust-lang/rust

Fix #[track_caller] shims for trait objects.

discussed stable nomination in T-compiler meeting.

@rustbot modify labels: stable-accepted

anp

comment created time in 3 months

pull request commentrust-lang/rust

Fix incorrect clashing_extern_declarations warnings.

discussed at T-compiler meeting.

We decided the complexity of this PR, weighed against the bug it fixes, does not warrant a backport.

However, we agreed that a PR that just changed the lint on beta to be allow-by-default would be a reasonable thing to put on the beta branch.

jumbatm

comment created time in 3 months

more