search for: birkenfeld

...he Pygments lexer is sort of "brittle" and will fail to syntax highlight things if they stray too far from the lexical syntax it expects (due to being out of date or misspecified in the Pygments highlighter). You should check that the upstream has the same issue < https://bitbucket.org/birkenfeld/pygments-main/src/9246d7a47a42e7920c0ecee4d4946b982e9e2430/pygments/lexers/asm.py?at=default#cl-193>. We may just need to update to the latest sphinx. -- Sean Silva > > > -- Mikael > > > _______________________________________________ > LLVM Developers mailing list > L...

Hi, The language reference uses "::" many places where it seems it should be using ".. code-block:: llvm". The result is that Sphinx does not colorize these samples. Should I fix this? Or is it purposeful? Also, anybody but me that has noticed that Sphinx does not always colorize things even if you put the proper ".. code-block:: llvm" in front? If it is a known

Hi all, Did you know that there is a 'deplibs' keyword? Neither did I. It looks like it's not really used for much. We don't document it in the Language Reference. The only support I see if for reading/writing bitcode and manipulating modules. There's a bunch of code that could be removed if we could get rid of this. Does anyone use this thing? Does anyone mind if I nuke it?

Overhauling Attributes Problem ======= LTO needs a way to pass options through to different parts of the compiler. In particular, we need to pass code generation options to the back-end. The way we want to do this is via the LLVM Attributes class. In order to do that, we need to overhaul the Attributes class. The Attributes class right now isn't very extensible. After considering several