Skip to content

llvmPackages{12-git}.clang: don't swallow unsupported option errors when compiling + linking#356547

Merged
emilazy merged 1 commit intoNixOS:llvm-19from
paparodeo:clang-args-fix
Nov 17, 2024
Merged

llvmPackages{12-git}.clang: don't swallow unsupported option errors when compiling + linking#356547
emilazy merged 1 commit intoNixOS:llvm-19from
paparodeo:clang-args-fix

Conversation

@paparodeo
Copy link
Contributor

llvm/llvm-project#116278
llvm/llvm-project#116476

the test case is dropped from the patch as it doesn't apply cleanly to clang < 17

make clang report unsupported option errors / warning when compiling + linking in the same command.

this works

$ clang --target=aarch64 -mpopcnt hello.c
clang: error: unsupported option '-mpopcnt' for target aarch64

before change clang swallows the error

$ clang --target=aarch64 -mpopcnt hello.c -lc
$ echo $?
0

after change error is reported:

$ clang --target=aarch64 -mpopcnt hello.c -lc
clang: error: unsupported option '-mpopcnt' for target aarch64

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@emilazy

@github-actions github-actions bot added the 6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related label Nov 16, 2024
@paparodeo paparodeo marked this pull request as ready for review November 16, 2024 20:48
…hen compiling + linking

`https://github.com/llvm/llvm-project/issues/116278`

make clang report unsupported option errors / warning when compiling +
linking in the same command.

this works
```
$ clang --target=aarch64 -mpopcnt hello.c
clang: error: unsupported option '-mpopcnt' for target aarch64
```

before change clang swallows the error
```
$ clang --target=aarch64 -mpopcnt hello.c -lc
$ echo $?
0
```

after change error is reported:
```
$ clang --target=aarch64 -mpopcnt hello.c -lc
clang: error: unsupported option '-mpopcnt' for target aarch64
```
Copy link
Member

@emilazy emilazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch seems reasonable and it seems like the most elegant fix for the OCaml problem. We can revert if upstream has opinions on it later.

@emilazy emilazy merged this pull request into NixOS:llvm-19 Nov 17, 2024
@paparodeo paparodeo deleted the clang-args-fix branch November 17, 2024 15:47
emilazy added a commit that referenced this pull request Nov 18, 2024
emilazy added a commit that referenced this pull request Nov 20, 2024
@paparodeo
Copy link
Contributor Author

The patch seems reasonable and it seems like the most elegant fix for the OCaml problem. We can revert if upstream has opinions on it later.

it is now merged upstream

@RossComputerGuy
Copy link
Member

Next LLVM bump will drop the patch. Also, we probably should be using getVersionFile in the event something conflicts.

@paparodeo
Copy link
Contributor Author

paparodeo commented Dec 26, 2024

Next LLVM bump will drop the patch. Also, we probably should be using getVersionFile in the event something conflicts.

yeah, it is merged upstream so I guess the next git update will conflict. getVersionFile was confusing enough that I've just been adding patches in the normal way -- I like that I can just type gf in my editor to view the patch, whether it be a local or remote file.

when this PR was merged it was not clear when upstream would accept the patch.

[edit] tho after looking at it a little getVersionFile doesn't seem that hard and does cleanup the code a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants