Of course it does. Some changes, like doc changes, should not affect the program.
So why would you try to compile your software to verify those instead of just, e.g., generating your documentation ?
2,917 karma · joined April 21, 2019
So why would you try to compile your software to verify those instead of just, e.g., generating your documentation ?
The real problem with wayland are all the apps that just don't support it. From emacs, to, e.g., all the electron apps built with older versions of chromium, etc. You can use them seamlessly with Xwayland, but then a lot of things work "weirdly", e.g., HiDPI displays blurry Xwayland apps, applications like obs-studio cannot record some apps, etc.
The the Sway ecosystem main drawbacks are the immaturity of the tools (e.g., waybar (i3bar replacement), wofi (rofi replacement), etc.) and the drawbacks of wlroots (e.g. lack of nvidia support in contrast to gnome and kde, etc.).
Many things kind of "just work" under Wayland, but many things also kind of just don't properly work. Using pipewire to, e.g., stream desktop apps via webchat from firefox/chrome works weirdly, streaming one monitor or one sway workspace from firefox/chrome does not work, capturing one workspace from sway using obs studio in another workspace does not work, etc.
extern "C" { fn foo(x: [u8; 42]); }
void foo(uint8_t x[42]);* Lack of proper Linear and !Movable types, and being in a spot where adding them to the language would be a backward incompatible change. This results in complex abstractions, like Pin.
* Fallible destructors without an easy way to return failure. In Rust, destructors (Drop::drop) can fail, but the only way for them to fail is to unwind the stack, which doesn't play very well with the rest of the Rust error handling story. C++ gets this a bit better with destructors being noexcept(true) by default, and providing tools to query whether that's the case.
* Inconsistent handling of Out-of-memory errors. Initially, Rust decided that OOM errors would be fatal, and settled on using unwinding for them. Then realized that some projects driving Rust design, like Servo, actually needed to handle them (e.g. imagine downloading and image that's too big to fit in memory bringing your webbrowser down..), so they patched being able to handle OOM on top, by adding methods to some of the collections, like `Vec::try_push`, `Vec::try_reserve`, etc. This essentially means that there are two methods to do any operations on collections, that it is pretty much impossible to make sure that code that must handle all OOM errors for correctness does so, and does not call an unwinding method by default, etc. Its also one of the reasons why colelcitons parametrized by allocators (Vec<T, A>) its taking so long.
* Lack of parametrized modules, probably a decision that's just too hard to fix at this point.
* Lots of lang items for singletons, like global allocator, panic runtime, etc.
* Unsafe keyword being too coarse grained. Unsafe functions implying unsafe function body block, unsafe keyword used to allow different types of contracts, from dereferencing a raw pointer, to calling a target-feature function, ...
* const and mut raw pointers: this distinction adds pretty much zero value, and complicates certain types of code quite a bit, for no reason.
* too monolithic standard library: libcore adds floats suport, which essentially requires you to implement floats for embedded targets, for which they might make absolutely no sense. No way to prevent programs there from using floats, etc. No way to only implement the different parts of the standard library that make sense for a platform, like threading, etc. but instead requiring targets to just mock the standard library with "unimplemented!()" hacks that error at run-time when you try to use certain APIs.
* PartialOrd, Ord, PartialEq, Eq, traits are not very mathematically sound. They attempt to achieve what C++ spaceship operator attempts, but fail quite hard. They assume that there is only one "ordering" that might make sense for a particular type, but that's usually not true. For example, floats have many orderings (the classic partial order, and IEEE total order, etc.).
* Operator overloading traits like Add or PartialOrd mix half-backed semantics with operator overloading. The standard library ends up, e.g., implementing addition for Strings, to mean concatenation. So essentially any program that constraints generics using the Add trait and requires, e.g., associativity for being free of logic errors kind of fails when passed strings (it will work, but produce garbage).
* Iterator::next returns &Target, which means that you cannot implement Target to return a "proxy" reference type.
* Many of the standard library algorithms, like "sort" and "unstable_sort" only work on slices, there is no way to use them on Lists or other collections, requiring everybody to re-implement them. C++ got this a bit better.
* BinaryHeap is only a min-heap, reusing it as a max-heap is quite weird. In general, these std::collection API mistakes are consequences of having bad fundamental traits (like PartialOrd and friends mentioned above), and a lack of more meaningful Operation traits.
* std-library is a mixed bag, with some things being quite good thought out (Result, Option, The smart pointer types, Cell types), and others being kind of an after-thought (operator overloading traits, collections). Method names are also often inconsistently named across the different parts of the library, does not feel very cohesive.
* C FFI feels like an afterthought. Some things got bolted afterwards like va_args, unions, packed, etc. Its pretty much not clear at this point how to use these correctly, or whether they can be used correctly at all in C FFI. libc is one of the most used Rust libraries, and its a huge mess of duck tape, ABI incompatible depending on where you run your binaries, which resultes in crashes that are hard to debug, etc. It basically assumes that all operating systems that Rust will ever support never will break their platform ABI. Which is an assumption that no widely-used OS satisfies. How to pass C callbacks that panic, etc. is also still super weird.
And probably many more that I can't remember right now. These are just a small fraction of the issues I've encountered and that I believe are not fixable in a backward compatible way. None of them is, in isolation, a big deal. Whether they lead to a death by 1000 paper cuts at some point or not, only time will tell. Rust also has maaany more issues, that are hopefully fixable.
When you choose to write C, you are accepting the contract that if your program has UB, there are no guarantees about what it does.
If you can't uphold your end of the contract, C is not for you.
There is a huge difference between complaining that this contract is too hard to uphold, which is a complain that you should take with the C standard, and complaining to the compiler that, on contract violation, your program misbehaves.
If you can't accept that, again, C is not for you.
For every novice that complains about their mistake misbehaving I have 100 expert C programmers that would complain about bad codegen for programs that do uphold the contract.
From a compiler writer perspective, it is impossible to argue that we should penalize those that take the time and experience to play by C rules in favor of those that write broken programs.
100% of the experts would agree that it is hard to write correct code, but "disabling compiler optimizations" is not the right place to fix that.
If you believe that's the case, you are free to compile all your code with -O0, use volatile everywhere, or just use Python or some other language that suits you best.
But the argument that you are making is ridiculous. You don't like the consequences of breaking the law, so your conclusion is that prisons should be 5 star hotels and all the law-abiding tax-payers should finance them so that you enjoy them at their cost. I wish you the best luck in life with that attitude mate.
For example: 2000 line template error, some overload cannot be picked deep in the template instantiation stack. Probably a bug with SFIANE, or template argument deduction, or ADL, or... the error message isn't helpful. The compiler tries hard to give me a "smaller" error message, by filtering out overloads that it thinks aren't relevant. One of those is the one that should get picked. Why isn't that happening? Let's figure it out. Let's start going through the template stack, trying to break the compiler in the right way to give you the right error message. Tricks like:
template <typename T> struct NeverDefined;
NeverDefined<U> {}; // errors spitting out U
int******** k = t; // errors spitting out the type of t
That's the exact opposite of "fighting" rustc. Using rustc feels like pair programming with a god-like developer. They see your mistakes dozens of moves ahead. They give you a nice error message, 10 lines long, with a summary, and an annotated version of the relevant parts of your code, explaining how the different pieces fit together to cause a problem. If you are not sure you fully understood it, you can just ask rustc to explain the error a bit more, and it would give you a couple of "self-contained" examples that produce the same error, so that you can learn from those, and then go back to your big program and fix the issue. Its fighting in the same way that going through university and learning for exams is a "fight".
People who think they know better and there is nothing left to learn from them will see that as a real fight. They'll also see pair-programming as just another fight, a waste of time. Or even will start a fight when somebody elses review their PRs.
If you are that kind of person, then Rust probably isn't for you. You won't enjoy the compiler. You won't enjoy the language. The language is designed by listening to all opinions, listening to how many different people weight them, and then making an engineering decision. That's the complete opposite of "i'm always right, best products are designed by a single person".
Luckily for Rust, most programmers aren't like that. Github is proof that for many, programming is a social activity. Programming with rustc makes you feel less alone, you are always pair programming. Programming is not a fight with the compiler, but a back & forth interactive conversation, in which you together with the compiler are working together to write a bug free program.
When you collaborate in Rust projects with other people, the social experience is also improved. The discussions about dependencies are very "goal-oriented and high-level": is this a dependency that will make the product better? Things like "how do we integrate or maintain this dependency" aren't issues with cargo. You also never discuss about formatting, that's handled for you automatically. You also never discuss about undefined behavior, or what the C or C++ standard say, or whether dereferencing something is UB or not, or whether you need a check here or not. If it compilers, the compiler proves your program for you. A huge refactor in a lock-free multi-threaded program? If it compiles, it has no memory safety or data-races. You can focus on just discussing the underlying algorithms, the architecture, the things that are most relevant for humans.
Just look at github.com/rust-lang/rust itself. People have time to write issues, explaining in them how to fix them for beginners, offering to mentor beginners into fixing them. You can drop a Rust beginner into a compiler, and you just need to explain them the high-level description of the fix. The compiler makes sure that they make no errors, and they can explore that part of the compiler on their own, by just following the types.
Because Rust is not "just memory safety". Its also having very strongly typed and explicitly-typed APIs and function signatures, that automatically give you great docs, great error messages that tell you which types to use, which you can use to find which methods these types have, and just explore code.
And these are just a couple of things that make Rust better than everything else I've ever used.
Is it perfect? Of course not. I've been using Rust full-time 5 years. It has _a lot_ of issues that probably cannot be fixed due to backward compatibility. But these issues are smaller, and less annoying, than the issues that all other programming languages I've ever used have.
Will I use Rust forever? I really hope not. I really hope somebody manages to discover a language that's significantly better than Rust in every way.
But I doubt I'll see that in my lifetime. Given the amount of features in Rust pipeline(), and the amount of time the group of PL design PhDs are taking to get them just right, such a language would need to be a significant advantage over the state of the art.
() specialization, higher-kinded types, generic associated types, variadics, full operational-semantics specification, ... there are even RFCs for dependent-types. It wouldn't surprise me if programming in Rust in 10 years feels closer to programming in Idris2 than in "Rust 2018".
Which attitude? The one that requests users to fill a bug report if they think there is an error in our compiler ?
Please let us all know which software you write and ship, and how you inspect all inputs that your users pass it in the search for bugs, instead of requiring users to fill a bug report if they think they encounter a bug.
Or maybe you are talking about the attitude of not assuming that all users know the C standard to the letter and never write code that has bugs ?
I suppose that for all the C and C++ code that you write, when the binary doesn't work as expected, you start by looking for bugs in compilers instead of proofing your own code right? Because it is almost impossible to write subtly buggy code in C and C++ right?
Given the amounts of bugs that are both filled and fixed on a daily basis, reality does not seem to reflect this claim.
If you expect compiler writers to go and explore your open source project of choice in a blind hunt for compiler bugs that they can fix, I hope you sit down while you wait and do not really need these kinds of bugs actually fixed.
And obviously, under the hope that somebody notices the failure by then, tracks it down to the right commit, and fixes the commit, instead of adding a workaround that avoid having to find the root of the problem.
"master doesn't pass tests" isn't just about naming. Its about culture. Its about agreeing that there is some source of code that everyone agrees on should work, and having the culture of agreeing that all modifications to it should work as well, and that it is the responsibility of those doing the modifications to make sure that's the case.
For example, some people send doc fixes. Sometimes these doc fixes have "bugs" that actually make compilation fail. Like adding a line break and forgetting to mark the next line as a comment...
Compiling LLVM for such changes takes quite a bit of time, so of course people don't even do it.
I have better things to do than reading the whole SQLite code base like, for example, fixing the bugs of the people that actually bothered to fill in a bug report.
Until this bug is confirmed, it can be anything, and unfortunately, bugs reported for C and C++ projects are quite often not bugs in the compiler, but UB in user code.
The fact that you think that just by looking at a single function signature one can deduce where this could be UB related to const depicts the problem. UB is unfortunately not that simple, and I can think of a couple of ways of const-related UB in which the declaration "looked fine".
Does anyone have a link to the reported clang bug?
For example, it might well be that the function that clang believes does not modify pmem->flags "promises" that it does not modify the value. In which case it might be an SQLite bug, that clang just did not happen to "correctly optimize" before.
This can happen, e.g., if you mark your function with __attribute__((const)), for example, which promises that your function does not access memory via arguments that have pointers. It then becomes trivial for clang to make the transformation above.
The bug wouldn't even need to be on the function definition, it might just be on the declaration, or on a declaration somewhere, in which case you have an ODR violation as well.
All that seems very unlikely since it appears to be clear that the function does modify memory, but still, I'd just wait for the clang bug to be filled with a reproducer, and the issue to be tracked down.
It does strongly hint at a bug in clang, but from the linked page, I at least cannot conclude that yet.
If you look at Rust, you cannot commit to master:
- without the resulting master merge passing the whole test suite, which would probably take a day or more to run locally, and - without a review of someone that knows the part of the code you modified well, or somebody they delegate to, and often, of a group of multiple people that know that part of the code well. These people verify that the code is correct, commented, tested, appropriate, etc. Often, a design team in charge of that part of the code that makes sure that the change goes in a direction that aligns with the project strategy/goals (i.e. that this is a change we want to make).
Even the best of the best software developers:
- don't always test that their code compiles before committing: for Rust, they really can't to, they'd need to cross-compile the compiler dozens of times, run these compilers under qemu on different hardware, and verify that they work - too much work for any single human - don't always test that their code passes the test suite: the test suite is _huge_. Its impossible for anybody to test anything locally, takes too much time. - don't always benchmark the compiler after a change on reasonable applications, takes too much time. - etc. point being, you cannot trust the best of the best, much less anyone else. As a Rust compiler dev, the first person that you should not trust is _you_.
The whole point of the process is identifying all possible sources of errors, and making them impossible, or at worst, extremely unlikely to happen.
Most of these errors are only quite unlikely to happen, e.g., because all the automated tooling that exists to prevent them is also written by humans that make mistakes.
But every time a new source of error is identified, there is at least a discussion about how to make it impossible to happen in the future.
Having a test suite, having reviewers, are just two things you have to do to avoid a large set of errors (see a comment below about how each release of Rust is required to succesfully compile all existing public Rust source code and run all their tests succesfully).
They are not barely enough. And even if your process makes errors extremely unlikely, Rust and LLVM have hundreds of PRs on flight and hundreds of developers working on the source code regularly. Throw enough developers at a project, and unlikely events become a daily thing.
I build LLVM from source a lot, and master not even building because somebody made a change that doesn't even compiler is astonishing.
FWIW, LLVM has a pretty big test suite. But... to catch errors... you actually... have to... run it...
It is often the case that Rust, which does have a policy of "master always passes all tests" catches bugs in LLVM before LLVM does.
I expect Canonical or Lenovo or both to test all release candidates of all kernel versions after release and make sure that the hardware actually works, and if it doesn't, prevent the release of a broken Linux kernel version.
That would be the minimum level of QA acceptable for a "certified" laptop.
Waiting 7 months to be able to use sound was not an option for me. I needed to use the microphone and headphones for work.
Luckily I managed to get Arch set up, which came with a recent enough kernel and SOF driver. As of June 2020, Ubuntu still does not.
Maybe its my fault for having unreasonable expectations. No idea what the story is on Windows.
FWIW, I've also used fwup and it has worked perfectly, so that's something that Lenovo did get right.
> I think Linux support of new hardware is always going to be shaky unless we can get vendors to care and support it themselves.
This is what I actually expect from a Ubuntu-certified laptop. That the manufacturer makes sure that the Laptop actually works with Ubuntu.
That's the same bar I have for Apple and windows laptops.
Otherwise they should just call them "Linux tinkerer friendly" or similar.
But since I paid 2k$ for a Lenovo Ubuntu laptop, I'm the one that's wrong for expecting the fingerprint reader to actually work.
I paid ~2k$ for a Lenovo Laptop certified for Ubuntu. I don't really see the difference between doing that and paying 2k$ for an Apple laptop that's certified for MacOS (which i've upgraded for 8 years for free), or some other laptop certified for windows.
Except for the obvious difference that the Lenovo Laptop does not work with Ubuntu as promised.
Why IBM? IBM sold Lenovo to China years ago, does IBM still handle support for Lenovo in your country?
That's ok for any Laptop that isn't advertised as "Ubuntu certified".
But I literally had to uninstall Ubuntu and install Arch to get audio and microphone back to work after the 19.04 update broke it, and some dev mentioning on the bug report that the fix wouldn't land on 20.04 which it didn't.
Imagine Microsoft or Apple telling their users that they have to live without a soundcard for 6 months during COVID-19 because "tough luck". Well that's pretty much how Canonical and Lenovo treat their customers.