1. 02 Jul, 2019 1 commit
  2. 13 Mar, 2019 1 commit
  3. 12 Mar, 2019 1 commit
  4. 12 Nov, 2018 1 commit
  5. 26 Jun, 2014 2 commits
  6. 25 Jun, 2014 2 commits
  7. 10 Feb, 2014 1 commit
  8. 14 Jan, 2014 1 commit
  9. 01 Jan, 2014 1 commit
  10. 09 Oct, 2013 1 commit
  11. 27 Dec, 2012 1 commit
  12. 13 Jun, 2012 2 commits
  13. 29 Mar, 2012 1 commit
  14. 12 Mar, 2012 1 commit
  15. 20 Feb, 2012 1 commit
  16. 26 Sep, 2011 1 commit
  17. 24 Aug, 2011 1 commit
  18. 28 Feb, 2011 1 commit
  19. 21 Feb, 2011 2 commits
  20. 16 Feb, 2011 1 commit
  21. 14 Feb, 2011 1 commit
  22. 30 Dec, 2010 1 commit
  23. 19 Sep, 2010 1 commit
  24. 28 Jul, 2010 1 commit
  25. 26 Apr, 2010 1 commit
  26. 30 Mar, 2010 2 commits
  27. 16 Mar, 2010 2 commits
  28. 08 Feb, 2010 1 commit
  29. 05 Feb, 2010 1 commit
  30. 19 Jan, 2010 1 commit
    • Rob Shearman's avatar
      wpp: Fix expansion of macro bodies following the parsing of a numerical digit. · 3fecf9dd
      Rob Shearman authored
      The current regular expression causes all letters and spaces (among
      other characters) following the appearance of a digit to be classed as
      a literal, including C identifiers which may need to be expanded.
      
      The expression was intended to catch the remaining characters that
      were not covered by the first two rules ([^a-zA-Z0-9'"#/\\\n]+ and
      {cident}), but the [^'"#/\\\n] expression caught {cident} as well.
      While one solution would have been just to catch the expression that
      match [a-zA-Z0-9]* that don't match {cident}, i.e. [0-9][a-zA-Z0-9]*,
      in the interests of avoiding unnecessary multiple LITERALs being
      generated and then combined during parsing the expression also
      includes the first expression, making it
      [0-9][a-zA-Z0-9]*[^a-zA-Z0-9'"#/\\\n]*.
      3fecf9dd
  31. 04 Jan, 2010 1 commit
  32. 30 Dec, 2009 1 commit
  33. 29 Dec, 2009 1 commit
  34. 13 Oct, 2009 1 commit