-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #99451
Rollup of 8 pull requests #99451
Conversation
This is needed for my Ubuntu 22.04 box due to a slight change in gdb output. The fix is similar to the fix in rust-lang#95063.
Improves the compiler error backtrace information, as shown in rust-lang#99363, by using `span_bug` instead of `bug`. New output: ``` build/aarch64-apple-darwin/stage1/bin/rustc /tmp/test.rs --edition=2021 error: internal compiler error: compiler/rustc_middle/src/ty/closure.rs:185:25: Unexpected type Opaque(DefId(0:5 ~ test[db0f]::main::T::{opaque#0}), []) for `Field` projection --> /tmp/test.rs:11:27 | 11 | let Foo((a, b)) = foo; | ^^^ thread 'rustc' panicked at 'Box<dyn Any>', /Users/jmq/src/forked/rust/compiler/rustc_errors/src/lib.rs:1331:9 stack backtrace: ``` (Remainder of output truncated.)
The restriction that success ordering must be at least as strong as its failure ordering in compare-exchange operations was lifted in rust-lang#98383.
wf-check generators fixes rust-lang#90409 We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.
…estebank Mention first and last macro in backtrace Slight improvement to diagnostic mentioning what macro an error originates from. Not sure if it's worthwhile.
Use split_once in FromStr docs Current implementation: ```rust fn from_str(s: &str) -> Result<Self, Self::Err> { let coords: Vec<&str> = s.trim_matches(|p| p == '(' || p == ')' ) .split(',') .collect(); let x_fromstr = coords[0].parse::<i32>()?; let y_fromstr = coords[1].parse::<i32>()?; Ok(Point { x: x_fromstr, y: y_fromstr }) } ``` Creating the vector is not necessary, `split_once` does the job better. Alternatively we could also remove `trim_matches` with `strip_prefix` and `strip_suffix`: ```rust let (x, y) = s .strip_prefix('(') .and_then(|s| s.strip_suffix(')')) .and_then(|s| s.split_once(',')) .unwrap(); ``` The question is how much 'correctness' is too much and distracts from the example. In a real implementation you would also not unwrap (or originally access the vector without bounds checks), but implementing a custom Error and adding a `From<ParseIntError>` and implementing the `Error` trait adds a lot of code to the example which is not relevant to the `FromStr` trait.
…al-def-id, r=oli-obk Use `LocalDefId` in `OpaqueTypeKey` Addresses a `// FIXME(oli-obk): make this a LocalDefId` r? ``@oli-obk``
…pnkfelix Fix debuginfo tests. This is needed for my Ubuntu 22.04 box due to a slight change in gdb output. The fix is similar to the fix in rust-lang#95063.
Use span_bug for unexpected field projection type Improves the compiler error backtrace information, as shown in rust-lang#99363, by using `span_bug` instead of `bug`. New output: ``` build/aarch64-apple-darwin/stage1/bin/rustc /tmp/test.rs --edition=2021 error: internal compiler error: compiler/rustc_middle/src/ty/closure.rs:185:25: Unexpected type Opaque(DefId(0:5 ~ test[db0f]::main::T::{opaque#0}), []) for `Field` projection --> /tmp/test.rs:11:27 | 11 | let Foo((a, b)) = foo; | ^^^ thread 'rustc' panicked at 'Box<dyn Any>', /Users/jmq/src/forked/rust/compiler/rustc_errors/src/lib.rs:1331:9 stack backtrace: ``` (Remainder of output truncated.)
Update invalid atomic ordering lint The restriction that success ordering must be at least as strong as its failure ordering in compare-exchange operations was lifted in rust-lang#98383.
…=scottmcm Fix `Skip::next` for non-fused inner iterators `iter.skip(n).next()` will currently call `nth` and `next` in succession on `iter`, without checking whether `nth` exhausts the iterator. Using `?` to propagate a `None` value returned by `nth` avoids this.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@4603ac3. Direct link to PR: <rust-lang/rust#99451> 💔 miri on windows: test-pass → test-fail (cc @RalfJung @oli-obk). 💔 miri on linux: test-pass → test-fail (cc @RalfJung @oli-obk).
Finished benchmarking commit (4603ac3): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesThis benchmark run did not return any relevant results for this metric. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Successful merges:
LocalDefId
inOpaqueTypeKey
#99347 (UseLocalDefId
inOpaqueTypeKey
)Skip::next
for non-fused inner iterators #99434 (FixSkip::next
for non-fused inner iterators)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup