-
Notifications
You must be signed in to change notification settings - Fork 13.4k
llvm lint: "Return statement in function with noreturn attribute" caused by .count() ? #48227
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 3, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now mark such return values with a new `IgnoreMode::Uninhabited`, and emit an `abort` anywhere that would have returned. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 3, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now mark such return values with a new `IgnoreMode::Uninhabited`, and emit an `abort` anywhere that would have returned. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 4, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 4, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 4, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 4, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
Centril
added a commit
to Centril/rust
that referenced
this issue
Apr 4, 2019
Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn`, but we were still generating return instructions for this. When running with `-C passes=lint`, LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value. Fixes rust-lang#48227 cc rust-lang#7463 rust-lang#48229 r? @eddyb
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Uh oh!
There was an error while loading. Please reload this page.
This was reduced from diff.rs https://github.com/utkarshkukreti/diff.rs
The lint warning vanishes when I remove the
.count()
.EDIT: //cc #7463
The text was updated successfully, but these errors were encountered: